Level Playing Field

Originally posted on August 2, 2017

For many open source organisations, open means the same thing as transparent: open as in open book. At the Eclipse Foundation, we regard being transparent as the practice of making sure that the community can see and understand what the project is doing; and being open as the act of giving up absolute control and welcoming the community to participate as an equal player on a level playing field (i.e. being open to participation by the others).

At the Eclipse Foundation, we take the open part of open source very seriously. It’s codified in the Open Source Rules of Engagement found in the Eclipse Foundation Development Process.

Everybody needs to play by the same set of rules. A level playing field doesn’t necessarily mean that a project team needs to accept every single contribution that comes their way. Rather, it means that the project team needs to have a set of rules by which everybody participates; and these rules can’t include things like for whom the contributor works.

Contribution rules can require that contributions fall within the project’s scope and current release plan. The rules can require that all code contributions be accompanied by unit tests and documentation; or that contributions implement a solution for an issue that’s been discussed by the project team in their issue tracker. Some sort of quality bar is a reasonable part of any set of contribution rules.

For most open source projects, these contribution rules aren’t formally captured. However, most of the rules that I’ve listed so far collectively form a pretty reasonable default set of participation rules. A quality bar is (obviously) hard to quantify, but for many project teams it’s enough that any committer feels that the contribution should be accepted (some projects require that two committers sign off on a contribution before it can be accepted).

Note that it’s also perfectly reasonable for a project team to require that significant contributions come with a promise of continued investment in the form of the contributor becoming a member of the project team.

Regardless of the rules that define the level playing field for any particular project, any content destined for the project’s code base should have some public record of contribution. Otherwise, the project would be operating (at least in part) hidden from community involvement and so counter to the open source rules of engagement. That public record can take the form of a Gerrit review, merged GitHub pull request, GitLab merge request, or (if you’re in a pinch) an attachment on a Bugzilla or GitHub Issue record.

Regardless of how a contribution is presented, the contributor must be listed as the author in the Git commit record and must complete the Eclipse Contributor Agreement before any contribution can be accepted.

The best way to get involved with an open source project is connect with the project team. All Eclipse project repositories should have a contribution guide in the root of every Git repository with this contact information and more. You can also search for project information on the Eclipse Projects website.