I won't try to "sell" you or anyone on the ASF. That's not how we work. I do think that the ASF would be a great home for the project, and it would be joining a large and growing list of ubiquitous FOSS projects, well known and well used in the entire web/cloud/IT community.
The advantages of 3 is that the ASF is truly individual and volunteer focused. It is a safe and neutral location for a project, and allows both volunteers are corporate-sponsored developers to work together, but ensuring that the *community* had control of the project. I also think that such a location would be a "safer" bet for VMware, and they would likely be more willing to have the ASF be the new home.
I would also encourage you and the community to make this decision. It is, or should be, yours to make. Also, make sure it's an *informed* decision, and not one based on FUD and biases, but on facts and on what's best for the project and the community.
On Thursday, January 10, 2013 4:58:38 AM UTC-5, Tim Fox wrote:
As promised, let's discuss the options for the long term future of the project.
I'll make an assumption that, until we come to a conclusion, VMware won't make any further unilateral changes to the way the project is administered or attempt to influence the decision in non public ways. If my assumption doesn't prove to be correct, all bets are off.
So, what are the options:
1) "Netty-style solution". In this solution almost everything continues as-is. The only difference is a CLA is crafted that grants rights of the contributions not to RHT or VMW, but to the "Project". This would require VMWare to grant a perpetual license to the "Project" for use of the name Vert.x.
2) Fork. We wouldn't have permission to use the name 'Vert.x' so we'd have to rename the project. That means removing all references to 'Vert.x' from the code, documentation, and other materials. We'd also lose the current github issues, the wiki, the blog, Google Group and domain. This would not require any permission from VMware.
3) Move project to Apache Software Foundation. This would need approval from ASF and VMware.
4) Move project to the Eclipse Foundation. This would need approval from the Eclipse Foundation and VMware.
Here is my personal opinion (as it currently stands) on the options:
My preferred option is 1) This has the least disruption to the project of all the options, but it requires VMW to grant a license. I proposed this before and it was refused. I would like to ask VMware to reconsider this. It would be by far the easier way to resolve this crisis. There is a very clear precedent for this succeeding in the real world. However, if VMware confirms that this is not an option, then we can remove it from the table.
Let me say a few words about moving to ASF or Eclipse: I don't know much about the fine details of the processes (I will learn more), but, aiui, they both follow a similar approach. The IP for the project gets signed over or licensed to the neutral entity. Both foundations mandate fairly complex development processes that relies on concensus amongst committers in order for changes to made.
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 problem right now, is there has been an almost complete breakdown of trust and communication between myself and VMW due the recent actions and subsequent behind the scenes political actions by certain parties.
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...
...and that would leave us with 2) Fork. This is the "Hudson vs Jenkins" option. Forking is a pain since we would lose the name, the github followers, the google group, the wiki and the blog. However I don't think it would be the end of the world. If we go down this route, I suggest that we do make a clean break down by continuing the project in the fork with the 2.0 release of the newly named project.