Contributing to Intel® OpenMP* runtime

Why should I contribute changes to the Intel® OpenMP* runtime?


If you contribute your changes they can be accepted into the main source base for the Intel® OpenMP* runtime and thus be included and tested in future releases, including the COM licensed releases of the runtime made with Intel’s compiler products.

To learn more about the Intel® OpenMP* runtime contribution process please refer to the contribution section of openmprtl.org.

Why is there a contribution process?


In order for the Intel® OpenMP* runtime to be released under multiple licenses, including COM, Intel must maintain rights to the code base.

For Intel to maintain the rights to the code base it needs to dual-license, contributors to the Intel® OpenMP* project must contribute their code and explicitly agree to the contribution terms laid out in the contribution agreement in order properly to assign these rights to Intel.

When you contribute you don’t lose rights to your code (we give them right back to you!), but you give us enough rights that we can make the outbound dual-licensing work.

This is the same kind of process that is required to submit code to many open-source projects; for instance you have to give your rights to the Free Software Foundation before submitting code to the GCC project.

Do I lose any rights to my contribution under the contribution agreement?


To preserve the needs of all product users, you will need to assign your copyrights to Intel, which are then licensed back to you.

Who will decide which contributions are accepted to the Intel® OpenMP* runtime code base?


The final decision will rest with the maintainer (Intel).

When can I start contributing fixes and enhancements to the Intel® OpenMP* runtime? How can I start doing that?


You can start contributing now.

How do you plan to manage the process of introducing changes made by the community to your commercial products?


We will actively review all proposed changes to the source and assess market demand for new features. The more a change contributes to a feature for which there is high demand from our user base the more likely we are to incorporate it.

Do you expect to accept all input?

We hope so. Obviously we’ll need to review the impact of the change on all the platforms we support (we’re not expecting every contributor to benchmark their changes on the Intel® Xeon Phi™ coprocessor, for instance!)  and .may need to introduce  modifications. However our aim is to enable community contributions, not to block them.

What turn around do you expect on accepting changes in from the community?


We will regularly post new updates to the Intel® OpenMP* runtime source; the turnaround of a specific change will depend on the complexity of the change and the time it takes to complete each step of the review process. We’ll strive to make the process visible for the community.

Is there a mailing list for users or developers?


No. The Intel® OpenMP* Runtime forum has an RSS feed, and we are using that for the moment. If that proves to be a problem we can always change later.

Does this project include the “right to fork?”


Yes. But may we say “ouch!”? Forking has been called a “nuclear option.” We are committed to being excellent maintainers – translating our passion for parallelism and for helping software developers into a fantastic project, a project that is a good experience for all involved. If “forking” seems like a good idea for some reason, we hope we’ll have the chance to discuss it and work out differences. We think the industry will benefit from a single strong project.

However, we also believe that the “right to fork” is an important right. It is a “check” on the maintainers that helps to bring balance. Of course, if your maintainer is evil or bad in your opinion, this “check” can be powerful.

So we believe in the “check” but we think that projects should be well maintained and, in general, not fork. Therefore, we have adopted standard licenses, which include the “right to fork.” There are no funny little “extra” clauses saying you can’t fork. If we fail to be a good enough maintainer to build a community which does not fork – we’ll be sad and disappointed. Enough said.