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
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?
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!
