By far and away, my favourite quote from Cory Doctorow‘s talk at EclipseCon was: “Ideas are cheap. Execution is hard.” Those truly are words to live by.
Remember that as I walk through some thoughts on Eclipse and our community’s strategy. Tony Baer, who writes OnStrategies has been an avid Eclipse-watcher for some time, and one that I very much enjoy reading. His latest theme seems to be that Eclipse is in flux, largely as a result of the growth in projects and the resulting lack of focus. Tony raises many very good points. I don’t agree with all of them, but even where I disagree I find them thought-provoking. I certainly gain a lot more from reading something which challenges our assumptions than those who agree with them.
Here’s a roundup of some of their Eclipse-specific articles:
- Guess Who’s Coming to Dinner? provides an excellent summary of the interactions with both Microsoft and Sun last week at EclipseCon. There were two money quotes in this article:
- “No longer defined by the IDE, the spreading of Eclipse’s mission means that members and neighbors aren’t necessarily drinking all the Kool Aid.“
- In other words, as Eclipse gets broader, its mission is in the eyes of the beholder.
- Eclipse’s Vernal Equinox came out the day EclipseCon 2008 opened, and picked up on the theme from the previous year. To whit:
“Eclipse is undergoing organizational growing pains made possible by its embrace of a technology (OSGi) whose versatility opens up huge new possibilities. But as any organization spreads its wings, preserving consensus becomes far more challenging, not to mention maintaining focus. Although the Eclipse Foundation is not a standards organization per se, it shares challenges similar to confederated standards bodies like Oasis that have lean, loose governance structures. All too often, you wind up with anarchy as competing, overlapping projects admitted with the intent of encouraging participation instead compromise the very principle by which most of these organizations were founded: interoperability.“
- Eclipse Eclipsed? came out around the time of EclipseCon 2007 and first raised the issue that Eclipse was losing its focus in a way very similar to the JCP. By spreading ourselves too thin, we are….well, actually this article never actually states what the downside might be. After pointing out that Eclipse had moved from its “...almost comical…” origins to “…the Java world’s de facto response to Microsoft Visual Studio…“, it singles out RedHat’s decision to open source their Eclipse plug-ins on their own forge rather than at Eclipse to indicate “…that the open source community does not necessarily want Eclipse to become all things Java.“
As I mentioned earlier, I don’t agree with all of these points. But there is one over-arching theme that I definitely do agree with: life is getting more complex as Eclipse projects spread into more areas. Runtimes in particular, have ummmm generated some interesting conversations, as various organizations have sought to understand what’s happening at Eclipse and how that might affect their business.
Tony is also completely correct in believing that companies like IBM, Oracle and RedHat are going to be selective in which technologies from Eclipse they adopt. It is highly unlikely, in fact, that any of the current players are going to adopt all of the projects in the new EclipseRT project (see EclipseCon slides). The whole point of the stackless stack is, of course, that selection is not only possible but desirable.
Where I disagree with Tony’s analysis is his assumptions. Eclipse is not only “…not a standards organization per se...”, it is nothing like a standards organization. Our goals, processes and outputs are very different than a standards organization. That’s why open source organizations make excellent complements to open standards, but are not a replacement for them.
Open source communities such as Eclipse and Apache are innovation engines. They are places where ideas can be forged to usefulness in the crucible of a meritocratic community. Remember: ideas are cheap. Achieving the expectations of a successful Eclipse project (quality, APIs, community and commercial adoption to name just a few) requires some very hard execution indeed.
Similarly, assuming that interoperability a goal of Eclipse is off the mark. At least in the way term is used. I believe that one of the single strongest elements of Eclipse is that we do, as a community, have a great deal of interoperability. The fact that Equinox provides a common OSGi-compliant runtime shared by every single project at Eclipse gives us good (but not perfect) interoperability across our projects. But the purpose of the Eclipse Foundation is not to specify interoperability between its many projects. Our goal is “…to advance the creation, evolution, promotion, and support of [a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools] and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services”. We are on a development platform mission, not an industry-wide interoperability mission. We actually seem to be having some very real victories in interoperability, but don’t confuse side-effects with the main mission.
So when I hear comments that Eclipse is losing focus, I ask: what do you think our focus is? I believe our focus is to create a community and ecosystem, not — with the possible exception of the base platform — any particular technology. “Development platform” is a broad term that encompasses quite a bit of technology. Or put another way, the secret sauce of Eclipse is not any particular technology; it is that we have come up with the best model we know of for doing collaborative development amongst both individuals and corporations. Our primary focus at the Eclipse Foundation is to constantly invest in improving the development and IP processes and the IT infrastructure to support that collaborative model.
Of course we also like to raise awareness when the community builds some cool technology as well. And once some technology has demonstrated broad utility and adoption, then it might be useful to send it off for a formal specification.
As long as we are seeing a steady stream of innovative new projects at Eclipse we are making progress IMHO. The Eclipse Foundation does not pick winners by trying to decide a priori which projects will succeed, if for no other reason than my utter confidence in our inability to pick those winners. Competition and the community will sort that out for us. And competition — which is the universal constant in successful ecosystems — means that failures must exist. But I assert that any philosophy other than embracing competition and its inevitable winners and losers will result in a dysfunctional community. Even if that means that we sometimes suffer “…anarchy as competing, overlapping projects…” arrive at Eclipse.
Ideas are cheap. Execution is hard. Think of Eclipse as the place where ideas have an opportunity to be executed. Shameless pun intended 
