�鶹��Ժ

Isn’t it weird that the radically democratic miracle of open-source collaboration is so full of monarchical dictatorships?

Take your pick of projects; “benevolent dictators” are everywhere. Linux has Linus Torvalds, WordPress has Matt Mullenweg, and Ethereum has Vitalik Buterin—all of them founders poised to enjoy (or not) lifelong, absolute authority. Even in the case of Bitcoin, whose inventor Satoshi Nakamoto may or may not be an actual person, enthusiasts cling to Nakamoto’s writings chapter-and-verse in debates about the meaning and future of the project. People seem to know no other way.

The open-source dictators are part of a broader pattern among online communities that I call “.” It has to do with a historical and technical norm by which platforms grant nearly absolute power to community founders and their appointed successors, whether in a Facebook Group or a GitHub repo. But as much as it confers absolute power, this primitive governance system often results in what the 1970s feminist activist Jo Freeman called a “.” Under the rhetoric of openness and meritocracy, an entrenched and disguised hierarchy reigns. Newcomers have a hard time knowing who is really in control. Outside companies can hijack and steer open-source development as long as they keep the dictators happy. This sort of medieval arrangement has also helped create the problem of open-source “”—or lack thereof.

At a time when so much of our lives and work are online, our online governance has never mattered more.

There are the exceptions to the feudal pattern. The Debian operating system has its liberal-democratic , and Wikipedia has its under “constitutional monarch” Jimmy Wales. When the self-described “benevolent dictator for life” Guido van Rossum stepped down from running Python, he set off a for a new model that resulted in a sensible elected board. Yet the exceptions prove the rule. They are outliers, each resulting from a deliberate, wheel-reinventing process that have not been widely replicated.

I find the feudal dictatorships a very strange norm. As someone with leadership roles in several online communities, also, I have experienced firsthand how badly equipped most platforms are for doing things differently. But I have also seen how a few simple rules can go a long way. When a large mailing list I administer adopted the as our code of conduct, we quickly went from being flummoxed for months by a troublesome member to resolving the issue rapidly. But, I noticed, the Contributor Covenant doesn’t say anything about why I hold the power I do or whether there are any limits on it. The only option for those who don’t like what I do is to leave.

Noticing this got me started on what became , a tool designed to help diverse groups—whether global open-source projects or local —to get their governance house in order. Like choosing a Creative Commons license, CommunityRule offers a palette of templates, from dictatorship to various flavors of democracy. Like the Contributor Covenant, a group’s “Rule” might sit in the background most of the time, needed only when a particularly thorny conflict or decision arises. Rightly or wrongly, however, CommunityRule differs from those by encouraging customization before you drop a Rule into your group.

I think of the governance that CommunityRule supports as a too-often-missing layer on a larger community “stack”—the gray one here:

Open-source communities tend to be really good at thinking through some of the other layers, like licensing, collaboration practices, and the underlying tech platforms. GitHub even encourages administrators to clarify those things at the outset. Projects lean on other layers of the stack to make up for the absence of the governance layer—keeping dictators at least a bit accountable through the culture of collaboration and through the platform’s built-in features. But basic tools for real accountability—the elections, the juries, the term limits—are nowhere to be found. Having a Rule in place at least makes explicit a shared intention to do those things one way or another.

Even in the case of a dictatorship—as many early-stage projects are and should be, including CommunityRule for now—being explicit matters. It helps avoid that tyranny of structurelessness, ensuring that the lines of responsibility are clear. A Rule also serves as a mirror, encouraging community members to ask whether the current structure really fits the nature of the community. Any Rule should include provisions for how the community can evolve its governance as it matures, as any community must.

There is in rethinking some of the basic expectations in open source. The , in particular, is establishing standards for what an ethical software project looks like and how its software can be used. I have with Ethical Source’s founder, Coraline Ada Ehmke—also the instigator of the Contributor Covenant—to include a provision in the that projects “must publish clear rules for project governance,” alongside a code of conduct. If a software community is to decide together about its ethical commitments and enforce a code of behavior, participants should be able to understand how those decisions are made and implemented.

Developing CommunityRule will continue to be a priority at the University of Colorado Boulder’s Media Enterprise Design Lab, which I direct, as part of our broader involvement in the . There is , and we could use your help—with user feedback, feature development, and simply spreading the word. Please let me know if I can help you get involved.

Regardless, take a moment to notice the governance layers of the communities and projects you are part of. What is stated, and what is not? How would you make explicit the ways they are operating with now, and what do you wish their shared agreements would say?

Also published .