Open source governance is an important issue that is sometimes overlooked or misunderstood by new open source projects. This week there has been a fascinating discussion on the future of the vert.x project that illustrates the need and options for governing an open source project. Unlike some discussions on this topic, the key participants are respectful, logical and very articulate. It is really an insightful case study, some hightlights:
1. The Need – Who owns and controls what?
The discussions started when Tim Fox, vert.x project leaders and creator, left VMWare and joined Red Hat. VMWare lawyers sent Tim a letter claiming ownership to the vert.x trademark and requesting control of the vert.x web properties.
No one likes getting these types of letters and you could make the argument VMWare could have taken a different approach. However, it does illustrate that every open source project has an individual(s) or organization(s) that owns the trademark, source code copyright, domain name, and controls the source code repository, web site, etc. A ‘community’ or ‘project’ are typically not legal entities so they can’t own anything in a legal sense.
2. The Options
Tim does a great job documenting the options he has for proceeding.
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.
Options 1 implies that the “Project” is hosted at a legal entity, like SPI or SFC, to own in trust the Vert.x name. Surprisingly, it turns out Netty is not hosted at either. Option 2 is always a hard decision, especially for fast growing projects like Vert.x. Options 3 & 4 introduce a different culture and process to the Vert.x project.
- Option 1. Bradley Kuhn details how the Software Freedom Conservancy operates.
- Option 2. Kohsuke Kawaguchi, the Jenkins project leader, describes the approach used for creating Jenkins, which was a fork of Hudson. [Full disclosure: Hudson is now an Eclipse project] KK’s comments about the need for governance so the project leader doesn’t go rogue highlights even this option requires good governance.
- Option 3: Mike Milinkovich describe how Eclipse works and addresses some of the CLA and process issues.
- Option 4: Jim Jagielski and Norman Maurer describe the Apache Way.
We are a Vegas gaming company and we gamble, but not that type of gamble.
