This document discusses establishing long term support for Eclipse projects. It notes that while Eclipse targets commercial usage, the lifecycles of Eclipse releases and organizations' support needs do not always align. It proposes the Eclipse LTS concept, where system integrators would act as "general contractors" to provide long term support across multiple Eclipse projects through a single contract. This would benefit customers, system integrators, and support companies. It aims to have the LTS infrastructure in place by the end of 2011 in a way that maintains Eclipse's open source principles.

1. Establishing Long Term
Support for Eclipse
Jochen Krause, EclipseSource
Karsten Schmidt, SAP AG

2. Introduction
Eclipse has always targeted commercial usage
But discrepancy between lifecycles
Early 2009: we triggered
the discussion at Eclipse
Early 2010: Board of
Directors Working Group
June 2010: Board
approved proposal
Goal: have it up and
running by end of 2011 Commercial approach: business
opportunities for the ecosystem

3. Eclipse is mainstream in many industries

4. Luckily we are not (yet) flying

5. But even systems engineering tools
have a need for looong maintenance

6. We are also moving into the
computing centers ...

7. Equinox, Riena, Virgo, Gemini, RAP,
EclipseLink, ....

8. On the server you care about support

9. The Lifecycle Challenge
Major Eclipse release each year
– Two support releases in the following 9 months
No service releases beyond SR2
– Organizations requiring support beyond a year
need to find a third party or do it themselves

10. Yawn – yet another support strategy for
open source?

11. Eclipse long term support is
different

12. We do it the Open Source Way!
No vendor lock-in
Source code is Open Source under EPL
All fixes are visible and available for
everyone – fix each bug only once!

13. Source Control and Versioning
• Source code is Open Source under EPL
• Anyone can find and download the patches
• Optional branching for critical fixes
Build Infrastructure
• Out-of-the-box build infrastructure also for old releases
Bugzilla
• The same issue tracking as for the dev codeline
IP process, signing of archives
• Generate the trust associated with the Eclipse brand by running the
IP process and by signing the archives
• Binaries will only be available to participating companies
Central Infrastructure run by the
Eclipse Foundation

14. Maintenance Committers
Today: Only Committers can check in
source code
LTS: Concept of „Maintenance Committers“
• ... are nominated by companies
• ... do not have to be committers (but all
committers are maintenance committers)
• ... may check in code into maintenance
codelines, not into dev codeline
• But: each patch must be offered to the
committers to be included in the dev
codeline

15. Most companies have committers in
only a few projects
Projects
1 2 3 4 5 6 7 8 9 10
Current release

16. Most companies have committers in
only a few projects
Projects
1 2 3 4 5 6 7 8 9 10
Current release
Company A Company B Company C Company D Company E

17. Most projects have committers from
only a few companies
Projects
1 2 3 4 5 6 7 8 9 10
Current release
Company A Company B Company C Company D Company E

18. Many commercial products use many
projects ...
Projects
1 2 3 4 5 6 7 8 9 10
Current release
Product X Product Y

19. ... leading to many small support
contracts
Projects
1 2 3 4 5 6 7 8 9 10
Current release
Company A Company B Company C Company D Company E
Customer X Customer Y
Product X Product Y

20. Most companies offer support for only
few releases back
Projects
1 2 3 4 5 6 7 8 9 10
Current release
Cr -1
Cr - 2
Company A Company B Company C Company D Company E

21. Customers have support obligations
for many years
Projects
1 2 3 4 5 6 7 8 9 10
Current release
Cr -1
Cr - 2
Cr - 3
...
Cr - many ?
Slide from
EclipseCon 2010

22. The Eclipse LTS Concept (1):
System Integrators as „General Contractors“
Company A Company B Company C Company D Company E
Customer X Customer YCustomer W Customer Z
SI 1 SI 2

23. The Business Model
• Customer benefits
– One contract partner, all customers share the costs
– No vendor lock-in
• SIs benefits
– Access to Open Source support infrastructure and Know-How
– Bundling of the otherwise fragmented OSS support market
• Support companies: Get a shop-in-shop effect
– Can get into business with their Know-How (committership)
– Significantly lower infrastructure investments
• Eclipse Foundation
– Additional revenue through fees for central infrastructure
– Key differentiator compared to other OSS organizations

24. Outlook / Next Steps
• Eclipse Foundation has begun to collect input from
potential customers, „General Contractors“, Companies
offering project support
• Concept to be refined, based on the feedback
• All input from YOU is highly appreciated
• Plan: have the infrastructure up and running by end of
2011
A well-structured Long-Term Support infrastructure,
based on Open Source principles, could become a key
differentiator for the Eclipse ecosystem!

25. Thank you!
jkrause@eclipsesource.com
k.schmidt@sap.com