The community discussion of the Vert.x open source project was just starting when I wrote about it last week. Conducted entirely on the mailing list as a result of all the press the Vert.x dustup received, this group conversation has launched an educational parade of governance solutions.
I've had a deep interest in open source community governance for years; indeed, several years ago I sketched out a benchmark for comparing governance approaches. Community governance matters because when disputes arise it's important that every good-faith community participant has a right to join in the resolution. Many developers feel licensing and governance are a bureaucratic make-work nuisance imposed by an aging generation trying to retain control over software. But projects that neglect or ignore licensing and governance can discover too late how important it is.
[ Also on InfoWorld: Who controls Vert.x: Red Hat, VMware, or neither?. | Track the latest trends in open source with InfoWorld's Technology: Open Source newsletter. ]
Without shared ownership of concrete assets like copyrights and trademarks, as well as social assets (access right approvals, feature selection, and release management), times of crisis become opportunities for overprivileged community members to make self-serving fiat decisions at the expense of community members. The results can be forks or the departure of community members, and ironically those with control frequently find they lose more than they gain as the community evaporates.
The time to pick licenses and governance styles is early, before the arrival of existential crises, so the actions of Vert.x project leader Tim Fox in calling out the risk of covert corporate carve-ups are paying off. While some researchers are experimenting with automatic analysis of governance, the best way to compare and contrast today is to ask community members about their communities. It's worth tracing the path Vert.x has taken. Reading the thread will introduce you to the three main ideas the Vert.x community considered and illustrate some of the many governance choices available.
A community journey
Faced with the perception that VMware wanted to retain control at all costs, the first option the community considered was to create a fork and continue the existing approach independently. But it quickly became obvious that a fork was neither necessary nor helpful because VMware did not want to retain control of the project at all costs.
The next option considered was to run the project as it is now -- using GitHub as the host -- but trust concrete assets to a nonprofit foundation. Possible hosts for those assets included Software in the Public Interest (SPI), one of the oldest open source nonprofits, formed to host assets for the Debian project.
It gradually became apparent, however, that Vert.x needed a steward for more than just the concrete assets of the community. With two strong companies already involved -- Red Hat and VMware -- and the evident interest of more, the need for a guarantor of social assets became clear. Indeed, it was concern over who would have ultimate control over participation and contribution that lay behind Tim Fox's original posting. The conversation turned to understanding "full service" foundations, involving a governance methodology, a community philosophy, and concrete asset stewardship.