Google Groups

Re: Discussion: The future of the Vert.x project

Mike Milinkovich Jan 10, 2013 5:57 AM
Posted in group: vert.x

I understand your point of view and preferences. I am here to try to help explain how Eclipse works. I hope you find it useful.

There are a few misconceptions about Eclipse below that I will try to address. Eclipse and Apache have a lot in common, in that we uphold the core values of openness, transparency and meritocracy. However, there are important differences between the two cultures that a lot of people don't realize.

On Thursday, January 10, 2013 4:58:38 AM UTC-5, Tim Fox wrote:
The IP for the project gets signed over or licensed to the neutral entity.

That's not entirely correct at Eclipse. The project names (e.g. trademarks) for Eclipse projects have to be assigned to Eclipse. But the ownership of the copyrights and patents don't come to Eclipse. We also do not require CLAs at Eclipse. So unlike a lot of organizations, we don't aggregate all of the IP at the Foundation.We rely on symmetrical inbound and outbound licensing.

Both foundations mandate fairly complex development processes that relies on consensus amongst committers in order for changes to made. 

"Fairly complex" is fair comment. But the Eclipse process does not require consensus for commits. People who have commit status can commit code. Of course if they screw something up, they hear about it :).  Eclipse projects also actually have clear project leaders who are expected to run the project. Our Project Management Committees (PMCs) are also quite small and well-defined groups. 

In other words, our development process is calibrated to be in the middle of the "benevolent dictator" model and the "everything is a consensus" model.

If we went down this path I assume both VMW and RHT would want to have committer representatives on the team. For this setup to work, it requires trust and co-operation between the committers. Without trust the project could easily grind to halt as changes from one committer are vetoed by other committers with conflicting agendas.

The initial project leader and list of committers for Eclipse projects are defined in the project proposal. Unlike Apache, existing members of the Eclipse community do *not* get to join the project at startup. A new project does need to find two mentors from the Architecture Council to assist them in learning and navigating the Eclipse processes. Mentors do not get commit rights.

Once a project is established, the only way in is via meritocracy. E.g. a contributor who wants to become a committer has to demonstrate a history of contribution, be nominated by an existing committer, and be voted in by the existing committers on the project. And as I said above, committers at Eclipse don't get to veto other committers changes. The project leader can kick some butt if necessary, but it happens exceedingly rarely.


For me, personally, to seriously consider 3) or 4) as an option then the current poor atmosphere would need to be fixed, or it's simply not going to work...

Amen to that. Trust is the bedrock of any community.