Imagine that you want to contribute to an open source project. You visit the project to browse the information provided by the project team and make your way to the downloads page. There, you discover that the downloads are hosted at a separate site owned and maintained by one of the project’s contributing organizations. Let’s say that the organization is a competitor of your own employer. Would you still want to contribute to that project? Would you feel invited to join? Would you feel that the project is open to your ideas?
Vendor neutrality is a tricky thing to balance. Organizations that contribute to open source deserve some recognition, but if you cross the line from recognition to vendor bias, you may end up turning away potential contributors and their contributions.
Splashing a few logos on a project page is a great way to provide recognition. Committer email addresses can very often also provide some amount of recognition. The trick is to stay on the right side of the line that separates “interesting; company X contributes a lot to this project” and “company X obviously owns and runs this project”. It can be very difficult to manage perception.
Vendor neutrality is a requirement that’s baked right into the Eclipse Bylaws:
The Eclipse technology is a vendor-neutral, open development
platform supplying frameworks and exemplary, extensible tools (the “Eclipse Platform”).
It’s something that we take very seriously. It’s not something, however, for which we have very many hard-and-fast rules. Managing vendor neutrality tends to be a subjective matter that is highly-dependent on perception.
For example, it’s generally acceptable for a project to include a link or two on their download page to software that is hosted elsewhere. Some projects do this to provide more complete packages that contain the project code along with value-add software. There’s nothing wrong with doing this, provided that:
- the project code is accessible directly from the vendor-neutral eclipse.org download server;
- the eclipse.org-based downloads are the prominent choice; and
- there is a means for other organizations provide similar links to their project-related downloads.
Similarly, providing links to services related to a project can be helpful for the adopter community. Again, there’s nothing wrong with doing this, provided that the playing field is level. If a project chooses to provide links to services, it must be done in a vendor-neutral manner: other providers of similar project-related services must have a means of having their links included. It’s often enough to just document a reasonable set of conditions that must be met for another organization to list their services. Or you can just outsource the problem completely and include a link to services listed in the Eclipse Marketplace.
The Eclipse wiki provides further guidance concerning links to non-eclipse.org content.
Vendor neutrality is a big and important part of project diversity. If you are an Eclipse project, you have to care about project diversity. By extension, you have to care about vendor neutrality.
