The Eclipse Long-Term Support Concept
Jochen Krause, EclipseSource
Karsten Schmidt, SAP AG
Eclipse Summit Europe, Ludwigsburg
November 2010
Introduction
Eclipse has always targeted commercial usage
But discrepancy between lifecycles
Early 2009: we triggeredthe 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
Eclipse is mainstream in many industries
Luckily we are not (yet) flying
But even systems engineering tools have a need for looong maintenance
We are also moving into thecomputing centers ...
Equinox, Riena, Virgo, Gemini, RAP, EclipseLink, ....
On the server you care about support
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
Yawn – yet another support strategy for open source?
Eclipse long term support is different
We do it the Open Source Way!
No vendor lock-in
Source code is Open Source under EPL
All fixes are visible and available foreveryone – fix each bug only once!
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
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
Most companies have committers in only a few projects
Projects1 2 3 4 5 6 7 8 9 10
Current release
Most companies have committers in only a few projects
Projects1 2 3 4 5 6 7 8 9 10
Current release
Company A Company B Company C Company D Company E
Most projects have committers from only a few companies
Projects1 2 3 4 5 6 7 8 9 10
Current release
Company A Company B Company C Company D Company E
Many commercial products use many projects ...
Projects1 2 3 4 5 6 7 8 9 10
Current release
Product X Product Y
... leading to many small support contracts
Projects1 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
Most companies offer support for only few releases back
Projects1 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
Customers have support obligations for many years
Projects1 2 3 4 5 6 7 8 9 10
Current release
Cr -1
Cr - 2
Cr - 3
...
Cr - many ?
Slide fromEclipseCon 2010
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
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
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!
Recommended
