FOSS Governance and Blockchain Networks

12 min readJul 13, 2020

The principles of free and open source software (FOSS) are fundamental to the ethos of the communities building blockchain-based web services. While it is not uncommon for a single organization or a small group of core developers to coordinate and deliver most of the work, the source code is generally open for everyone to inspect and improve upon. Control is maintained not by keeping software proprietary, but through social and institutional means, including ideological discourse, community management, and trademark license agreements. Apart from the unique governance challenges from issuing network-specific assets (tokens) to operators, investors, users, or other stakeholders, there are many similarities between blockchain and traditional FOSS projects. Existing research on FOSS governance may therefore be helpful in designing blockchain governance systems.

The Meaning and Stages of FOSS Governance

Governance can be defined as the process of applying any design feature or control mechanism that maintains and steers a system. Governance of FOSS projects consists of the following:

Ownership and management of assets (incl. intellectual property)
Documentation outlining the project’s vision and policies
Software development and upgrade process
Community management and social control/norms
Conflict resolution and the creation/changing of rules
Tools and methods of communication and organization

Across these six categories, a further distinction is made between informal and formal structures or processes: the former are based on shared social norms and community culture, while the latter are expressed in written rules and contractual agreements. In addition to external control mechanisms, such as software licenses and code quality checks, effective FOSS governance depends also on factors that are internal to the individuals involved, such as intrinsic motivation and self-policing. [1]

Many FOSS projects start out as voluntary, small-scale initiatives, relying on a small group of original contributors and maintainers. At this early stage, governance is often informal and spontaneous, emerging organically out of the personal preferences of, and relations among, initial community members. Over time, standards of new developer onboarding and peer review are developed, as well as typical ways of completing recurring tasks and addressing recurring challenges. These standards and collective habits represent early forms of institutionalization and become the foundation for more enduring structures of governance down the road.

The need for formalized governance vis-à-vis the external world arises as the developer and user communities expand, and especially as commercial interests or conflicts among different stakeholders emerge. To handle the growing complexity, maturing FOSS projects introduce legal structures (typically a non-profit foundation or a lead developer company), a much more specialized division of labor (including delegation and a clear distinction between strategic, administrative, and technical tasks), official forms of communication, and a stronger overall focus on the long-term stability and sustainability of the project. [2] Once established, formal governance helps preserve a project even when its founders and initial contributors are no longer actively involved.

Types of FOSS Governance

Taxonomies of FOSS governance focus on software licenses, organizational structure, and the general ethos of the project. Most FOSS projects can be placed on a spectrum between mechanistic/hierarchical vs. organic/distributed ecosystems, or open/reciprocal vs. more restrictive/commercial approaches to software licensing. [3] Beyond that, further distinctions can be made based on the distribution of decision-making power, or how a particular project manages their software development process and stakeholder relations.

In terms of decision-making, FOSS projects are commonly categorized as (benevolent) dictatorships (a single person or a core group of key individuals have the final say), meritocracies/technocracies (rule by the most active or accomplished contributors), democracies (either direct or representative), or commercially-driven/plutocracies (power tied to primary sources of funding, usually private companies with business interests tied to the continued maintenance of the codebase).

In terms of software development and community management, [4] have identified three types of FOSS communities: Open, Defined, and Authoritarian. Open communities are loosely organized and governed directly by the project’s contributors with minimal centralization in the hands of specialized administrators. In a generally informal and lightly managed work environment, including no pre-defined procedures for handling conflict, individual members have considerable freedom to join the community, self-select tasks, and drive the project forward. However, in doing so, they are usually expected to follow some basic guidelines regarding the use of tools and information associated with the project.

Defined FOSS communities are characterized by a more tightly controlled software development process, while community management is kept decentralized and democratic. Bottom-up defining of goals and tasks is possible, although less common, and the process of adding to and releasing software is supervised by designated community members who are following a well-established set of rules and standards. Importantly, Defined communities have a managed process for resolving conflicts and employ a variety of control mechanisms to arrive at a desired work environment and outcomes, such as publicly shared expectations about acceptable behavior and clear measures of success.

Finally, as the name suggests, Authoritarian FOSS communities are characterized by a more centralized management structure. Regular members tend to have less control over how objectives or the division of labor is determined as key decisions are often made unilaterally by the project’s leaders. The software development process is somewhat defined, but expectations and procedures regarding the use of tools and information are not necessarily clear. As a result, Authoritarian communities tend to have less collaborative group cultures than Open or Defined communities.

Best Practices in FOSS Governance

The success of FOSS governance can be measured by the quality and adoption of the software over time, the frequency and handling of major conflicts, and the general health of relations within the project’s ecosystem. There is no single correct way to govern a FOSS project, and a variety of systems have proven effective under different circumstances. However, certain best practices have been highlighted in research.

It is generally agreed that undefined project governance is rarely sustainable and that some explicit rules are required for long-term growth and success. At minimum, there should be clarity on the process of setting goals, making decisions, managing resources, and resolving conflicts. Depending on the context, both excessive controls and a lack of structure or formal procedures may discourage participation and cause dissent. [5] In establishing its policies, each FOSS project must therefore find a balance tailored to the specific needs and preferences of its developer and user communities.

Making rules explicit is not synonymous with elaborate and time-consuming governance activities. For example, many FOSS communities practice “rough” or “lazy” consensus, which means a particular action or proposal is considered acceptable unless someone objects within a relatively short time period. In more loosely organized projects, another typical coordination mechanism is self-assignment of tasks with only a small subset of members regularly engaged in formal discussion and decision-making. [6] More important than broad participation on every issue or activity is transparent communication and effective, legitimate means for participants to voice their concerns and resolve potential disagreements.

The stereotypical image of a FOSS community is that of a distributed network of voluntary contributors. But in reality, both developer hours and governance authority are often concentrated inside a handful of individuals and organizations, such as the core developer team, a dedicated software foundation, or a private company that’s spearheading and funding most of the work. Centralization and authoritarian governance have proven effective in FOSS communities with highly capable and respected leadership. However, concentration of power is also seen as problematic because it creates a single point of failure and reduces organizational resilience [7]. Greater degrees of openness and accountability have often proven more effective in attracting new contributors than autocracy and opaqueness [1].

According to [4], between Open, Authoritarian, and Defined FOSS communities, the latter tend to have the most effective coordination and highest overall performance. A closely managed software development process and a clear division of labor ensure clarity on technical objectives and reduce the likelihood of duplicate activities. Formal control mechanisms such as creating budgets, establishing work procedures, and assessing deliverables provide the necessary scaffolding for stable progress. Importantly, by allowing broad participation in general community management, Defined communities are able to crowdsource ideas and contributions from a large pool of developers, thereby fostering a collaborative work climate despite the tightly controlled development process.

The importance of more informal governance mechanisms such as common values, personal reputation, and self-control should not be understated, and this is where the attitude and habits of a few key individuals can have a particularly large impact. By setting an example, leading community members play an important role in establishing behavioral norms that help structure and guide the work process, while providing a basis for newcomers to assess whether they’re a good fit to join the project. Shared norms and expectations about acceptable behavior, together with social pressure to act accordingly, are therefore just as important in steering FOSS communities as formal rules and organization. [4] [6]

A final notable component in effective FOSS governance concerns the use of tools and interfaces, especially Internet-enabled communications. While physical meetups and developer conferences can play an important role in establishing personal relations and group identity, all FOSS projects rely heavily on mailing lists, online forums, websites, wikis, conference calls, instant messaging, and code collaboration platforms to coordinate their work and information flows. [5] This includes interactions not only among code contributors but also end-users. By releasing software early and often, while encouraging feedback from people using it, any issues and potential fixes can be identified more quickly, leading to more rapid improvement in quality and user experience. [3]

FOSS Governance in Blockchain Networks

The governance of public blockchain networks and decentralized applications (dapps) is spread between three points of control. First, the rules inscribed in the protocols that enable and limit the interactions between various network participants; second, coordination of the software development and upgrade process; and third, managing the rights and relations within the broader community of stakeholders, including network operators, end-users, and investors. Activities that are facilitated by or recorded on the blockchain are referred to as on-chain governance, whereas activities that take place independently of the blockchain are referred to as off-chain governance.

Essentially all major networks and dapps are running open source software protocols and have established formal guidelines on submitting and subsequent handling of software improvement proposals. [8] [9] Developer activity and communications are typically coordinated by a dedicated non-profit foundation, a handful of private companies, or other self-organized groups within the community. Some blockchains have managed to attract considerable developer activity beyond initial contributors, especially around building applications that use the services provided by the underlying network. As such, the challenges and emerging best practices of governing blockchains have obvious similarities with traditional FOSS governance.

However, things get more complicated (and controversial) once certain unique features of blockchain networks are taken into account. For example:

As cryptographically secured and openly verifiable data structures, blockchains are often used to store financial values or transactional logic that require strong settlement or execution guarantees, even in adversarial computing environments. As a result, both legitimate software upgrades and malicious cyberattacks may affect the issuance, distribution, or safety of network-specific digital assets (tokens), which means that users of the blockchain (who hold the private keys for controlling these assets) have very explicit financial interests tied to how the network evolves.
Many blockchain communities aspire to build systems that are public, permissionless, user-owned, and user-operated. The source code is generally open for everyone to inspect and improve upon. Network participants are free to either run the published software or not and, in case of major disagreements, launch a competing network by forking either the code, data, or both. To reduce the need for transparent social coordination, some communities avoid formal governance and try to make as few major changes to the core protocol as possible. [10] Others argue that blockchain systems must evolve over time, creating a need for transparent and legitimate means to make and implement decisions with minimal disruption in the services provided by the network. This has led to various experiments in decentralized governance, including careful curation of public discourse, formation of elected expert or technical committees, and attaching formal governance rights to network- or dapp-specific tokens held by different stakeholders, which usually means voting to ratify proposed software upgrades, tweak various system parameters, or allocate common pools of resources. [11] [12]
The most fundamental value proposition of blockchain networks and dapps has to do with decentralization, or not having to rely on centralized intermediaries that have the ability to censor transactions or unilaterally change the rules of the system. Therefore, any governance mechanism that re-introduces central points of control and failure may undermine the core purpose of using a blockchain instead of a more centralized solution. Importantly, this includes technical centralization, which can be avoided by ensuring the availability of multiple software implementations developed in different programming languages. Public blockchain communities are thus faced with a very difficult challenge of reconciling the ethos of decentralization with the need for effective and legitimate governance.

What, then, does good governance look like in blockchain networks? Starting with a clear distinction between the software development process on the one hand and general community management on the other, a solid foundation can be established by employing best practices from traditional FOSS governance. Indeed, this is what leading networks appear to be doing already by having formalized their software development and upgrade process, creating organizational structures to manage shared resources, and using modern communication technologies to disseminate information and coordinate activities among different stakeholders.

Beyond traditional FOSS governance, however, blockchain communities are in uncharted territory. Some are opting for minimal decision-making and change, bowing to the prescriptions of the initial designers of their system; others aim for maximal adaptability to take advantage of changing technological and market opportunities; some are comfortable starting out centralized, while committing to strive for more decentralization later down the road; others try to empower a broad range of stakeholders within an elaborate system of checks and balances; and still others seek to automate as many processes as possible to keep their system operational even without constant human involvement.

All these experiments will allow different communities to iterate towards governance structures best suited to their needs. In doing so, they will be guided by the values and principles that leading ‘network politicians’ succeed in mobilizing support and resources for. But applying best practices from traditional FOSS governance in the context of blockchain networks and dapps is just one aspect of a much bigger topic. The economic and administrative systems that humans are building with information technology are changing the fundamental structure of society and have important implications for political agency and organization. A topic that I intend to focus on next is how these emerging systems fit into the broader landscape of digital governance as the information technology revolution continues to unfold (see here and here).

Footnotes

[1] Markus, M. L. (2007). The governance of free/open source software projects: monolithic, multidimensional, or configurational? Journal of Management & Governance, Vol. 11, pp. 151–163. Available here.

[2] De Laat, P. B. (2007). Governance of open source software: state of the art. Journal of Management & Governance, Vol. 11, pp. 165–177. Available here.

[3] Raymond, E. S. (2001). The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O’Reilly Media.

[4] Di Tullio, D. & Staples, D. S. (2013). The Governance and Control of Open Source Software Projects. Journal of Management Information Systems, Vol. 30, №3, pp. 49–80.

[5] Jensen, C. & Scacchi, W. (2010). Governance in Open Source Software Development Projects: A Comparative Multi-Level Analysis. IFIP Advances in Information and Communication Technology, Vol. 319, pp. 130–142. Available here.

[6] Di Tullio, D. (2012). The Governance of Open Source Software Development Projects. PhD Thesis. Queen’s University, Canada. Available here.

[7] Eghbal, N. (2018). Governance without foundations. Available here.

[8] Bitcoin development is organized through Bitcoin Improvement Proposals (BIPs), as described in BIP-0001, BIP-0002, and BIP-0123. Disclosure: The author’s work is funded by Placeholder, an investor in BTC.

[9] The development of Ethereum, a leading blockchain network with Turing-complete smart contract functionality, is organized through Ethereum Improvement Proposals (EIPs), as described in EIP-1. See also Jameson, H. (2020). Ethereum Protocol Development Governance and Network Upgrade Coordination (available here); and Jameson, H. (2020). What is an Ethereum core developer? (available here). Disclosure: The author’s work is funded by Placeholder, an investor in ETH.

[10] A good example is Bitcoin, known for its lack of transparent and formal governance beyond the rules of the protocol and the BIP process (see footnote [9]). While considerable influence is inevitably concentrated in the hands of core developers, leading miners (network operators), and other powerful stakeholders, such as large cryptoasset custodians and exchanges, there is currently no formal basis for any of them to claim legitimate authority over Bitcoin’s governance.

[11] For example, Polkadot has an on-chain governance mechanism that divides decision-making authority between a community-elected council, an unelected technical committee, and the holders of Polkadot tokens called DOTs. To learn more about Polkadot’s governance, see here and here. Disclosure: The author’s work is funded by Placeholder, an investor in DOT.

[12] Votes are often weighted according to the number of network-specific tokens held by each voter, which means that the distribution of tokens effectively determines the distribution of formal decision-making power. See Institutional Participation in Token-Weighted Network Governance.