Project Governance: What the Blockchain Community Can Learn from the Open Source Community
By Mark Radcliffe and Jonathan Bryce
Blockchain governance has become a significant topic of discussion within the blockchain community; recent examples of these problems include the meltdown in the BitcoinCash fork and the debate over the proposed changes in the Ethereum blockchain. Despite many articles about blockchain governance, they rarely refer to the obvious model for governance of such blockchain projects: governance of open source projects. The open source community has over twenty years of experience in governing collaborative development projects, with major projects such as Linux and OpenStack experiencing significant growth and widespread enterprise adoption. Jonathan Bryce, the founder and Executive Director of the OpenStack Foundation, summarized this experience as follows: “open source project governance should provide balance (like good government) between the entities and participants. If a single entity has too much power through governance, it’s likely over time that participation by other parties will dwindle. This risk is not always visible in the early days of a project or community when hype is at its peak and everyone is dying to be involved. But this balance becomes really critical when things get bumpy for whatever reason.” This experience is particularly relevant to “consortium” which are private or permissioned blockchains rather than public blockchains, such as Ethereum and Bitcoin.
Virtually all of the articles published about blockchain governance in the last year have focused on the governance of public blockchains, particularly Ethereum (starting with an article by Fred Eshram Blockchain Governance: Programming Our Future on November 27 2017 (https://medium.com/@FEhrsam/blockchain-governance-programming-our-future-c3bfe30f2d74) and continuing through a series of articles on Medium by a variety of authors including Vlad Zamfir and Steven McKie as well as panels at Ethereal in New York City and a podcast with a debate between Gavin Wood and Vlad Zamfir. However, the governance issues of public blockchains are quite different from consortium blockchains which are “private” or “permissioned” and are made up of a limited number of known entities. These consortiums are forming in many industries to deal with the particular problems of those industries: they include B3i and the RiskBlocks Alliance in the insurance industry, BiTa in logistics and FoodLogiQ Blockchain Consortium in the food supply industry. These consortiums will be managing collaboration development and, sometimes, operation of software systems among competing enterprises. A further difference is that such private consortia are likely to select “off chain governance” through a separate entity rather than the “on-chain” governance characteristic of public blockchains, such as Bitcoin and Ethereum.
The governance challenges that such private consortia face are very similar to the challenges of open source software projects, particularly because many of the major blockchains are based on software licensed under open source licenses.
Jonathan Bryce, who has spent his career building the cloud, is Executive Director of the OpenStack Foundation. He has been leading the OpenStack Foundation from its formation in 2012 through the present. He has seen the OpenStack community grow from a handful of developers and companies to a community with more than 82,000 members from 187 countries around the world. Currently more than half of the Fortune 500 use OpenStack software. .
Mark Radcliffe assisted Jonathan Bryce in organizing the OpenStack Foundation and has experience working a number of OSS consortia (frequently organized as non-profit foundations) in solving these governance problems, including assisting the Linux Foundation and the Apache Software Foundation. He is also familiar with more traditional corporate governance through his representation of companies and investors in the venture capital ecosystem (during his 35 years in Silicon Valley, he has managed over 1,000 venture capital financings) and service as a Board member of a publicly traded mutual fund
In addition to his work on OSS consortia governance, he has been advising on open source intellectual property licensing matters for over 15 years. For example, he assisted Sun in open sourcing the Solaris operating system. And he chaired one of the four committees which drafted the new version of the GPL (“GPLv3”) in 2007 and was the lead drafter of the template contributor agreements for Project Harmony.
Based on this experience, Jonathan Bryce and Mark Radcliffe recommend that these new blockchain consortia should consider the following major issues in developing their governance procedures. Naturally, if the private blockchain consortia are new, they have much greater flexibility. However, if they are trying to apply governance to an existing blockchain project, like we did for the OpenStack project, they need to “mold” these principals to the way the project currently operates. In the case of the OpenStack project, that meant that the Board included eight members elected by the “individual” members of the OpenStack community. They are enclosing a summary of the top four issues to consider:
1. Identify Stakeholder Groups for the Blockchain Project: The stakeholders in the blockchain consortium need to be identified in order to provide representation and determination of which decisions should be made by which group and how the decisions will be made. For many blockchain projects, they will include companies in the industry, service providers to these companies (for example, freight forwarders in logistics consortia), academic institutions, nonprofit institutions, software developers, and users of the blockchain project. The companies who wish to participate may vary dramatically in revenue (particularly revenue attributed to this industry) and most open source software (“OSS”) consortia provide for corporate memberships with different fee levels and representation on the Governing Board or Board of Directors (“Board”). A general framework for such participation is described below:
Platinum: Annual fees are the highest and each class member receives a Board member
Gold: Smaller annual fees, potentially based on company revenues. The class has more limited Board representation (perhaps one out of three)
Silver: Modest annual fees, designed for smaller companies. Generally, one or no Board member.
Academic/Nonprofit: No or small fee. Generally, one or no Board member.
Developer Community: One or no Board member; possible Board observer.
The other stakeholders such as users who do not fall into these categories and third party developers of applications and documentation may be represented by committees that report to the Board. A number of these projects rely upon major vendors, such as IBM or Microsoft to develop the solution which would be unusual in OSS consortia. Such vendors should generally be dealt with through commercial agreements and not become a “member” to avoid conflicts of interest.
2. Form of Representation. Once the stakeholder groups have been identified, they must decide how they will be represented in the organization. Generally, the industry stakeholders will be represented through the Board. The major issues for the Board are: size, method of appointment or elections, term, quorum (the number of Board members needed to transact business), percentage votes for approval (and any special percentages for certain decisions), appointment of officers and affiliated entity board limits. If a Board becomes too large, it can be difficult to operate. On the other hand, the Board needs to represent the major participants in the blockchain project ecosystem. The OpenStack Foundation board has 24 members and operates well, but they think that any Board of greater size would be difficult to operate effectively. As noted above, the highest level of corporate membership would generally have the right to appoint a member to the Board with the lower levels of corporate membership “electing” a representative of the class members. The terms of the Board members will generally match the membership terms (which is generally annual). The quorum will depend on the size of the Board and the need that sufficient stakeholders are present to give the Board decisions legitimacy. Similarly, the percentage votes will depend on the Board composition and the need to provide legitimacy. Frequently, the majority of Board members who form a quorum will be the requirement for routine decisions (my experience is that most Board decisions in well run consortia are unanimous or near unanimous) but certain decisions, such as changing the size of the Board, changing the allocation of Board seats among membership classes and approval of the budget may require percentage votes higher than a majority or a vote by the classes themselves (see below). The day to day operations of the consortium will be managed by officers appointed by the Board and the Board needs to decide which officers are required by the relevant law where the consortia are incorporated and which the consortia needs: most consortia have a Chief Executive Officer (frequently called an Executive Director), Chief Financial Officer and Secretary. Finally, most OSS consortia ensure that a single entity (or group of affiliated entities) does not obtain undue influence by limiting the number of Board members who can be from a particular entity or group of affiliated entities. This limit is frequently referred to as a “board diversity” requirement and also applies to an increase in the number of Board seats held by a single entity or group of entities arising due to a merger or acquisition. The organizational documents may also set up special Board committees to deal with particular issues such as management of technical roadmap, trademark, membership and audit. These committees may either report back to the Board or actually have authority to make decisions on behalf of the Board in their particular area.
3. Special Voting Rights for Critical Issues. Although Board approval is generally used for routine decisions for the project, the members may demand that some decisions require additional approval (such as the approval of the “class” of members). The classes (such as Platinum Members or Gold Members) will probably require that any change in their rights must be approved by a majority or supermajority of the members of the class: these rights could include the number of Board seats for the class, the number of members of the class, the policy for admitting new members of the class, the method of election or appointment of Board members and the “director diversity” requirement. The members could also require special “class” votes for other major issues such as the software license for the project, the policy for use of the trademark for the project and change in consensus method (Proof of Work, Proof of Stake or Proof of Authority).
4. Form of Entity and Jurisdiction. The choice of form of entity and jurisdiction in which to organize the entity will depend on whether the entity will be for profit or non-profit and the location of the participants in the blockchain projects. OSS consortia are generally organized as non-profit foundation and many are incorporate under US law: the OpenStack Foundation is a Delaware non-profit non-stock corporation, the Linux Foundation is an Oregon nonprofit mutual benefit corporation and the Apache Software Foundation is a Delaware membership (non-stock) corporation. However, other OSS consortia are organized under the laws of different countries: the R Foundation is organized under Austrian law (and has not received non-profit status under US law) and the Document Foundation (which manages the LibreOffice project) is organized as a non-profit foundation under German law. The choice of entity and jurisdiction will also depend on regulatory and tax issues. If the consortia is for profit and may seek traditional venture investors in the future, the consortia may choose to be incorporated in Delaware because virtually all venture capital investors wish to invest in a Delaware corporation. However, if the consortia is a non-profit, it has a wide range of choices which will depend on tax, regulatory and consortia participants. Currently, the following jurisdictions which are the most likely choices are Delaware (as a non-profit non-stock corporation), Switzerland and the Cayman Islands. The challenges of governance in private consortia for blockchain are very similar to those solved (and continuing to be solved) by the OSS community and these blockchain consortia should look to the experience of OSS consortia to take advantage of their experience (and avoid their errors).
