Contents

Why forges?

We have been quite successful for many years running a single forge with a single set of rules. Why do we now have separate forges?

Eclipse is becoming a community of communities. What we have learned over the years with Eclipse is that the combination of a meritocratic open source community with an engaged commercial ecosystem works extremely well. However, as Eclipse has grown, it has become obvious that we need to have mechanisms to repeat that successful combinations for groups of projects and Member companies who want to focus on a particular domain. As a result, we created the notion of working groups. Some (not all) working groups would like to have separate forges to support their community.

Branding is part of the reason. Different communities gain strength from having a separate identity that they can rally around. A community like LocationTech, for example, might find the strong tools focus synonymous with Eclipse difficult to overcome.

Licensing is occasionally a reason to keep things separate. The Eclipse brand is very closely associated with commercially-friendly licenses like the EPL, EDL(BSD), etc. Eclipse projects are limited in terms of the licenses that they can use, both in code produced and in third-party code that is leveraged and distributed. As we attract new communities, some of them require use of a broader range of licenses. LocationTech and PolarSys, for example, both permit the use of libraries licensed under LGPL.

Ownership

In the broadest sense, all forges are owned by a Working Group (with the exception of the eclipse.org forge). All forges are managed by the Eclipse Foundation staff with a designated Eclipse Foundation Staff sponsor. The sponsor is responsible for the smooth running of the forge identity, which includes such things as content and overall management of any web properties included in the forge.

Technical issues regarding a forge should be addressed to the Eclipse Webmaster via Bugzilla.

Authentication and Authorization

User authentication is done via a single Eclipse Foundation account. With an account, a user can log into any Eclipse Foundation-managed forge. Authorization is managed within the forges via relationships defined in the Project Management Infrastructure (this is not strictly true: project/committer relationships are mirrored in LDAP).

Overall Structure

Forge

Each forge has a distinct Bugzilla instance for issue tracking, along with a wiki, VCS, and an instance of the Project Management Infrastructure (which is shown as two separate boxes in the diagram).

The various services use the shared LDAP for authorization.

The "committer" (CM) roles managed by the PMI feed into the shared LDAP by way of populating groups associated with the projects.

LDAP groups are used to authorize users against the various technologies

Eclipse Foundation

Individuals have a relationship with the Eclipse Foundation.

Single set of sign-on credentials that are used to authenticate with various Eclipse properties;

Basic personal information, including postal address, phone number and organization affiliation; and

Individual Documents (e.g. CLA, MCA/ICA, ECF)

Forges are not legal entities. The Eclipse Foundation is the legal entity.

All trademarks are held by the Eclipse Foundation.

Existing Forges

Eclipse

Eclipse is a community of open source projects. Eclipse projects cover runtimes; static and dynamic languages; thick-client, thin-client, and server-side frameworks; modeling and business reporting; embedded and mobile; and, yes, we have world-class Java IDE.