So Long, and Thanks for All the Fish

Current and future viability of Eclipse

No, this is not another farewell. We have had too many of them over the last few years. Following the recent discussion [1][2][3] about Eclipse Juno one can get the impression that Eclipse is going to be “demolished” anytime soon to make space for a new hyperspace bypass. Reality is, there is no new hyperspace bypass. Not even a plan for one*. Eclipse is the market leading IDE, and receives millions of downloads with a trend going up. The dolphins can stay another decade. But how is it possible that a) the internal community is shrinking b) people are getting criticized for their open source work?

EclipseDownloadTrend So Long, and Thanks for All the Fish

Open Source is not a business model in itself
Historically the Eclipse Platform and the exemplary Java IDE has been built by IBM engineers. There was a clear business model for IBM, because the Eclipse platform serves as the foundation for 300+ tools that IBM is selling to its customers in one or another way. And the Java Developer tools demonstrated the “best practice” in using the platform. This has been working very nicely for the last decade. But something must have changed for IBM because they are putting less energy into Eclipse as a platform. That is nothing that we can or should blame them for, they are a commercial company and need to optimize their profit.

Eclipse describes itself always as an “ecosystem”, so why are there no other companies stepping up to close the gap IBM’s change in strategy is leaving? Because the ecosystem is not making money with the platform and the Java Developer tools. Millions of users are using the – good enough – tools that they can get for free. The ecosystem is making its money with extending Eclipse for various use cases and industries ranging from aviation to utility.

No more satisfaction
Now some of the users of the free tools are less satisfied with Eclipse Juno. We could argue that we don’t care, because there is no claim for perfection attached to the free and open source tools. But that could start a downward spiral for Eclipse many community members seem to be afraid of.

Who is going to pay?
Bottom line is: Some new people will have to pay if we want to put more work into core pieces of Eclipse again. The proposal to put a toll on the companies participating as strategic members is likely not going to work out – as described before they are not making their money with the free tools. But why shouldn’t the users that profit the most from the free tools pay a share for developing and maintaining them. Before you cry foul – “Eclipse is open source and needs to remain free for everyone” – let me explain where I think we should be heading.

There are hundreds of companies out there that have saved big bucks by switching from commercial tools to open source. From my point of view we should involve them in paying for the Eclipse platform and the Java IDE. But we have to offer something that you can’t get for free, otherwise they are not going to pay (there are a few notable exceptions of companies that strategically invested into the health of Eclipse). Paying for maintenance and support is an established Open Source Business Model and we will be giving it a try. With “we” I mean a group formed of the Eclipse Foundation and ecosystem companies that have agreed to start the “Long Term Support (LTS) Working Group“. Because Eclipse provides a really broad set of technologies no single company is able to support the entire breadth of Eclipse. The Eclipse Foundation will orchestrate LTS and provide the infrastructure, and companies of different size and different technology skills will provide the support. As a company you can get the “claim” that is missing from Open Source, and the resulting work will remain open source. Sounds like a “win-win” for everybody, doesn’t it? Expect to hear more about Eclipse LTS very soon.

* One could argue that JavaScript and the trend towards html is removing the necessity of an IDE. But if you look at the Tiobe Programming community index or Redmonks programming language rankings it is obvious that there are still a lot of people in need of an IDE. Unless you are a super geek you shouldn’t develop Java and C without a tool suite IMHO.

Resources:
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=385272 Bug on Eclipse Juno Performance Issue
[2] http://mmilinkov.wordpress.com/2012/09/10/juno-performance/ Mike Milinkovich on Eclipse Juno Performance
[3] http://www.jroller.com/andyl/entry/something_is_really_broken_with Andrey Loskutov on Eclipse Juno
[4] http://www.imdb.com/title/tt0371724/quotes – The Hitchhikers guide to the galaxy – quotes
[5] http://wiki.eclipse.org/LTS/Charter – Eclipse LTS Charter
[6] http://de.slideshare.net/KarstenSchmidt1/econ-2011-eclipse-lts EclipseCon slides on Eclipse LTS
[7] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html – Tiobe Programming Community Index
[8] http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12/ Redmonk Programming Language Rankings

6 Responses to “So Long, and Thanks for All the Fish”

  1. Andrey Loskutov says:

    Interesting article, promising program, but until now I still don’t see really good value for money for LTS members (according to LTS charta in [5]). Might be I’m missing something, but the is a MSP role described, with no appropriate link to anything under “services and activities”.

    Especially unclear is this sentence: “It is expected that MSPs and SSMPs will aggregate the services of PSPs to provide maintenance services to Consumers, or in the case of SSMPs, to themselves.” What “maintenance services”? For *extra* money on top of 50.000$/year?

    There is nothing one can’t get already or one would need at all. Forge? Bug tracker? Builds? Documentation? Most of it is already doable/available/not needed and so gives my high level management no reason why we need to spend extra 40-50.000$/year.

    What I’m missing is the simple answer to one question: how one LTS member company can make sure that its 50.000$/year spent to fix for 5 very specific, serious Eclipse platform bugs/features per year. This is of course an example, but I hope the basic idea is clear. I don’t even request a private build/sign for that – just that the bugs get fixed and code gets committed to the central Git repo.

    If LTS charta would give us such an answer, I would make everything possible to make sure my company will participate in LTS at least as a premium member. Otherwise I don’t see any chance for me to get money for that.

    May be few simple “use case” examples would help to understand what real value the participating members will have from LTS.

  2. Andrew Ross says:

    In fairness, $50K sounds high, because it is the highest possible total for combined Solutions membership & LTS IWG dues for the largest companies (over $250M in annual revenues). $3K is the opposite end of the spectrum.

    Being an LTS member lets you use employees or contract maintenance committers to work on precisely what you care about. You also get the fixes you didn’t directly pay for as a bonus… all ready to go from the LTS members git source code repositories or binaries from the download site.

    Alternatively, you can approach an LTS member and pay them to fix the items you care about. In so doing, enabling a business model for them to justify their dues & efforts. Chances are they are selling their services to more than just you to be as profitable as they can.

    Hope this helps!

  3. Jochen Krause says:

    Hi Andrey,

    Thanks for your valuable feedback. Pointing to the LTS charter without further explanation was probably not a good idea, as it is pretty cryptic and really not self explanatory.

    LTS is meant to enable Support offerings – it is not the support offering itself. There will be a matrix of projects and support providers – and companies that integrate support for multiple projects. The pricetag in the charter is for companies that want to provide support , not for companies that want to consume support. The notable exception are the “Self Service Providers”, companies with a significant investment into Eclipse that want to use the support infrastructure internally.

    The end user pricing will largely depend on the SLAs you require, but for 5 platform bugs it should be significantly less than 50k.

  4. Aaron Digulla says:

    Excellent idea. From my experience, there are two problems with open source: Important bugs aren’t sexy (too complex, too boring, too much work, high risk, lot of friction) and free (as in freedom) != free (as in beer).

    Open Source just means “you get the source” not “you get it for free.” Unfortunately, we’re all guilty in making people believe that “free == free” (since you don’t have to pay anything when you download Eclipse) and the Open Source wouldn’t really work if there was a “Pay via…” button instead of a download link.

    For the AROS project, we created a web site where you could pledge money for a certain bug. Kind of a per-bug kickstarter. That way, users could create an incentive to fix their most pressing issues. If someone big stepped in, they could get any bug fixed they wanted by simply paying the for fix as if they were contracting someone.

  5. Eric Moffatt says:

    Jochen, thanks for the post…it’s very close to what I might have written (had I the time…;-). You’ve hit the nail pretty well on the head IMO, I too wonder why larger corporations that gain substantial advantages from using eclipse seem unwilling to give back by providing a committer or two to the base components (SWT, Platform and JDT). I do understand that many of these companies do contribute to other areas of the ecosystem but without a solid foundation to run them on it seems to make little sense (ok, I’m biased).

    We are all committed to providing the best that we can but of late the pace is simply crushing those of us left, mostly because we *do* care deeply about eclipse. This is a serious issue, we’re currently in a position that is, simply put, unsustainable. I of course have no answers as to how we proceed, I just push pixels but sincerely hope that some mechanism to inject new resources can be found before we all burn out.

  6. Jochen Krause says:

    Eric, We are planning to finally launch LTS in November and I am curious on the uptake. It will provide another mean than providing a committer to adopters that care about Eclipse as a platform. Paying money for maintenance and support is a much more established practice than providing committers at non-development organizations like financial institutions. I hope we will be able to inject new resources into the eco-system and provide some relief to the platform team.

6 responses so far

Written by . Published in Categories: EclipseSource News, Planet Eclipse