OpenStack, the open source "cloud operating system," is really a dozen different projects to standardize management of virtualized data center resources. This week also saw steps toward the first elected board of directors for the OpenStack Foundation. It's a community with very high market stakes; consequently, high politics can be expected. It's been no surprise to see signs of submerged gameplay, with allegations of threats against board candidates, as well as a wide, diverse, and in some cases surprising set of nominations.
OpenStack has always been a project living in the shadow of Rackspace. Last year, exactly that issue led to the resignation of its community manager, who alleged:
I think that Rackspace is trying to control Openstack rather than influence it. A perfect example is the recent change in governance. ... Rackspace has a choice to make; they can try to control the project and eventually fail, or they choose to influence it and succeed.
Though Rackspace took Rick's advice in the intervening year and started a foundation, sources suggest to me that a desire for control is still a problem, both in the current governance rules and in the list of candidates for the future executive director of the foundation. But it's now exacerbated by the arrival of a set of political professionals who know a thing or two about gaming processes and jockeying for control.
I fear the board nomination shenanigans we've seen over the last week or so are just the start of a process that is unlikely to be fixed until there's a clear separation of influence of the kind found in the Eclipse project. At Eclipse, the corporate sponsors have their board seats, and they discuss budgets, brands, and software industry politics, while the technical teams have their own leadership. Decoupling the two, along with clever governance rules in both parts, has rendered the powerful political forces at work in Eclipse unable to disrupt the technical direction.
Control vs. influence
OmniOS, GitHub, and OpenStack together illustrate the difference between destructive impact of control and the positive effects of influence. Contributors to open source projects are motivated by a passion for technology and do not appreciate attempts at unilateral control -- either from misguided community leaders or from vendor patrons with too much power. Attempts at control are a form of damage that the mesh of developer relationships routes around. Once the distorting effects of commercial business models are no longer directly imposed, the empowerment of the software freedom brought by open source is allowed to flourish.
Open source can be defined as the co-development of software by a community of people who choose to align a fragment of their self-interest in order to do something that would be almost impossible in isolation. The community members each work at their own (or their employers') expense in order to achieve a shared outcome that benefits all, including themselves. When they create an enhancement, fix a defect, or participate in a design, they are not "working for free" or "donating their work" so much as they are "participating in co-development." In other words, they influence the project by contribution and reputation.
Relaxing control leads to community growth and innovation -- often in directions that could never have been anticipated. The guiding principle that works for all open source communities is thus: Trade control for influence, because in a meshed society, control gets marginalized and influence delivers success. Your mileage will vary depending on the project, but this basic principle has remained the same for as long as I can remember.
This article, "OpenStack, GitHub, OmniOS: 3 projects, 1 lesson," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.