When does a software project grow to the point where one must explicitly think about governance? The term “governance” is stiff and gawky, but doing it well can carry a project through many a storm. Over the past couple years, the crucial OpenStack project has struggled with governance at least as much as with the technical and organizational issues of coordinating inputs from thousands of individuals and many companies.
A major milestone was the creation of the OpenStack Foundation, which I reported on in 2011. This event successfully started the participants’ engagement with the governance question, but it by no means resolved it. This past Monday, I attended some of the Open Cloud Day at O’Reilly’s Open Source convention, and talked to a lot of people working for or alongside the OpenStack Foundation about getting contributors to work together successfully in an open community.
When software is no longer just the domain of inquisitive college students and such, but comes mostly from large corporations (as commits to the Linux kernel now do), the risk of fake openness grows. I got a lesson in fake openness an embarrassingly long time ago when I worked for a company that was part of the Open Software Foundation (OSF).
The OSF was formed by major computer vendors in the 1980s as a defensive move, in reaction to a partnership between AT&T (the owner of UNIX) and Sun Microsystems (the most successful minicomputer vendor). The half-dozen leading member companies in the OSF agreed to combine their most advanced technologies to create interoperable products. They defined openness as interoperability, with no intention of providing open software as we know it today.
The companies’ actual strategy was to give the OSF a pile of crap (an appropriate technical term for the state of their software), take back the incompatible mess of overly ambitious components that the OSF created from the contributions, and then assiduously fix bugs internally without sharing fixes with other companies.
The OSF obviously could not survive this behavior. (Nor did most of its member companies.) The OSF merged with X/Open and still exists in some evolved form as the Open Group, but its main legacy is Microsoft’s Component Object Model, which the company copied (in a largely compatible fashion) from a contribution to the OSF by Apollo Computer.
Fast forward to more contemporary actors. The OpenStack Foundation was formed by companies that understood openness as a business strategy and community value. It has truly open software as defined by the license and by a contribution process that follows four “Open” promises: open source, open design, open development, and open community. According to community manager Stefano Maffulli, however, more recent corporate members joined up in a rush from market pressure. These corporations may have had little time to learn and understand the open collaboration that makes OpenStack so different from most open source projects, and they risk reverting to zero-sum thinking, like the members of the old standards groups.
In a recent presentation, Maffulli says that “committed companies” are deeply involved in the decision making process, know how and with whom to communicate, help fix things when they break, etc. (slide 26 in Maffulli’s presentation). In contrast “involved companies” are part of the Foundation for tactical reasons and their developed are “involved on the outskirts first” (slide 29).
To get the most from both groups, the Foundation is conducting an ongoing effort to sustain OpenStack’s growth with more education in the values of open innovation. Before each OpenStack Summit, the Foundation offers a free two-day training session to teach developers the social skills required to successfully contribute new code. This upstream training teaches developers the values of collaboration across corporate boundaries, hoping they can explain to their managers that paying a fee to the Foundation qualifies them to be members but that successful collaboration requires more. The call for speakers at the next OpenStack Summit in Paris has a track on How to Contribute, designed to share best practices and success stories.
Contributing a driver or a plugin to an OpenStack component is as valuable as contributing a new core feature. “Where would Linux be without device drivers?” asks Maffulli. “And where would device manufacturers be without solid memory management and other core features of the kernel?” They’re two sides of the same coin, but some people don’t yet see that.
It’s important to explain to companies that when they contribute a driver or some other small piece of code to any open source project, they are responsibility for the success of the whole. Dropping 10k lines of code at the periphery of a project with 2M lines of code means taking ownership of the whole 2M: it’s a responsibility toward its customers not to repeat the mistakes of the Open Group.
Federico Lucifredi told me that OpenStack was at risk of spreading itself too thin by embracing too many new projects, a problem similar to the OSF’s adoption of overly complex and immature technologies. In the case of OpenStack, many companies are pressing the community to embrace new modules that are addressing decidedly non-urgent requirements. This reached a zenith at the November 2013 Hong Kong summit, and a reaction set in among community leaders. The OpenStack Foundation is now working to identify the select Core modules that correspond to the use of the OpenStack trademark. Projects deemed worthy of support and recognition will continue to receive Incubator status, in a model similar to the Apache Foundation’s.
At the Open Cloud Day, OpenStack’s Release Manager, Thierry Carrez, was asked how the project could maintain forward momentum with a distributed, decentralized decision-making structure. He answered, “The benevolent dictator model is great if you can afford it,” but few projects can find someone who functions over the long term as both technical lead and release manager as Linus Torvalds does. The OpenStack Foundation is trusting the community to restore balance through voluntary measures. Its experience is a case study in the blending of structure with letting a thousand flowers bloom on a massive scale for open source technologies.