I was asked earlier today if I could describe “…the Eclipse community and its differences between other traditional commercial open source communities say like Sugar’s and non, or less pure commercial communities like Apache.”
Darn good question. Off the top of my head here are a couple of key differentiating points. I would certainly be interested in hearing the views and comments of others. Both from Eclipse and from other communities.
- I actually don’t think of the likes of Sugar or MySQL as “traditional” open source communities. I think of them as corporately owned communities. Yes, there are vibrant communities there, but the intellectual property is owned by a single vendor backed by investors with an expectation that a profit will be made and that an exit will be had.
- Communities such as Linux, Apache and Eclipse are distinctive in that they are either not-for-profit or non-profit and have a legal requirement to be vendor-neutral and a community requirement to respect the principles of openness, transparency and meritocracy. They are not motivated by their own profit, but are motivated to see the businesses of their stakeholders be profitable. As such, they are trusted agents at the centre of the business ecosystems that they create, in ways that a for-profit vendor could never be.
Eclipse is differentiated from Apache in many ways. But here are a few to think about:
- First, our interests in creating a commercially profitable ecosystem are more overt. Obviously, there is a very vibrant ecosystem that has sprung up around many of the Apache projects and the Apache folks are happy about it. But at Eclipse it is a stated directive for the staff of the Foundation to help foster that commercial success, rather than a side effect. We work every day to attract companies to use technologies from the Eclipse projects.
- Secondly, the Eclipse community is working on a single technology platform, so every Eclipse project can inter-operate with the others at some level. Since we are using a common technology platform (Equinox OSGi) and since many of our developers are paid to be full-time Eclipse developers we can do things like ship an annual release train where dozens of Eclipse projects release simultaneously. (This year there were 37 projects that shipped together.) These release trains form the technology platform for the Eclipse ecosystem to build products on for the next year. We now have a track record of shipping six years in a row with the release train on schedule to the day.
- Thirdly, as a matter of culture Apache uses “community before code” as its mantra. We don’t run around saying this but the reality is that at Eclipse we value “code before community”. Diversity and community are one measure of the health of an Eclipse project but in the end we really care about the code quality and commercial adoption of an Eclipse project when we think of it as a success. The Eclipse projects that manage to do both are the ones we consider our home runs.
So vive le difference!
There are obviously some gross generalizations in the above, but I think I successfully captured some of the key points. Anything I missed? Anything blatantly dumb?
