Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Multiple forges at the Eclipse Foundation


the last months I become more and more aware that Eclipse Foundation can be best described
by a set of principles or rules that allow organizations to collaborate on a neutral ground
with rules that are open source and business friendly. Those rules are centered around a
model of collaboration. The "three laws of eclipse" are a description of those rules:

I think if there are industries that want to build vendor neutral business friendly
open source projects the Eclipse Foundation should be the first address....

The idea of different forges makes a lot of sense, because it allows to host
different "interest groups" under the same guiding principles of the Eclipse

Is this something the Eclipse Foundation could "advertize": we are the place
if you need a business friendly, IP clean set-up for open source projects?


While entering a new bug for mentors, it occurred to me that the relationship between the Eclipse Architecture Council and the various forges hasn't been fully discussed.

By way of background, the Eclipse Foundation has branched out and is now hosting multiple "forges". As part of this, we (the Eclipse Foundation staff) have started to distinguish between "The Eclipse Foundation" and "". The
Eclipse Foundation is the organization; is the forge.

As of today, there are three forges managed by the Eclipse Foundation:

Each of these forges has its own website, Git repositories, Bugzilla instance, mailman, and forums.

These forges have considerable overlap. All forges use the same development process (EDP), and same IP Policy. The EPL is the main license for all forges. All forges share a single IPZilla instance. We also (internally) have a single system
that we use for managing all the various documents that committers are required to provide. A committer in one forge does not need new documentation to become a committer in a different Eclipse Foundation-managed forge.

The webmaster is currently working on consolidating the separate forges into a single LDAP instance. With this, we're changing the notion of having an "" account to that of having an "Eclipse Foundation" account. With that single
Eclipse Foundation account, you can authenticate on any of the forges. The rights that you have on the forges depends on  your roles in that forge. You still need to be a committer on a project to make any changes to project metadata, for
example. In practical terms, this change should have no impact on any existing Eclipse committers.

*Here's the important bit. */The forges also share councils/. There is one Eclipse Foundation Planning Council and one Eclipse Foundation Architecture Council. As time progresses, people from these other forges will be nominated to the
councils based on the exact same set of conditions that guide nominations from the community. These people will be natural choices to be mentors for new projects created in their respective forges. In the meantime, we need to
lean on the existing members to help bootstrap the new projects that are starting to trickle into the new forges.

For all practical purposes, mentoring a or project is no different than mentoring an project.

I am working on a web page that describes this with detail and fancy pictures.

As always, please let me know if you have any questions.


Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation <>
Learn about Eclipse Projects <>
EclipseCon France 2013 <>

_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top