Workplace Democracy and Open Source

This year at csv,conf,v8 in Puebla, Mexico I gave a talk on our experience as a democratic worker cooperative creating digital public goods, and why we think co-ops are potentially a good fit for creating public-interest technology. You can watch the recorded talk on YouTube, or read on for a bloggified version of the talk below.

3+1 Institutional Roles

Most modern economic institutions have people play some mix of the following roles:

• Labor: The people doing the work.
• Capital: The people investing resources and expecting a return on that investment.
• Governance: The people who have decision making power.
• Users: The people downstream who are actually using whatever we produce (a special role in the context of digital public goods)

In the case of Capital and Governance, there’s also a question of how money and power are distributed among the people playing those roles.

Capital vs. Governance

We often conflate governance and capital into a generic brand of ownership: in which voting power is proportional to capital invested. “One dollar one vote” corporate governance is the norm, and is what you see in most publicly traded and many venture capital funded companies.

Historically capital and governance have been distributed in a many different ways and independent of each other. Early joint stock companies in the 17th and 18th centuries often had charters that protected minority shareholders from wealthier investors. Governance power scaled with ownership — but only to a point.

We also have modern capitalist dictatorships like Meta (Facebook) and Alphabet (Google) in which one or a few owners have super-voting shares that empower them wildly out of proportion to their economic stake.

Another big exception is the 501(c)3 non-profit organization, in which private ownership is prohibited. If a charitable organization gets liquidated, its assets have to be turned over to another charitable organization or a public entity. But of course non-profits still have governance — it’s just not linked to economic interest at all.

Worker Cooperatives

Worker co-ops occupy another “extreme” corner of the capital and governance space, in which the Labor, Capital, and Governance roles are all held by the same people, and both governance and economic rights are distributed very evenly.

Cooperatives are one-member one-vote organizations, and in worker co-ops each member is a worker. Any surplus value that’s generated is distributed in proportion to member labor inputs. This means worker co-ops tend to be wealth distributing rather than wealth concentrating institutions.

With the same people acting as owners, employees, and decision makers, co-ops are forced to internalize the tensions between these roles. It doesn’t make potential conflicts disappear, but it avoids split incentives.

The flat governance structure of co-ops also tends to result in a flat capital structure — if you don’t get additional governance power with a larger investment, it’s less likely that any individual will invest much more than another. Often members invest in a single member share that provides a small amount of initial working capital for the business. External financing if it exists is typically debt.

This structure doesn’t work well for capital-intensive businesses. If you’re trying to build a $10B chip fab, or a $1B battery factory, you’re probably going to need to attract a bunch of outside money. But for digital public goods — open data and open source software — it’s fine! Almost the only inputs to this business is our labor and knowledge.

Open Source Project Pathways

Open source software projects have different institutional forms. Often they start as an individual passion project, or an informal do-ocracy, which can evolve into a BDFL (Benevolent Dictator For Life). Some popular open source projects started life inside big corporations before being released, fully formed, into the wild — Apache Airflow began inside AirBnB. PyTorch and TensorFlow were the internal machine learning frameworks at Facebook and Google respectively.

More recently there’s been a new crop of venture capital backed open source startups like prefix.dev and their package manager pixi, or Astral, the company behind the popular Ruff linter for Python, or the Dagster orchestration framework that we use in PUDL and its competitor Prefect — both of which compete with Airflow. And some established open source tools like Pydantic and dbt have received later-stage investment.

These project pathways all have their own potential pathologies. A do-ocracy can be usurped by paid outside contributors. How long does the dictator stay benevolent? What happens when half the internet depends on someone’s passion project and they burn out? Someday the “open source” VC funders will come looking for their exit. Will the projects be able to persist without a firehose of investor cash? Can beloved tools that accept outside investment and try to build a business continue to serve their existing communities?

Happy endings exist, but a lot of them focus on widespread tools capturing a tiny percentage of the value they create, e.g. the Python Software Foundation has an annual budget of just a few million dollars even though the language it maintains underpins huge swathes of the modern data engineering and machine-learning infrastructure, generating many billions of dollars worth of profits every year.

Folks are also experimenting with more distributed open source funding mechanisms, like OpenSourceCollective and TideLift, but we think there’s also case to be made for building smaller businesses around open source projects, and considering worker co-ops as the organizational container.

Why a worker co-op?

Internalizing multiple interest groups reduces split incentives. This can include the workers (core developers), project governance, and economic stakeholders, as well as a sampling of the project’s end users, if we make sure that the co-op itself is making intensive use of the open source software or data it’s producing.

Co-ops also tend to maximize organizational autonomy — autonomy and independence are one of the longstanding cooperative principles — unlike a 501(c)3, there’s no external board that can become disconnected from the day-to-day governance of the organization, and unlike a typical company there are no external investors seeking to extract returns. The flat investment structure of a co-op also reduces concentrated incentives to privatize value — no one founder has a huge stockpile of shares they might want to liquidate.

As a democratic organization from the beginning, cooperatives have to learn the skills of collective decision making and governance, which is good preparation for deploying those skills in a broader open source ecosystem around the project as it grows.

Jobs with real purpose and autonomy are rare, and good for recruiting qualified members.

Finally, the co-op is an economic institution with the ability and incentive to steward the project and pay core maintainers IF it can find a way to capture enough of the project’s value to be sustainable.

What hidden business?

So, what kind of open source or data projects might have a business hiding inside of them? And what form might those businesses take?

• A narrow user base, but one with more intense need can mean higher user commitment.
• Users who derive direct economic benefit from the project may have more willingness to pay — if only to ensure that it keeps being maintained going forward.
• If the project serves the broader public interest in some way, grant funding may be available in lieu of outside investment.
• If your users need or value the project’s openness, it can allow paid outputs to be reinvested in the underlying platform.
• Combining domain expertise and software or data skills often creates outsized value for users.

Remember: if there’s no margin, there’s no mission.

Bill Stevenson, Rocky Mountain Farmer’s Union

Model: Grant Funding

E.g. Alfred P. Sloan Foundation, NSF Pathways to Open Source Ecosystems, NSF Cyber Infrastructure for Public Access and Open Science, Mozilla Foundation, Climate Change AI

Opportunities:

• Think of grants as seed funding to build a business that creates public goods — but from investors that don’t demand control or profits.
• Grants can also support new infrastructure — projects that are too large to fund with internal funds, or that no single client is likely to want to fund, even if many users would benefit.
• Because grants have less strict success criteria than a client, they can be used to acquire new skills or test out riskier projects.

Challenges:

• Grant funders don’t usually want to fund general operations forever. You need some other path to long-term economic sustainability.
• Grant funders aren’t users. They won’t give real feedback on what you’ve built. Excessive focus on your own use case can produce outputs that are less useful to others.
• You may need to find a tax-exempt non-profit sponsor to receive some foundation funds.
• Grants typically have overhead rates of 10-20% that are too low to cover the costs of running a real organization. You will probably need to cover those costs with other revenue sources. This means that grants are more like an internal investment multiplier than “free money” — if you’re willing to invest $1 of your own money, the grant may provide the equivalent of $3-5.

Model: Consulting

Sell services that make use of the open source or open data project, or the skills that you’ve acquired in the course of building the project.

Opportunities:

• You’ll know your open source tool or data better than anyone. You can build a consulting practice that provides extra value even though it sits on top of open code, data, or infrastructure.
• Consulting provides opportunities to learn new things and prototype new data sources and infrastructure systems that are at the margins of your experience because clients probably need something different than you do.
• Consulting clients are demanding users. They’ll tell you want works and what doesn’t.

Challenges:

• If your consulting practice diverges from the focus of the core project it can create internal division. Does it just exist as a cash cow to support the open source side of things? Or is it also an “internal customer” that benefits from the open source project? Ideally you want to set up a mutually reinforcing flow of value between the consulting practice and the open source project.
• It can be hard to balance choosing appropriate consulting projects with the need for income

Model: Sustaining Membership

Cultivate a group of institutional users who are committed to sharing ongoing maintenance and development costs because they rely on the project and want to mitigate the risk of it being abandoned or heading in a direction that doesn’t serve their needs.

Opportunities:

• Lets you fund maintenance that’s unlikely to be funded by grants, and can be expensive to fund with internal investment.
• Sustaining members can also provide focused feedback and help prioritize where new investments and improvements are made.
• Having a group of users pooling resources means you can fund larger projects that they all benefit from, but that no one of them would be able to pay for in isolation.

Challenges:

• Free-riders: if everything is open, who has an incentive to pay?
• If you don’t ensure that your sustaining members are aligned with the open project’s mission, inviting them into the governance of the project can take take it in directions you might not want to go.
• Your institutional users may not be representative of all users you want to serve. How do you integrate other outside stakeholder voices?
• Different organizations and different kinds of users may have very different willingness and ability to pay. Managing those disparities within project governance may be difficult.

Model: Tiered Access/SaaS

Provide different tiers of access to data or services, with some of them being restricted and paid. E.g. bulk annual data releases are free, but monthly releases require registration. Metered paid access beyond some free usage threshold.

Opportunities:

• Gives you the power to capture as much or as little value as you want.
• Requiring registration can provide detailed usage statistics and help you understand how your users are and what they’re doing, which can be challenging with truly open data and software.

Challenges:

• There’s a big temptation to start hoarding data or creating captive software platforms that privatize a growing portion of the value created once you’ve built the infrastructure to do so, which may lead away from the generation of public goods.
• Some users may lose trust in the project if you start down this path, especially if they’ve had negative experiences with captive platforms in the past.
• The restricted or paid access platform may be another piece of infrastructure you need to build or maintain, and be responsible for operating — potentially in a business critical context for users.

Other Tech Worker Co-op Resources

• Worldwide Directory of Tech Co-ops
• The Patio Tech Co-op Community 
• The US Federation of Worker Cooperatives
• Unlearning Economics on Worker Democracy (YouTube)
• Owning our Future by Marjorie Kelly (Book)
• A Brief History of Equality by Thomas Piketty (Book)
• Governable Spaces by Nathan Schneider (Book)
• The Shared Capital Cooperative Development Fund
• The Seed Commons Cooperative Development Fund
• Worker Self-directed Non-profits from SELC