After much thought I'd like to give my personal recommendation to the community.
As explained in other posts, I think a neutral foundation is the way to go.
As I see it, the main question here is do we need a "full-service" foundation, or will one that provides mainly IP management be sufficient? I know I've oscillated a bit on this point as more information has become available, but my opinion now it's probably best for the project to go for the "full-service".
As Kohsuke pointed out, if we want a truly neutral project the natural conclusion of that is for all the project services to be neutral as well (repo, tracker, hosting etc). I'm sure we _could_ figure out a way to host them ourselves that doesn't have any bias to any particular organisation or individual, but frankly it's a headache. I also think that some kind of project governance that can help prevent committers or project leads going rogue is probably a good idea.
For me, that means we're left with ASF and Eclipse. I've stated on other posts that I am not a huge fan of the ASF voting process, especially the veto, and the weaker notion of project leadership. I also think Eclipse is perhaps a little more "business friendly" and that's going to be an important thing for Vert.x as we progress if we want to get a foothold in large enterprises.
Therefore my recommendation to the community is that the project is proposed for inclusion in the Eclipse Foundation.
On Thursday, 10 January 2013 09:58:38 UTC, 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.