Three Governance Case Studies
One of my communities is choosing a new governance structure, and in preparation for our first conversation on the topic, I wrote up three governance case studies. I covered DisCOs (Distributed Cooperative Organizations), Enspiral, and Python.
I want to continue writing up these case studies and share them in a more navigable and findable way, but for now, I thought I’d share what I’ve got with you.
DisCO
DisCO stands for “Distributed Cooperative Organization”, an alternative to DAOs that prioritizes inclusive, locally grounded, cooperative work with a social and environmental focus. The DisCO model uses Contributive Accounting to share resources in a way that supports behavior not traditionally incentivized by capitalism. The case study I read was of a DisCO called Guerilla Translation (GT).
The GT DisCO has both casual and committed members, with a 9-month “dating” period for people to become committed. Committed members have priority over casual members and are added slowly, through the unanimous consensus process of existing committed members. Committed members can also be removed through unanimous consent of existing committed members, with the person being removed standing aside.
The GT DisCO Contributive Accounting (“credit system”) classifies work into three categories: pro-bono/love, paid/livelihood, and care/admin. Credits earned of these three types are paid out equally, though paid/livelihood credits are paid out more quickly. This system creates an ongoing debt from the coop to its members, where paid back credits are “divested”, unpaid back credits are “invested”, and the sum of all credits are historical credits, which are used in voting. Patterns of credits can be used to prioritize people for livelihood work or to incentivize people to do more care work, for example.
Decision-Making
Day to day decisions are made by committed members, or by casual members with the review of committed members. Many day to day decisions do not require any formal decision process; when things to require a decision, every effort is made to use the Lazy Majority method.
(While the goal here is to minimize unnecessary process, this doesn’t mean members can disengage. There are minimum participation requirements such as voting twice a week to ensure members are engaged with decision-making.)
The Lazy Majority method holds that as long as no one explicitly blocks after 72 hours the vote passes, or if a minimum vote threshold has been reached with no blocks, it can pass more quickly. If this doesn’t work, they move to Unanimous Consensus, which requires everyone to agree and has a minimum time of 120 hours.
In a small number of cases, they may make decisions by weighted voting, where people have votes in proportion to their historical credits. This type of voting is discouraged and only used when there is a blocked proposal with no resolution or when there are large structural changes in the governance model.
Stuck proposals can also be resolved via the Stakeholder Board, which consists of external stakeholders. These can be advisory or binding votes, and are usually added to the existing committed member votes rather than replacing them.
Key Points
-
Decisions exist on a gradient, with light-weight processes for minor and/or low-controvery decisions. As decisions are more important, the mechanisms grow more time-intensive, from no oversight to lazy majority to unanimous consent to weighted voting or stakeholder board.
-
The stakeholder board vote serves a dual purpose, bringing in outside perspective as well as breaking deadlocks.
-
There are minimum participation requirements for people who are given power in the community, to prevent absentee leadership.
-
Past engagement by members, as measured by historical credits, are used in key decision-making processes; conversely casual members with little engagement have almost no say at all.
-
Pro-bono, administrative and care work are all incentivized through the contributive accounting system, which diverts money from paid work in a systematic way towards other purposes. These kinds of labor count equally when past engagement is weighed up for decision-making.
Enspiral
The Enspiral Foundation is a (New Zealand) LLC, which requires them to have a board of directors and chair. Their goal is to have a “minimum viable board”. Board Directors do not need to be members - outside perspectives are encouraged. Directors are expected to be active participants in online and offline Enspiral discussions and meetings and to be available to answer questions about the Board and its decisions. They can be added or removed with 75% support of Enspiral members.
Outside of the board, Enspiral functions primarily through a collection of about a dozen agreements. The Decision Agreement is the core Agreement from which all others derive their legitimacy.
People (Membership) Agreement
Enspiral has both Members and Contributors. Everyone is a Contributor, but only some are members.
Members hold a non-financial share of the Foundation and are its collective owners. They elect the board, control what members, contributors and partners (ventures) are asked to join and leave. Contributors can be invited by any members, but members must be nominated and then approved by a Quorum Decision. Both can be removed by an Emergency Decision of the members.
Decision Agreement
Anyone can propose a formal decision. However, they are only required when there is significant impact on the network. Formal decisions are required when adding, changing or removing agreements, making decisions about money, making decisions about membership or the board of directors, partnering with outside ventures and a few other situations.
Formal decisions are made through consensus, which is not the same as agreement - you need to be able to live with a decision, you don’t have to prefer it. A single block is enough to stop the process, which means members are expected to use the block sparingly and, when they use it, to commit to extensive discussion to find a workable solution.
They have four different decision types:
-
Standard decision: the default and quickest option, can proceed as long as there are no blocks (though proposer is encouraged to engage with non-blocking issues)
-
Significant decision: used for more consequential decisions, has a longer time frame and requires more than 50% of those stating a position to agree
-
Quorum decision: used for most important decisions; requires 75% of group members to participate; requires 75% of group members to agree or abstain; requires no blocks.
-
Emergency decision: used only when a minority block would be destructive, such as when removing a member or contributor from the community; still takes 10 days to do (the emergency is not for time-based emergencies - for those the Board has to act)
Venture Agreement
The Venture agreement governs projects that are supported by the Enspiral network. These can be pre-existing projects that join Enspiral or projects that are starting up.
Each venture must have three active “stewards”. At least one needs to be a key person in the venture, and at least one needs to not be a key person. Two or more of the stewards must be Enspiral members. Individuals are encouraged not to steward more than 3 ventures at once.
Stewards are points of contact for the Enspiral network, are responsible for issuing quarterly updates and keeping their information up to date, and are responsible for following the leaving process if the venture disaffiliate. They also are collectively responsible for helping othe new ventures join. The division of these responsibilities between the three stewards is up to each set of stewards.
Ventures are expected to contribute to Enspiral financially and/or otherwise, at their discretion. Ventures are approved by the members via a Quorum Decision and can be removed in the same way.
Proto-ventures are either early-stage projects or established external projects that are exploring the idea of becoming Ventures but are not ready to commit. They can participate in the community in various ways but have not gone through the formal process yet.
Key Points
-
Enspiral welcomes outside influence by having non-member Directors on their Board.
-
The Board is as minimal as legally possible; most power rests with membership.
-
People are periodically asked to opt-in every six months (members) or twelve months (contributors). Various kinds of participation are required or strongly encouraged, which discourages absentee leadership.
-
They use a single decision process (consensus) but have different rules for quorum, passing criteria, minimum engagement, and length of decision, depending on how consequential or urgent the decision is. This lets the community focus on one process while letting them adapt it to the needs of a given situation.
-
Enspiral’s Venture Agreement is an interesting approach to addressing the unique governance needs of affiliated projects.
Python
Python has long had a two-part structure: the Python Software Foundation, which oversees the community, brand, and finances, and the Python language team.
PSF
The PSF is a member-elected 501c3 non-profit.
There are six types of members, five which have voting power (contributing, managing, supporting, sponsoring and fellows) and one which does not (basic).
Membership types vary in how hard they are to achieve. Anyone can become a basic member just by signing up, while supporting/sponsoring memberships require yearly donations. On the other end, fellows have to be nominated and awarded fellowships for significant service to the Python community.
Fellows are members for life, all other members must be re-affirmed yearly. All voting members are weighted equally; this means big companies like Google have no more power than a random individual donor, which limits the influence of corporations, though of course they may have power in other ways.
The Board of Directors serve staggered three-year terms. The Board appoints the foundation president and officers. Since 2002, the President has been Python founder Guido van Rossum.
Python Language
For a long time, the language side operated under Guido as BDFL, though on a day to day basis it was actually run by the Core Developers, aka the people with commit privileges to the Python repositories. Anyone could become a Core Developer, but you had to go through a period of oversight and demonstrate commitment. The community made decisions through PEPs, and if there was conflict, Guido would step in and resolve it.
In July 2018, after a particularly acrimonious PEP process, Guido resigned as BDFL (though not as president of PSF). This kicked off a long process to create a new governance model. After several months of debate, a group of core developers got together decided to pass PEP-8001 which asked people to submit various governance models as PEPs. (They also did a pretty cool survey of existing open source governance models.)
After the submission period, the PSF oversaw a vote on which model to use. Only active core developers were allowed to vote, with active status determined via the honor system. They wrote: “we are asking core developers to self-select based on whether the governance situation will affect them directly”.
The system they decided on created two groups: the Core Team and the Steering Council.
The Core Team is essentially the Core Developers but renamed. It controls the language and infrastructure and makes day to day decisions.
Core team membership is granted by receiving at least two-thirds positive votes in a core team vote and no veto by the steering council. There’s no time limit on core team membership, but people who haven’t made non-trivial contributions in two years may be moved to “inactive” and lose their commit access as well as privileges like nominating or voting on steering council members.
The Steering Council is a group of five people. The Steering Council is tasked with making contributing accessing and sustainable and liaising with the PSF. They can resolve controversial decisions that have split the Core Team but are urged to use that power as little as possible.
They make decisions via a majority vote of non-abstaining members. They’re nominated by the core team and elected by the core team. No more than 2 people who are employed by the same company can serve on the council at the same time.
The Steering Council and Core Team essentially govern each other, in a fairly balanced way:
-
The Steering Council is elected by the Core Team.
-
The Core Team can vote no confidence in individual Steering Council members or in the Council as a whole. If the vote passes with a 2/3rds majority, the individuals or the Council as a whole is removed.
-
The Steering Council can vote to eject members of the Core Team, again requiring a 2/3rds majority.
That said, the current governance model can be altered by 2/3 vote of Core Team, so in the end the Core Team has primary power.
Key Points
-
Again, the importance of being active: most PSF members must renew each year, Core Team members can lose privileges if inactive, and when voting for the new Python language governance system, inactive developers were asked not to vote.
-
There are checks and balances throughout the system, with multiple semi-independent bodies (the Steering Council and the Core Team; the Python language community and the PSF).
-
Care is taken to prevent corporations from having too much influence, by making their memberships equal to individual memberships and by a rule preventing more than two Steering Council members from being employed by the same organization.
A Quick Summary
There are a number of patterns we can see in these organizations. Before I jump into them, though, I want to stress that these organizations are fairly well developed - Python, for example, is several decades old with many thousands of developers and millions of users. Their structures may not be ideal for young organizations picking their first governance models, but we can still learn from them.
Promoting Engagement
All three of these models have formal mechanisms for promoting engagement, with DisCO going so far as to ask members to participate in decision-making processes at least twice a week.
The degree to which you want to encourage or require engagement amongst decision-makers probably depends on the kind of work your community does. You do probably want to draw a line somewhere, though.
In explaining why they chose to resolve blocked decisions by favoring those who have been more engaged, DisCO writes that “we trust that those who have made larger efforts over the years will hold true to the collective’s purpose”. It is too easy for non-engaged decision-makers to lose sight of the values of the organization or the context in which decisions are being made.
Getting Outside Perspective
At the same time, there should still be a seat at the table for outsiders. There are many people who may be influenced by your organization who do not have the time or desire to participate fully. Creating space for their voices allows you to address issues coming from outside your bubble.
Python, Enspiral and DisCO all accomplish this in different ways; I am a particular fan of DisCO’s Stakeholder Board.
Different kinds of membership
All three orgs have different kinds of membership with different decision-making privileges depending on their level of commitment. This allows them to be welcoming to large numbers of people while reserving decision-making power for those who are actually investing into the projects.
“Graduated Formality” in Decision-Making Processes
All three orgs have low-effort “happy paths” for decision-making as well as processes to handle more impactful decisions. They all also address what happens when decisions have stalled due to conflict.
Enspiral handles stalled decisions by keeping the decision-making group the same but changing the rules so that they can override blocks, in the Emergency Decision protocol. This is only used in situations where a decision is needed.
DisCO resolves conflict in the extreme case by having people vote by historical credit, so that those who have been most active have the most say.
Python (language) resolves the conflict by having the elected Steering Council step in and make the decision.
Get creative & adapt to your context
While there are many patterns that reoccur across these three organizations, there are some mechanisms unique to each. This reflects the fact that every community is operating in a different context, which means different goals and different fears.
For example, Python has significant reason to worry about corporate influence. The language is used by billion-dollar corporations that donate significant sums and employ members of the community. Both the PSF and the Steering Council have rules which attempt to minimize corporate influence.
Enspiral’s community is full of projects (ventures). They needed a way to nourish these projects without letting them dominate the network or misrepresent them to outsiders. Their Venture Agreement is an attempt to strike that balance.
Finally, DisCO wanted to escape the capitalist logic that incentivizes paid work to the exclusion of other vital types of labor, like pro bono, administrative, or care-based labor. They use a creative system called Contributive Accounting to achieve their goals.
Your community will have its own unique goals and worries. It’s okay to experiment in trying to address them! There is much more out there than just the standard corporate/non-profit bylaws.