http://www.infoworld.com/d/open-source-software/fork-vmware-open-source-triumphs-again-211029
As the Vert.x community selects its future home, it offers a fascinating illustration of the role of governance
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.
Both the Apache Software Foundation and the Eclipse Foundation were proposed early in the discussion, and much of the later discussion involved understanding the nature of these two foundations. Both are large communities with proven approaches, and they have much in common. Both have strong policies on ensuring cleanliness of the copyright provenance on all contributions, for example.
They differ in important ways, though. The deepest difference is their nonprofit type. Apache is a public-benefit nonprofit, registered with the IRS as such and able to accept tax-deductible donations. Eclipse is a member-benefit nonprofit; as such, its IRS registration does not allow tax deduction by donors.
Decision time
This difference goes beyond taxes to community ethos. Eclipse formally includes businesses in its governance and recognizes the affiliations of contributors, while Apache allows only contributors to engage in its governance and encourages hiding of affiliation.
In the end, it was probably this difference that settled the decision, and on Wednesday Tim Fox recommended that the community move to the Eclipse Foundation, saying, "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."
Issues remain. Vert.x uses the permissive Apache License, and the Eclipse community will need to agree to an exception to its normal policy of using the copyleft Eclipse Public License. VMware will need to follow through on its commitment to donate the trademarks to Eclipse and satisfy its copyright provenance rules. Various members are concerned by the need to move the Git repository from GitHub to Eclipse, so contribution ownership tracking can be maintained. (GitHub does not offer this, although there's now a third-party solution.)
Hopefully these details will be sorted out. The whole experience has been educational, and I know many participants and readers have gleaned useful insights into the governance needs of a new open source community.
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.
Both the Apache Software Foundation and the Eclipse Foundation were proposed early in the discussion, and much of the later discussion involved understanding the nature of these two foundations. Both are large communities with proven approaches, and they have much in common. Both have strong policies on ensuring cleanliness of the copyright provenance on all contributions, for example.
They differ in important ways, though. The deepest difference is their nonprofit type. Apache is a public-benefit nonprofit, registered with the IRS as such and able to accept tax-deductible donations. Eclipse is a member-benefit nonprofit; as such, its IRS registration does not allow tax deduction by donors.
Decision time
This difference goes beyond taxes to community ethos. Eclipse formally includes businesses in its governance and recognizes the affiliations of contributors, while Apache allows only contributors to engage in its governance and encourages hiding of affiliation.
In the end, it was probably this difference that settled the decision, and on Wednesday Tim Fox recommended that the community move to the Eclipse Foundation, saying, "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."
Issues remain. Vert.x uses the permissive Apache License, and the Eclipse community will need to agree to an exception to its normal policy of using the copyleft Eclipse Public License. VMware will need to follow through on its commitment to donate the trademarks to Eclipse and satisfy its copyright provenance rules. Various members are concerned by the need to move the Git repository from GitHub to Eclipse, so contribution ownership tracking can be maintained. (GitHub does not offer this, although there's now a third-party solution.)
Hopefully these details will be sorted out. The whole experience has been educational, and I know many participants and readers have gleaned useful insights into the governance needs of a new open source community.
No comments:
Post a Comment