Quo Vadis Eclipse? Part Two
In the second of our three part critique of the Eclipse Foundation and ecosystem, we look at the discussions that took place within the community, and how companies' interactions with the Eclipse Foundation, are changing....
The first critical discussions were carried out in community blogs in 2009, when different Eclipse activists debated how the value of Eclipse Foundation membership could be restored, and how more companies could be encouraged to contribute to the Eclipse ecosystem. These discussions were prompted by Community director Bjorn Freeman-Benson who posed the following question in his blog series 'State-of-Eclipse:' “Fewer resources, more to do, and a larger user base – change is upon us, so what are we going to do about it?”
This discussion eventually drifted off course and, after the dismissal of Freeman-Benson and his subsequent exclusion from the organisational team of EclipseCon 2010, the debate became more of a polemic dispute between Freeman-Benson and Mike Milinkovich. The following slanging match, where Milinkovich called his former employee a “Jerk” and publicly ordered him to leave Eclipse (“Dear Bjorn: Go away”) detracted from the seriousness of the original discussion in which a number of the major protagonists of the Eclipse ecosystem took part.
The debate did touch upon some important issues, originally highlighted by Freeman-Benson, just perhaps in too frank a manner. But, these issues impacted the wider community and remain a thorn in Eclipse's side even today.
Most of the Eclipse projects are governed by a single company. Equations like: Eclipse JDT = IBM, BIRT = Actuate, EclipseLink = Oracle are still valid even today. This can be problematic as companies, especially in economically hard times, have a tendency to either neglect their open projects or to adjust them to suit their own requirements. If a company withdraws support, and the project loses its “Sugar Daddy”, a project is likely to die the slow Open Source death, especially if they are not the centre of a vibrant user community. In an interview with Eclipse Magazine Doug Schaefer acknowledges this: “I’ve seen too many projects that are single vendor and that scares away contributors because they’re not sure what the intentions of that vendor are.”
High Access Hurdles: IP Processes
Another problem: The IP guidelines, which must be strictly adhered to, certainly lead to reliable, commercial-friendly source code, which companies require in order to build up their projects. But these laborious IP guidelines also require considerable additional effort, which become the sole responsibility of the committers.
In an interview with Eclipse Magazine Greg Wilkins, the Mastermind of Jetty, said:
“Because Jetty is a maven built project, it is very good at tracking its dependencies and how we depend on them (eg for test, by source, optional, etc). This encourages a distribution that can pull in lots of optional 3rd party soft dependencies into the bundle for download. This has been a pain point for us, because every byte available for download from Eclipse is under the Eclipse Foundation terms and we cannot make representations about some of the dependencies that we have brought in just for testing or for optional integrations.”
The IP processes prevent easy access to the Eclipse ecosystem. This may cause problems, particularly for small, innovative community projects. The Eclipse Foundation seems to be aware of this problem: in December 2009, Mike Milinkovich announced the creation of “Eclipse Labs," where new Eclipse projects can reside without having to fulfill the strict Eclipse Foundation guidelines. The future of the “Eclipse jewels” that have gone unnoticed on SourceForge for years, is beginning to look brighter.
There is a third point of discontent that can be found in community discussions. Today, Eclipse is available to download in ten pre-configured distributions, arranged according to purpose: from the “IDE for Java EE Developers” via the “SOA Platform for Java and SOA Developers” to “Pulsar Distribution for Mobile Java Developers.” These distributions appear to be readily consumable products, but in reality they contain only loosely connected frameworks. They give the impression of providing well coordinated components, such as you might find in professionally marketed IDEs like InelliJ or commercial Eclipse distributions like MyEclipse. But they rarely offer the standard expected of a commercial distro: Components have to be adjusted manually, new plugins have to be installed, etc.
Particularly amongst the free plugin market, one is faced with a plethora of Eclipse extensions that conform to completely different standards of quality and release cycles. Complaints about the “plugin hell” following the installation of Eclipse plugins are frequent and widespread (see, for instance, the interactive IDE comparison on JAXenter.) The underlying problem is that there is an expectation that the Eclipse distribution is a ready and gratis product. This has at least three serious consequences:
The following idea is propagated: Eclipse is gratis (“Free as in Free Beer.”) So, why should you pay for commercial support?
The community expects to get a readily consumable product, and is disappointed. Consequently, many turn away from Eclipse –NetBeans actually wins constantly more supporters.
By providing distros, the Eclipse Foundation enters into competition with its own member enterprises. The Business Model of offering coordinated Eclipse distributions like MyEclipse (Genuitec) or Yoxos (EclipseSource) has been undermined.
“The main problem I see is that Eclipse member companies actually compete with the free Eclipse.”
Mik Kersten, CEO Tasktop Technologies:
“I think that we have to strive to be more clear about what people can get for free and where to go if they want more. This means doing things like setting support expectations on download pages, and email/newsgroup listings.”
The Vital Question of the Eclipse Foundation
A greater diversity of projects, more flexible IP processes, a better distribution strategy - these were the three main demands of those who participated in the community discussions. Indeed, they were looking for a solution to the one decisive question which could become a vital question for the Eclipse Foundation: What do members of the Foundation, still get from being members?
Let's take a look at the evolutionary process of the Eclipse ecosystem: Why did companies become members of the Foundation in the first place? In an interesting quote, Richard Gronback (Co-Leader of the Modeling PMC and Project Lead of the Eclipse projects GMF and Amalgam) remembers the beginnings of Eclipse, when the strategic members were less interested in the marketing boost gained by the “Eclipse” brand, as their company names were then much more widely-known than Eclipse. The members “paid to contribute in order to share in the expense of building and maintaining a high quality underlying platform for their commercial products.”
Today, the situation has changed. This jointly created platform is already established and can be used without contributing to the Eclipse ecosystem. In addition, the Eclipse technology has reached such a high standard that many dare to ask: What can the Eclipse Foundation offer me, what I can't already get from them for free?
“Another good question: If the members stopped funding the Foundation and it disappeared, would Eclipse live on? I think the answer would be yes. And, I think that's the real issue at play here.”
Indeed, Eclipse-based products run on a stable platform that exists independently of Eclipse Foundation membership. What would Siemens – one of the big Eclipse users – actually stand to gain from being more active in the Eclipse Foundation? What would be the advantages of a small company such as “Powerflasher” (which offers 'FDT,' an Eclipse IDE for Flash) becoming a member of the Eclipse Foundation?
Typically, the Eclipse Foundation's stance is that one gains a stronger influence over the direction of the Eclipse ecosystem, as a strategic member. However, in our dealings with Eclipse companies we have increasingly encountered the attitude that, since they are content with the existing platform, they have no interest in participating in developing it any further. In addition, there is the barrier of having to adjust to the many different interests within the Eclipse Foundation, and to assert oneself against the majority of “IBM and Oracle people” in the Foundation.
So, what if I, as the manager of an enterprise, come to the conclusion that it is the best for my business model to use Eclipse free of charge, and save on the subscriptions and commitments connected with membership in the Eclipse Foundation?
“Clash of Cultures” or “Tragedy of Commons”?
“Betrayal!” cry the Open Source advocates who refer to the 'Tragedy of the Commons' “due to the egoism of individuals, a jointly cultivated good is ruined!” But it is not as simple as that.
The lifecycle of Eclipse projects can be generally described as follows:
- Committers develop projects.
- On the basis of theses projects emerge products for the end user that can be commercialised.
- The end users generate profit for the companies.
- The companies finance committers.
In theory this pattern is circular and should lead to an increase in Eclipse technology, a growth of the Eclipse market and thus to continually increasing profit-making opportunities for participating companies. But, more and more frequently the transition from stage three to stage four does not take place. Nobody prevents a company from using the qualitatively high-grade code basis of Eclipse, if they haven't given something back to the community.
It is certainly true that financing Eclipse committers is of benefit to the Eclipse ecosystem. But, it is doubtful whether the companies automatically profit from a growth in the Eclipse ecosystem. If they profit at all, it is likely to be a long-term process. Especially in economically difficult times, there is the tendency to optimise for the short term in order to emerge from the crisis with minimal negative impact.
It is also of no use to appeal to the “Open Source Spirit” in the sense of a grassroots movement. Even the Eclipse Foundation pushes Open Source projects via strong governance processes from a grassroots movement, towards a more business orientation. On this level, there is no room for idealistic images of freedom in a collectively built platform. Instead, you must deal with the tough, calculated vested interests of one company competing with another. Cross-company co-operations are indeed still rare (in 2008 the Eclipse Roadmap listed the foundation of industry working groups as a strategic aim. However, up until now there have been only two IWGs: Pulsar and Eclipse SOA.)
The neglect of a jointly cultivated good (Tragedy of Commons) is not so much an issue here. Instead, the issues are the massive cultural differences in the clash of Open Source ideology and business interests.
Here is a documented example of the current practice: Company A makes use of a free accessible Eclipse project in a productive way. Company B evaluates the same Eclipse project and asks the original project developers for more information, which is provided promptly. But, when the original project developers ask company A to make their experiences available for company B, the answer is this: for 2,500 Euros per day, we will gladly arrange a briefing.
Here, the following question comes into play: Who actually benefits from Open Source? In this instance, it certainly isn't the original Open Source developers.
Even when Open Source software finds a constantly increasing acceptance and adoption (see Mike Milinkovich in an interview with Eclipse Magazine 4.10: “Open Source Won.”) it might simply be the case that you cannot gain as much money from the Open Source business model, as was initially thought. Previously, you might have believed that the new Eclipse Governance Open Source Model was unstoppable. Today, we are brought down to earth by the insight that the Eclipse ecosystem is stagnating, and few companies earn their money simply because they contribute to Open Source software, or because they are members of the Eclipse Foundation.
What is the 'Eclipse' Brand Worth?
But, what about the positive impact of the 'Eclipse' brand on advertising, as mentioned in the official Eclipse Foundation document 'Memebership Benefits'? “The exclusive members only logo and supporting artwork can be used on marketing material such as your web site, signs at trade shows, product collateral, etc.”
Well, it was certainly the case that during the Eclipse boom the tag 'Eclipse-based' or 'member of the Eclipse Foundation' had marketing potential, and could considerably increase the visibility of a company or a product. In gold-digging times, the Eclipse Foundation didn't really have to actively market: the 'Eclipse' brand spoke for itself.
But, increasingly it seems that 'Eclipse' is losing its status as a marketing magic-bullet. Eclipse is established; it no longer has the buzz of something 'new,' 'innovative' and 'pioneering.' Certain Eclipse companies are visibly trying to distance themselves from Eclipse. Actuate, for example, has toned down the Eclipse branding, and when it comes to model-driven development is stresses that these technologies are also appropriate for projects outside the Eclipse ecosystem.
Tool manufacturers also react rather coolly, when asked about the Eclipse crises. In an interview with Eclipse Magazine, an Eclipse entrepreneur recently said: “My product might be Eclipse-based, but it can build on other technologies if necessary. In case Eclipse was no longer there, then there would be something else.” The industry is preparing itself for a world, post-Eclipse.
In this climate, the Eclipse Foundation is being asked to provide better marketing of its own accord. But, given the staffing constraints, the possibilities are rather modest and the current discussion amongst the community is focused on improving the IT infrastructure. Some of these improvements have already been put into place: the new Eclipse Marketplace has been established; a Marketplace client is under development to directly integrate the IDE and the Marketplace. Apparently, something along the lines of an 'Eclipse App Store' is planned for the future. But how this would look is currently a matter of controversy.
When all the aforementioned points are taken into consideration, the industry's lack of enthusiasm towards the e4 project is understandable. Eclipse as a development platform and as a Rich Client Platform has been established to such an extent that any change to the underlying platform threatens investments amounting to millions. As much as the community agrees that the platform has been getting a bit long in the tooth, it is unclear whether the e4 project can bring about a second Golden Era of Eclipse, where Eclipse is something exciting, innovative and new. Where is the “killer feature” in e4? asked Elias Volanakis in his blog 'Is e4 a lemon?”
It is revealing that, apart from IBM, only a few Eclipse companies followed the Foundation's appeal that all parties participate in the e4 project (from the 20 active committers, 11 come from IBM.) It is characteristic of IBM's dominance within Eclipse, that almost solely the IBM-led components made it into the Eclipse 4.0 SDK – XWT, Toolkit Model and other subprojects currently remain in the e4 incubator.
The question remains: Will Eclipse once again land a coup (as they have done previously with Eclipse 3.0 and the OSGi-based Equinox Platform,) or is e4 just Eclipse presenting something new to the community, in the hope of maintaining interest in Eclipse?