Mark is correct. I wanted to keep the project neutral. However, in Korea, it is pretty difficult for an individual to found a non-profit. Therefore, I applied for SFC membership because SFC takes care of legal and financial issues and let me focus on development. Unfortunately, it took eternity to get approval - I actually didn't get any response for the application.
Meanwhile, we assigned the copyright to the 'Project'. I'm not really sure about the legal ramifications, and I still wish there's a foundation similar to SFC which protects Netty.
Also referring to the useful info from Eclipse that Mark posted on the original announcement thread, there are a whole lot of benefits to going with Eclipse or ASF. Again I think from the perspective of those building on top of or using vert.x commercially, the governance and IP assurances are likely to be most valuable.
On Thursday, 10 January 2013 12:08:52 UTC, Tim Fox wrote:
On Thursday, 10 January 2013 11:18:04 UTC, Andy Piper wrote:
Something we should consider is that several folks have mentioned that they are building solutions and businesses on top of vert.x - which is fantastic - and that leads me to ask two important questions about governance and IP review / cleanliness of contributions.
I'm not sufficiently familiar with the "Netty-style solution" to know what guarantees exist there. Wouldn't the "Project" then need to deal with these things somehow independently?
As you can see grant of copyright license is made to the "Project" not to RHT, Twitter or <some_other_company>
I guess you can think of this is a "lightweight neutral organisation". I won't pretend to understand all the details and ramifications since ianal.
Setting aside the fork option, as it also doesn't address those questions, and also in my view would be a shame... that leaves a Foundation-based solution.
It's no secret that I'm an Eclipse committer, and I'm slightly biased in that direction mostly because I'm familiar with it.
In fact I found myself in a similar (but far from identical) situation a year ago when I left IBM but wanted to continue to contribute and lead the community for what was otherwise a somewhat IBM-heavy project, which has since diversified. I've been able to do that without significant issues or loss of "agility". Organisations generally like to consume and re-use Eclipse code, there's a good IP and governance process in place.
That said I've also worked with Apache (in fact I became friends with Pid through that community) and know that it's good some good structures in place as well.
So, +1 for moving to a Foundation, to enable continued independence, with governance and IP review to assure folks that the project isn't going away, and that the code has been well-reviewed.
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.