Examining How We Govern Collectives
What we can learn from the governance models in co-ops, open source software and DAOs, and how that will help dYdX inform its approach to decentralization
Summary
dYdX is undergoing a much anticipated effort to fully decentralize its governance through the release of V4 of the protocol. There are numerous past examples of coordination and governance among collectives that we can study to help dYdX shape its approach. This article unpacks the most common governance structures found within co-ops, open source software projects, and other DAOs that have successful decentralized decision making. It examines the nature of each of these communities, the mechanics of how decisions are made, then boils down the learnings to 3 key ideas that dYdX should take into account as it embarks on the road to complete decentralization:
Favor fewer decision makers whenever possible
Invest in the non technical contributors
Encourage contributors building on the edges
Co-ops: A Model for Collective Ownership
What is a Co-op?
A Cooperative (Co-op) is a business that is owned and democratically controlled by its members who have shared visions and goals. Voting power within co-ops is distributed uniformly — each individual has a single vote no matter the amount that they have individually invested in the business. Co-ops are generally operated at cost. The goal is to ultimately accrue value to the members of the collective rather than to shareholders like in a traditional company.
Co-ops first emerged in the early 18th century and have taken many forms since then. The early iterations of the co-op were to combat social and market power imbalances. Over time co-ops have evolved as a way to create true community ownership in a business and drive value to the community members.
The Origin of Co-ops
During the English Industrial Revolution, workers in cities labored in factories for low wages, with poor access to quality and affordable food. In 1844 in Rochdale England, workers worked together to solve this problem by forming the first co-op known as the Rochdale Pioneers to source quality food at more affordable prices for the community. The initial group of members pooled their money to open a store to sell basic food supplies such as wheat, butter, and flour. Through the co-op, members of the community were able to get quality ingredients at a reasonable price. The members of the co-op were able to have a voice in governance, and receive their fair share in the profits from the co-op.
Image: 13 of the original members of the Rochdale Pioneers Co-op.
Source: Rochdale Pioneers Museum
The Rochdale Pioneers Co-op was an example of one of the few ways where a community of individuals were able to take action in an environment where they were otherwise powerless to advocate for their own needs. The Rochdale Pioneers developed a robust set of operating principles that served as the backbone of the co-ops that followed. Rochdale was credited with setting the stage for modern co-ops, which has burgeoned to reach an estimated 3 million co-ops.
Types of Co-ops
Co-ops vary in who the members are. Here are a few of the common forms that co-ops take on:
Consumer: This is the most common type of co-op where the consumers of the business are the members of the co-op. The objective of the co-op is usually to produce the highest quality goods or services at the lowest cost to the consumers.
Ex: REI
Producer: In producer co-ops, product producers join together to aggregate their product so that they can better distribute, market, or produce. The goal is that economies of scale can help the individuals of the co-op have better economics together than apart.
Ex: Land O Lakes
Worker: Worker co-ops are owned and governed by employees. Their goal is to improve the wellbeing of workers by increasing wages, improving working conditions etc.
Shared Services: Shared services co-ops are comprised of organizations like small businesses that join together to get access to better prices with joint purchasing, training, and distribution.
Ex: Ace Hardware
Co-op Governance
As opposed to a traditional company where governance is ultimately in the hands of investors, in a co-op the management reports to the members of the co-op. Each member of the co-op has a single vote no matter how large or small they are.
As a co-op scales and its members number in the hundreds or even thousands, most co-ops take on an organizational structure that helps them manage their operations. Within a typical co-op there are a few key players:
Co-op members: The co-op’s members are responsible for voting on the board of directors. Co-op members usually attend an annual meeting where they vote on board members, and bylaws that affect the overall direction and strategy of the co-op.
Board: The board is elected by the members of the co-op primarily to oversee the management team’s performance. Other roles may include establishing budgets and advising the management team.
Management: The management is hired by the board to oversee the day to day operations of the co-op. Management has the power to hire staff and keep them accountable, implement policy, and have the power to make decisions that are required to operate the business.
Staff: Staff are hired by and report to management. They work on the day to day operations of the co-op.
Strengths of Co-ops
Customer Loyalty
In co-ops, especially in consumer co-ops, there is a strong focus on the community it serves, allowing the organization to inherently have a deep understanding of its customer. In addition, members’ ability to influence decisions allows the co-op to tailor products that meet the needs of its customers. These factors uniquely align incentives so that customers are extremely loyal to the organization.
Survivability
Studies have consistently shown that co-ops have greater survivability compared to traditional businesses. Quebec co-ops showed a five-year survival rate of 62% and ten-year survival rate of 44%, compared to 35% and 20%, respectively, for other Quebec businesses. Members of the co-ops each have a stake in the business and a voice in governance which aligns incentives to make the business resilient during hard times.
Challenges faced by Co-ops
In 2016 Mckinsey interviewed a total of 600 employees across co-ops and public companies to understand more deeply how co-ops compared in various operational areas. The general consensus from the study was that co-ops face challenges around agility in decision making, pursuing new opportunities, and sourcing and developing talent.
Source: Mckinsey and Co
Decision Making
The trap that co-ops fall into is the unclear divide between the decision making roles of management who operate the business, the board, and the co-op members. The tendency is for the board and co-op members both to get involved in the day to day decision making, leading to major decision making bottlenecks. Co-ops that are operating in competitive markets where decisions need to be made quickly to adapt to competitive pressures are especially impaired. The democratic and consensus driven approach that is central to the co-op’s ethos is the double edged sword co-ops live and die by.
Pursuing New Business Opportunities
Co-ops are formed to serve the members. The collateral effect is that it's harder for co-ops to convince members to invest in opportunities that do not have a clear short term payoff. Longer term investments like R&D, and new business opportunities are less appealing vs investing money into initiatives that can create tangible rewards to members immediately.
Companies with visionary CEOs are able to take calculated non consensus bets, which pay off on a longer time horizon. Since the direction of the company lies in the hands of members, it's difficult for co-ops to opt to invest in moonshots, or even ancillary business lines.
Sourcing and Developing Talent
Co-ops have difficulty attracting and retaining young talented performers. High performers don’t like to wade through red tape in order to get things done. Unfortunately, the collective decision making style within most co-ops runs contrary to the more nimble companies that talented individuals flock to. Understandably, not being able to attract talented individuals reduces their ability to compete on par with traditional companies.
Summary: Learnings From Co-ops
Community ownership is a powerful advantage that leads to loyal customers and helps the business survive tough times.
Define which decisions should be made by the collective vs decisions that should be made by operators with context. Too many decision makers leads to slow and suboptimal decisions.
With community ownership and decision making, it's easy to overlook investing in long term opportunities that don’t have an immediate payoff.
Inefficient organizational decision making repels talented individuals who run from bureaucracy.
Coordinating Contributors in Open Source Software
What is Open Source Software?
Open source software (OSS) is software that is released publicly for anyone to view, copy, or use. Since the 1980s internet communities have been formed around various open source projects to coordinate contributions and drive these projects forward. Most contributors are unpaid, yet open source projects have sustained contributions and impact that dwarf the largest companies in the world.
Open source projects sometimes have thousands of community members contributing to the source code, and millions of users who rely on the software. Let's explore the challenges that OSS communities face, how they coordinate contributors, and make decisions.
Coordination Problems in OSS
The most common issue that OSS projects encounter is not the dearth of contributors, but rather the new contributors who overwhelm project maintainers who onboard individuals, triage contributions, and wade through opinions. As Nadia Eghbal accounts in her book Working in Public: The Making and Maintenance of Open Source Software, the primary issues that open source software encounters is lack of attention of its core maintainers.
“The problem facing maintainers today is not how to get more contributors but how to manage a high volume of frequent, low-touch interactions. These developers aren’t building communities; they’re directing air traffic…it's not the excessive consumption of code but the excessive participation from users vying for the maintainer’s attention that has made the work untenable for maintainers today.”
The benefit of open source is that it is permissionless, which allows professionals with varying talents all over the world to work together to drive the project forward. On the flip side, permissionless means you don’t get the filtering that normal companies would to select the individuals with the right experience to participate. The result is a cacophony of voices that core contributors have to spend their time sorting through, which often does more harm than good.
There are two approaches through which OSS projects overcome this coordination problem. One is the more common solution of restricting the amount of time and attention core contributors spend on triaging contributions from the community. The second, is the opposite — consciously spending resources to onboard and level up as many contributors as possible so they can eventually help bring new members of the community along.
Public but Not Participatory
The founder of Python, Guido van Rossum stepped down in 2018 after 27 years as a leader of the Python community. Van Rossum’s departure was driven by a highly contentious decision that the community was trying to make around syntax changes in the language. The decision involved a hodgepodge of voices from a myriad of individuals with limited context, which proved taxing on to the core contributors of the project.
After Van Rossum’s departure, he argued that participatory decision making, where all members of the community can chime in on the decision, does not scale. Instead, a project can maintain the OSS ethos of building in public, but should restrict participation in decision making to a smaller group of individuals with the proper context. Otherwise, uninformed voices will slow down decision making, lead to bad decisions, and worst of all, burn out the valuable contributors who have the most context in the project.
Van Rossum’s suggestion to limit the amount of participatory decision making is often the most popular way that open source projects are able to avoid getting overrun by the deluge of contributions.
Hero Contributors
If we look at the contribution patterns in OSS, it suggests that most projects are not very participatory. In a study by Majumeder et al that looked at over 1,000 open source projects, they found that in 85% of the projects analyzed, 5% of contributors make up nearly 95% of all code commits and communications. The reality is that in most open source projects, there are a few “hero contributors” that do the majority of the work and a long tail of casual contributors.
Bootstrap is an open source project that is a prime example of hero contributors carrying the project. It’s one of the most popular projects on the internet, used by 22.1% of all websites but if we look at the number of commits by contributor, we see that a handful of contributors account for the majority of the contributions of the project.
Source: Working in Public by Nadia Eghbal
Making the project less participatory might be the most common way that projects are able to avoid overextending the core contributors on the team, but there it doesn’t come without drawbacks.
Side Effects of Reducing Community Participation
The most obvious side effect to not having a large and diverse group of core contributors is lack of project resilience. When the knowledge around a project is localized to a select few developers, the project is all of the sudden at risk if a few of those developers leave. In fact the bus factor, defined by the number of core contributors that get hit by a bus before the project would be in trouble, is a heuristic that projects use to measure a project’s resilience.
A more insidious effect of having a small number of core contributors is security issues. If a project doesn’t actively grow its contributor base, when members of the team leave there are parts of the library that don’t get the maintenance they need. As a result, it's easy for security risks to start showing up and even for saboteurs to actively exploit projects, to the detriment of the software’s broad user base.
In 2018 Dominic Tarr, an active open source developer, gave a stranger commit rights to a popular software module library, EventStream, that he had developed but was no longer actively maintaining. The stranger asked to take on the maintenance of the library, but proceeded to insert a malicious bug that targeted users using the bitcoin wallet Copay. Projects with no depth in contributors and/or core contributors with active commitments to other projects make such backdoor exploits much more likely to happen.
Node.js: Public and Participatory
Node.js is a project that has adopted a liberal policy of contributions to keep up with their growing contributor base. As opposed to restricting the number of contributors, Node’s strategy is to spread context as much as possible so that new contributors quickly get the context to make contributions and onboard others. With this strategy, Node was able to become one of the most vibrant user and contributor economies in OSS.
Node.js Governance
With a large number of contributors like Node, more formal organizational hierarchies emerge. For technical contributions, the Node.js project uses a simple governance hierarchy to help guide the project and make technical decisions.
Org Structure:
Roles:
Contributors are any individuals creating or commenting on an issue or pull request.
Collaborators are contributors who have made at least one non trivial contribution and have been given write access to the project repository.
Technical Steering Committee(TSC) members are collaborators who have been voted into the TSC and have voting rights in TSC meetings.
Working Groups
Most of the technical contributions that are merged into the codebase are done by groups of collaborators who work together in working groups. Each working group focus on a particular and make decisions fairly autonomously. There are multiple working groups that all work independently on initiatives that drive the Node project forward.
Decision making within working groups is through lazy consensus. In short, with lazy consensus, proposals within a group may be presumed to pass unless any explicit objections arise. Objections must be presented with actionable steps to fix that objection. Since it's easier for team members to agree by doing nothing rather than proposing alternatives, inertia works in favor of progressing the discussion forward.
Technical Steering Committee (TSC)
The TSC helps guide the overall direction of the Node project by providing guidance on things like voting on what projects can form a working group, setting release timelines, and making technical judgments when working groups are unable to come to a decision.
TSC makes decisions through the consensus seeking process, where the group attempts to reach a consensus, if the consensus can’t be reached then they call a majority vote. The possibility of the vote encourages team members to work towards a consensus.
Hallmarks of a Healthy Open Source Project
In his blog post Healthy Open Source, Mikeal Rogers, who was a contributor of Node.js from its early days, outlines what a healthy open source project should look like. He argues that when a healthy OSS project grows, the users, contributors, committers (called “collaborators” in the Node project), and technical committee should grow in proportion to each other.
In contrast, a project’s community looks like this if the project is not experiencing healthy growth:
In the latter scenario, the committers of the project do not make a concerted effort to continually onboard new contributors, which eventually leads to more serious problems for the project, but also for the users. As Rogers states,
“We know what happens to unhealthy projects over a long enough time period, more maintainers leave, contributions eventually fall, and if we’re lucky users leave it. When we aren’t so lucky, adoption continues and years later we’re plagued with security and stability issues in widely adopted software that can’t be effectively maintained.”
Liberal Onboarding Policies
To maintain a healthy open source community, Node diverges from most OSS projects by implementing a more liberal contribution policy. Their philosophy is to onboard contributors to be collaborators with commit access after their first non trivial contribution. In addition, Node tries to invest in onboarding a diverse set of talents. Due to the ability of git to revert code, code review, and limiting access to execute the high level decisions, any mistakes that happen can be avoided or easily reversed. Over time onboarding new talent becomes easier because the org doesn’t rely on a handful of maintainers with the context.
When liberal onboarding is done successfully, a project has independent teams that are empowered with the skills and context to make decisions. The project does not need to burden senior project members to weigh in on every tough decision, and can operate in a more decentralized way.
Summary of Learnings from OSS
In OSS, the open contributions often overwhelm core contributors, so the most common solution is for core contributors to build in the open but restrict contributions from the community.
Onboarding new contributors is expensive, but it increases the number of individuals with context and can help sustainably grow the project.
Context and expertise are critical to productive discussion, especially when working in the open. Without it results in slow execution, poor decisions, and contributor burnout.
Lazy consensus and consensus seeking decision making helps reduce decision bottlenecks, and encourages discussions to progress towards resolution.
A small group of core contributors reduces the burden of onboarding and coordination but there is a tradeoff of project resilience and long term security of the software.
Decentralized Coordination in DAOs
The rise of Defi in 2020 led to rapid innovation and experimentation in decentralized governance within DAOs. Compound Finance’s Governor Alpha and Bravo framework allowed for out of the box on-chain governance, which helped spark the proliferation of DAOs. On-chain governance has many advantages such as transparency and censorship resistance, but a pure on-chain governance structure can be unwieldy for protocols that need to be more nimble in their decision making. Yearn Finance is a case study of a project that has found success gradually building out its governance model primarily off chain to accommodate the needs of a fast growing early stage protocol.
Yearn Finance
Most crypto projects follow the model of progressive decentralization, where the founding team finds product market fit for a protocol and eventually decentralizes the company via a DAO. Yearn is an interesting case study because its founder Andre Cronje launched the protocol and token(YFI) and gave full control of the protocol to the community from the start. This forced the community to quickly build governance early on to make both high level protocol decisions and manage the day to day operations.
Constrained Delegation Governance
Early on in Yearn’s history, the community realized that the speed the organization needed to operate at required more localized decision making. Yearn’s first iteration of governance was called Constrained Delegation Governance, where there was a multisig wallet that allowed elected individuals to approve a defined set of decisions for the protocol.
The multisig was given power to perform operations key to day to day decisions around personnel and budgets such as:
Determining and distributing protocol grants.
Determining and distributing community grants.
Determining and distributing legal + DAO consultation grants.
Identifying and executing key hires listed on the attached budget.
Identifying and engaging security firms.
Identifying and engaging analytical firms.
Continue executing yVault strategy changes until a dedicated team can take over.
Facilitating UI & front-end development.
Facilitating business development and integrations.
The team was careful to limit the power of the multisig. The multisig does not have access to make important protocol level decisions such as token emissions, or power to pass governance proposals.
Yearn started with minimum viable governance — a single multisig model with a restricted set of powers. The choice of launching a basic structure was actually critical to the evolution of its governance. Yearn was able to seeing how the multisig model fit the needs of its community, and then tweaked that governance model to fit those needs to arrive at its more intricate model today.
Building governance is an iterative process. Governance tools are evolving, the objectives of the DAO may change, and most importantly the community is evolving. It’s the job of operators to understand the needs of the community as they inevitably change and shape the governance model to adapt to those changes.
Transition to a Multi DAO Structure
Eventually, Yearn outgrew the single multisig model and transitioned to a multi DAO structure where the YFI token holders delegate the decision making powers to teams that are operated as DAOs themselves. In this new structure, the governance of the protocol lies within three different units: YFI holders, yTeams, and the Multisig.
YFI Holders
YFI holders are members of the community that hold the token. They have the ability to submit proposals for high level decisions over the protocol not covered by existing yTeams. These proposals include decisions around spending the treasury, or changing the fees that the protocol charges users.
The process of working through proposals is similar to Compound’s process where discussions happen on forums before a formal vote. Instead of on-chain voting, voting is done on Snapshot, which is an off-chain way for the protocol to simulate an on-chain vote.
yTeams
The Yearn protocol has contributors that work in yTeams that are smaller DAOs that focus on specific operational areas. For example, yDevs are a team of engineers that manage the protocol engineering, and yPeople who focus on compensation for the DAO. These teams run fairly autonomously and have decision making power within their area of expertise.
yTeams each have a budget that is approved by YFI holders, that is managed by a multisig wallet controlled by the team. yTeams were designed so that the community of contributors can organically form teams around the needs of the protocol and operate autonomously. The contributors within the teams have ability to make day to day decisions quickly, which allows the organization to move more nimbly.
Multisig
All transactions that go on-chain from Yearn proposals or from the yTeams need to be approved by signers of a multisig wallet. Yearn has 9 members that are elected by YFI holders to be approvers of the multisig. 6 of the 9 multisig signers need to approve a transaction in order for it to go through. The multisig also has the ability to veto any transactions if they feel that the proposal needs to go through more review.
Below are the full list of powers in the Yearn Protocol, the teams that have the powers (Delegation), and a description of the powers:
Source: Yearn Governance 2.0
Delegated Decision Making with Checks on Power
Yearn’s multi DAO structure allows the token holders to delegate the decisions that require more context to smaller teams with subject matter expertise. This leads to both more efficient decision, and selects for the right decision makers to make quality decisions. yTeams are able to work quickly and autonomously to achieve their objectives, but their power is still checked by the multisig wallet who can sign or veto any of the on-chain transactions. This combination of empowering contributors but still maintaining a check on power allows teams to execute quickly while still maintaining the right guardrails in place.
Summary of Learnings
DAO communities are fluid so governance models should be fluid too. Start with a simple governance structure and evolve it to adapt to the needs of the community.
Delegate decisions to high context contributors for better and faster decision making.
As decision making is centralized in favor of speed of execution, use checks and balances to help maintain security.
What Can dYdX Learn From Past Governance Experiments
Let’s apply the learnings from Co-ops, Open Source, and DAOs to what dYdX should take away as it builds out its decentralized governance and contributor community.
Favor Fewer Decision Makers Whenever Possible
There are a multitude of different on-chain and off-chain governance frameworks and tools for dYdX to choose from as it develops its organization. I’d argue that a key axis that it should think through when deciding what the right governance tool to use is the one that allows the DAO to have the minimum number of decision makers making the decision, while still maintaining security.
One of the common threads across co-ops, OSS, and DAOs, is that as groups increase in numbers, the coordination involved increases quadratically.
In open source software and co-ops, when many individuals without the proper context or expertise weigh into decision making and operations, it reduces the likelihood of a good decision making and causes burnout of the team.
If we look at governance frameworks from the perspective of the number of decision makers, we see a correlation in the speed of decision making.
With that in mind, as a rule of thumb, when choosing the right governance framework the DAO should be asking what the most lightweight decision making structure can be while still maintaining security.
There may be decisions that require high security so the protocol should move slowly and involve all members of the community in the decision (ie. increasing the token supply of a protocol DAO). Other decisions that don’t have adverse downstream impacts to other teams or carry less security risk can be made by a small working group via power delegated by the community. Overall, delegating decisions to a small group of carefully selected decision makers generally increases the quality and speed of decision making.
Invest in Non Technical Contributors
In OSS software, we’ve seen fatigue from core contributors dealing with inbound requests from new contributors and users. Arguably the influx of inbound requests overwhelming core contributors is a symptom of OSS projects not having enough non technical contributors. If dYdX invests in non technical support functions, it can grow while avoiding the contributor burnout that many OSS projects face.
OSS is powered by developers who are largely working unpaid and part time to contribute to projects because they enjoy tinkering and giving back to the community. Naturally there is a dearth in attention for the inbound requests to go around because that attention needs to be focused on the most important thing, which is building software.
If we look at the inbound requests, in a company they are handled by the non technical members of the company like recruiting, customer service, and product. A well oiled organization requires not just developers, but people to help onboard new contributors, spread context across teams, and manage customer input. As a project grows in popularity, the growth of the support functions need to keep pace, otherwise the project with collapse under the weight of its own success. Unfortunately in OSS, tasks that is usually covered by the support functions are not what developers want to be doing on their weekends.
The advantage that dYdX has over OSS is its treasury that can be used to invest in bringing on the non technical contributors to build the “plumbing” for the organization. The most scarce resource in web3 are the developers. Therefore dYdX should build around ensuring that developers can be as productive as possible. Investing in support functions like product management, customer support, and onboarding can help the organization make the most of their dev resources and grow in a more sustainable way.
Encourage Contributors Building on the Edges
The permissionless nature of DAOs helps them harness the creativity of the contributor community and access talented individuals from all over the world. Contributors often come up with ideas that the core team hasn’t even thought about. If dYdX funds creative contributors that are building on the edges, they not only build for the future, but also develop healthy organizational dynamics.
Compared to traditional companies, co-ops have difficulty investing in projects that don’t have immediate payoff such as new ventures and even partnerships. We see hints of short term thinking within DAOs where communities are fixated on near term token appreciation rather than the long term viability of the protocol. With a short trip through most governance forums you’d see community members supporting burning tokens to drive up token price over reinvesting earnings to grow the protocol.
To avoid falling prey to these tendencies, dYdX should be consciously taking a long term view by not just investing their treasury back into their core work streams, but branching out and supporting builders exploring ideas on the edges. There should probably be at least 20% of the budget earmarked for community members spearheading projects that do not fall on the immediate product roadmap. These projects are a way to give the community agency and a voice to build what they see should be implemented in the protocol. While most pursuits will lead to dead ends, the asymmetric upside from finding the next 10X product is worth the investment.
Investing in community led projects doesn’t just allow dYdX to tap into the wisdom of the crowd to source ideas that the core team hasn’t thought of, it also helps promote healthy organizational dynamics. Traditional organizations are structured to inherently incentivize zero sum behavior. An org chart for a company may look something like this:
People at the bottom of the organization want to get promoted for more power, pay, autonomy etc. There are more individuals at the bottom than at the top, which means that in order for Alice to be promoted, Bob is passed over. Unless the company is extremely high growth, this traditional org structure naturally leads to organizational politics and sometimes unhealthy competition.
In DAOs the approach is bottoms up where contributors identify areas where their skills and experience can deliver value and jump in to help solve those problems. If an area of the DAO is saturated with contributors, the DAO’s permissionless nature empowers contributors to work on adjacent problem areas so they are not fighting over roles. This is a fundamental shift in the mindset of workers since the goal is to insert themselves where they see opportunity in the organization rather than fighting for an increasingly limited set of more powerful roles up the corporate ladder. Investing in contributor led projects will enable dYdX to foster more cooperative communities than ever.
If this was interesting follow me on Twitter @davincifi.
This was funded by dYdX Grants Program.