June 12, 2012
This industry working group charter is governed by the Eclipse Foundation Industry Working Group Process document.
Adoption of Eclipse tools and runtimes has reached an all time high, and today Eclipse software is embedded into many commercial software products. Enterprise software vendors are required to support their products, including the Eclipse components, for many years. Thus they are looking for support offerings that cover a variety of Eclipse projects and a large number of releases. The issue becomes more urgent the more Eclipse technology reaches into the runtime stack.
Due to the diversity of projects and committers at Eclipse, which come from a variety of companies and individuals, it is currently impossible to get a 'one-stop-support-contract' for all of Eclipse technologies needed. Vendor neutrality and diversity bring innovation and long term viability to Eclipse, but make it difficult to provide the support enterprises are looking for. It is very difficult for any one company in the Eclipse ecosystem to offer support and maintenance that covers the entire spectrum of Eclipse technologies.
Goals and Vision
The goal of the Long Term Support (LTS) Industry Working Group (IWG) is to enable the Eclipse ecosystem to consume and provide maintenance and support for the full breadth of Eclipse technologies.
To implement this vision, the IWG will:
- Enable an ecosystem-based solution for long term support and maintenance.
- Define and implement the policies, procedures and infrastructure required for long term support and maintenance, including software repositories, software builds, software distribution, and test facilities.
- Define a roadmap for LTS deliverables.
If agreed to by the Steering Committee, create and define the content to be contained in LTS releases, including:
- defining an LTS release branch based on an Eclipse release train, and
- the content of LTS service releases.
There are 4 roles in this ecosystem:
- Consumers are organizations that acquire maintenance and support services.
- Maintenance Service Providers(MSPs) leverage the IWG systems to provide commercial support and maintenance services to Consumers.
- self Service Maintenance Providers(SSMPs) are Consumers that leverage the IWG systems to provide internal support and maintenance services.
- Project Support Providers(PSPs) are organizations or individuals that leverage the IWG systems to provide support and maintenance services for one or more Eclipse projects.
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.
Core services and activities
- The LTS IWG will provide the management processes to enable an ecosystem-based long-term support program.
LTS provides a forge that enables building Eclipse software in the future for maintenance and support. The forge will include:
- Code repositories
- Bug tracking
- Knowledge management
- Software distribution and code signing
- Employees and contractors of organizations participating in this LTS IWG will have access LTS IWG facilities based on that organization's participation level as described in the Membership section below.
Connections with other Eclipse Working Groups
The LTS IWG may have connections with other IWGs such as Polarsys, Automotive, and others.
Additional industry working groups may request access to the LTS infrastructure in the future. Such access, including funding and annual fees, will require the approval of the LTS IWG Steering Committee.
An entity must be at least a Solutions Members of the Eclipse Foundation, have executed the LTS IWG Participation Agreement, and conform to this Charter to participate in the LTS IWG.
There are four membership levels: Guest, Participant, Premium, and, Steering Committee.
Guest Members are organizations who have been invited by the Steering Committee of LTS WG for a 6 month Guest Membership. . Typical guests are potential future full-fledged members who want to have a closer look before deciding on their strategy. Guest members are required to sign a participation agreement and they do not have voting rights in LTS WG meetings. Guest members will have the same access rights as Premium members for the duration of their membership. At the end of the 12 month trial period their access rights will be terminated.
Participant members have access to the download site providing LTS binaries.
Premium members have Participant level access as well as access to the LTS forge and build farm.
Steering Committee members have Premium level access and also governance influence over the direction of the IWG such as budget and resource allocation
|Privilege||Guest Member*||Participant Member||Premium Member||Steering Committee|
|Access to binary releases||x||x||x||x|
|Attend WG meetings||x||x||x||x|
|Access to the LTS build and signing infrastructure||x||x||x|
|Host custom branch on LTS infrastructure||x||x||x|
|Host custom build on LTS infrastructure||x||x||x|
|Member of Change Control Board||x|
|Member of Steering Committee||x|
*Guest Member privileges last only for the duration of their 12 month trial period.
LTS Member Fee Structure
LTS Guest Member Fees
LTS Partcipant Member Fees
LTS Premium Member Fees
LTS Steering Committee Member Fees
This Long Term Support IWG is designed as:
- a user driven organization,
- a means to foster a vibrant and sustainable ecosystem of components and service providers,
- a means to organize the community of each project or component so that users and developers can define and provide maintenance content collaboratively.
In order to implement these principles, the following governance bodies have been defined:
- The Steering Committee
- Change Control Boards
Steering committee members are required to:
- define the strategy of the IWG,
- define an annual program plan and budget, including the setting of annual LTS IWG dues,
- define support durations for LTS and VLTS (Very Long Term Support),
- define additional membership levels for the IWG,
- define the global roadmap,
- discuss and update the charter,
- manage the creation, operation, and termination of Change Control Boards,
- define and implement marketing and communication activities,
- elect a chairman each year, and
- meet a minimum of twice per year.
Each service release defined by the roadmap is led by a Change Control Board.
Change Control Boards members are required to:
- create and maintain a plan, to be approved by the Steering Committee,
- prioritize and approve all software changes to be included in each service release, and
- report regularly to the Steering Committee on status.
The Change Control Board elects a chairman who represents the projects.
Each Change Control Board will be disbanded once the service release under its control has been released.