Off

I’ve seen it again and again: A group gets started, gets working on something good an important, and then falls apart because some internal conflict arises. During the early days of Covid-19, mutual aid projects appeared in many towns and neighborhoods to help people help each other through a difficult time. It was inspiring. But in the years since, I have kept hearing stories of how what I then came to pass. When the initial excitement wore off, or when donations declined, little and big disagreements tore most of those groups apart.

Because of the lockdowns, many of those communities relied heavily on online tools to communicate. There, shooting off an insult or pressing “unfollow” are easier to do than their face-to-face equivalents. Further, starting with the earliest online communities in the 1970s and 1980s, a design pattern of “implicit feudalism” took hold. From Facebook Groups to group chats, social-media software assumes that there should be an all-powerful admin or moderator; the primary tools for problem-solving are digital censorship or exile.

By and large, that is, online platforms are not well designed for communities to self-govern. The usual methods for group governance offline—explicit bylaws, boards of directors, Robert’s Rules of Order, and so forth—are almost nowhere to be found online. Our online spaces still have yet to catch up to the lessons learned from offline ones. If we want to build for our communities, we need to be intentional about it. The software won’t do it for us.

In what follows, I’ll suggest a series of steps for how online communities can set themselves up for healthy problem-solving. This is not a complete program or a universal script, but it can serve as a checklist of questions that you can apply to your particular context. You should decide what is most relevant.

Codes of Conduct: What are the basic expectations?

For years, software developer Coraline Ada Ehmke the conferences she attended to adopt clear codes of conduct. At first they refused, claiming that such rules were unnecessary. But Ehmke, as a trans woman, knew how toxic those spaces could be for marginalized participants, and she helped more people raise their voices, too. Now, the she created has become a widespread norm in tech communities.

When a code of conduct is in place, it is easier for leaders to enforce basic expectations of decency. A code of conduct reduces the gray area and the temptation to tolerate toxic behavior.

When you’re setting up a community space, adopt a battle-tested code like the Contributor Covenant. What I often do—at the start of a class or the first meeting of a new group—is share the Contributor Covenant and invite participants to edit it. Based on their ideas, we create our own version attuned to our needs.

Rules: How does power flow?

There are important questions a code of conduct doesn’t answer: Who has the right to implement the rules and change them? If there are specific leaders, how are they accountable to others in the group?

Offline organizations often answer these questions in their bylaws—a document written in formal legalese, with off-putting jargon and turns of phrase. When MEDLab started building a platform to help mutual-aid groups self-govern, we called it , inspired by how some monasteries call their ancient bylaws simply a “.” Online communities don’t need legalese, usually. They just need some basic protocols in place for how decision-making works and how their norms should evolve.

Disputes: How do you resolve conflicts?

Even when there is a code and a rule in place, ambiguities will arise. People will feel harmed by others, and they will disagree about how and why. In the rule or elsewhere, plan ahead for how the community will resolve disputes. What does a legitimate resolution look like?

I have taken a lot of inspiration on this point from for “”—efforts to address harm in more holistic ways than resorting to policing and incarceration. But work is needed to make these processes accessible, especially for online contexts. This is something MEDLab plans to focus on in the coming year.

Economies: What resources and rewards are needed?

In many online communities, the underlying economies are hidden from view. Someone may be in a position of managing the community because they are paid to do it by their job, or because they have a job that affords them the time to do it outside of paid work. A community might seem almost magical when economies are hidden, because it creates an experience of a gift economy, of pure voluntarism. But over time such systems often leave people without access to the economic flows feeling .

Try to make the economies at work in your community explicit. If they don’t seem fair, talk about how to make them fairer. The platform is designed for communities that want to make their financial transactions transparent; hard conversations may be easier if there is a shared source of truth. If your community creates content, be sure to decide on the terms for sharing it, such as by adopting or licenses.

Stacks: Who controls your tools?

Ultimately, self-governance in online spaces should involve some ability to govern the tools we rely on. Even platforms like Reddit and Discord, which give admins wide latitude to customize their spaces, can always change the tools on you or pull the plug. The dominant online economy does not make it easy for communities to control their own tools. Any little bit of control you can get, at least, is a step in the right direction.

Here at MEDLab, a set of open-source collaboration tools together thanks to platforms such as , , and . We can do this at relatively low cost and without tech support—just a willingness to try things, endure mistakes, and learn. New_Public has a handle full of examples of things you can try. Even if you don’t have the skills for managing a server, keep asking: How could we self-govern our tools a bit more fully?

Share what you learn

Building governable spaces shouldn’t require reinventing the wheel. First, draw lessons from offline practices you’re familiar with; they are often perfectly applicable to online life, with a few tweaks. When you take steps in the direction of self-governance, share your lessons and best practices so others can learn from them. On CommunityRule, there is a where users have shared their rule designs for others to copy and adapt. When you start or enter a community, try to ensure that the basics are in place—a code of conduct and at least a simple rule for decision-making and accountability.

The things I’ve discussed here are bedrocks. What really makes communities healthy is what you build on top of them. Most of the time you shouldn’t need to worry about codes of conduct and rules, because your culture should take care of itself. But having those bedrocks there, when the culture breaks down, can be the difference between survival and collapse. For all the codes, rules, and tools you adopt, remember that the art of community governance always involves treading in mystery.

Off

Download for screen reading

Download for booklet printing

Download for standard printing

Waves of uncertainty swell around you. They threaten to consume you with confusion as they crescendo. Where do you and your community turn?

Since its invention 15th-century Italy, tarot has been a technology of sense-making often used as a starting point for reflection, divination, and introspection. By consulting the cards and considering their relevance to the problems that face us, these technologies can help us forge answers to the existential queries that arise across a lifetime of complexity and change.

We invited practitioners from various open-source communities to use the tarot as a tool for sense-making about governance transitions they have witnessed or participated in. We consulted the tarot, pulling cards for each contributor and encouraging them to interpret these cards as they may—conjuring wisdom about community governance, especially in moments of liminality and transition.

Making open-source software is a way of collectively speaking new possibilities into existence. Programming and community-building both are forms of practical magic: the writing and implementation of codes, spells, or “magic words” that do things in the world. Governance is the stewardship or oversight of these processes. By demystifying certain aspects of it (and mystifying others!), we can help communities operate more effectively and democratically.

Our hope is that this zine will be an open-ended starting point—a forkable resource—that can help others navigate growth, transition, and all kinds of impasse, in software development and far beyond. 

Edited by Adina Glickstein, Drew Hornbein, and Nathan Schneider. Design by Ritual Point Art & Divination. A project of the Media Economies Design Lab at the University of Colorado Boulder. This material is based upon work supported by the National Science
Foundation under Grant No. 2217654. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

Off

Download here

While supplies last, get the newest MEDLab zine, a tarot-infused exploration of governance transitions in open-source software communities. A free online copy will be available for all.

Waves of uncertainty swell around you. They threaten to consume you with confusion as they crescendo. Where do you and your community turn?

Since its invention 15th-century Italy, tarot has been one technology of sense-making often used as a starting points for reflection, divination, and introspection. By consulting the cards and considering their relevance to the problems that face us, these technologies can help us to forge answers to the existential queries that arise across a lifetime of complexity and change.

We invited practitioners from various open-source communities to use the tarot as a tool for sense-making about governance transitions they have witnessed or participated in. We consulted the tarot, pulling cards for each contributor and encouraging them to interpret these cards as they may— conjuring wisdom about community governance, especially in moments of liminality and transition.

Making open-source software is a way of collectively speaking new possibilities into existence. Programming and community-building both are forms of practical magic: the writing and implementation of codes, spells, or “magic words” that do things in the world.  Governance is the stewardship or oversight of these processes. By demystifying certain aspects of it (and mystifying others!), we can help communities operate more effectively and democratically.

Our hope is that this zine will be an open-ended starting point—a forkable resource—that can help others navigate growth, transition, and all kinds of impasse, in software development and far beyond. 

Off

A on the Pressbooks website recounts MEDLab's role in supporting the development of a governance strategy for the textbook Humans R Social Media, which I use in my :

One of the pivotal moments in the book’s continued evolution came in 2022, when Nathan Schneider, an assistant professor from ���������� Boulder (and contributor to the most recent edition), reached out to thank Daly for the book. This began a conversation about continuous updates, and an idea was born to turn the text into a “living book”. 

Currently Daly and Schneider are creating a shared governance plan for this book to go on continuously with annual updates managed by a group of collaborators. They are using processes modeled on open source software, something Schneider has deep experience with having previously worked with founders of open-source software projects to help them transition toward forms of community-centered governance.

The project involves a growing number of collaborators, and is always open for input, according to an open invitation included in the textbook itself. Whether it’s students suggesting improvements or faculty proposing new chapters, “.”

Read more about the project . Thanks for the collaboration of Hibah Ahmad throughout the process, as well as financial support from the Colorado Department of Education.

Off

Creating an effective way for users to navigate and utilize an online platform with extensive content can be a challenge, particularly for new users unfamiliar with the site’s structure. This was the case with , our online tool that hosts a growing library of user-created governance designs and existing templates. Newcomers often find it daunting to search for and locate specific rules or communities relevant to their interests. To address this, we embarked on a journey to enhance user experience through the implementation of a chatbot aimed at simplifying the search process.

Initially, we explored options based on the new crop of AI systems, particularly large-language model chatbots. But the complexity of that approach quickly got out of hand for a platform meant to be simple, open-source, and inexpensive to host. The solution we devised involves the use of a basic search tool powered by , an algorithm that measures the cosine of the angle between two vectors. This method is particularly suited for text comparison, making it an ideal choice for matching user queries with relevant content in our database. By analyzing the text input by users and comparing it to existing descriptions of rules and communities, the chatbot can suggest the most relevant matches, thereby streamlining the search process. Although we departed from the idea of having a conversational chatbot, we retained the chat interface for this search tool.

How to search CommunityRule

You will find the search icon at the bottom-right of the website, which will open a chat prompt as follows:

After searching with keywords, the tool returns the top five best matches as responses. The user can click a link and see that rule.

With the search-enabled chatbot in place, navigating CommunityRule has become significantly more accessible to new users. They can more easily find communities and rules that match their needs, enhancing their engagement and participation on the platform.

Off

is a tool that helps make communities better by providing a central place where people can create and share governance designs for their communities. It offers nine simple templates for setting up community structures. Communities can follow, modify, or even decide not to use these templates. They are meant to start discussions, inspire new ideas, and encourage feedback.

Since CommunityRule was first developed as a prototype by MEDLab, it has lacked certain important features. For example:

• User logins: There was no option for users to create personal accounts or log in.
• Robust database: The site lacked a robust database. It relied on a simple Google Sheet to manage the library of user-generated rules. This presented limitations on data storage, as well as yoking the project to an external platform.
• History of rule versions: The website didn’t keep a record of old versions of rules, making it difficult to see how rules evolved over time.
• Editing rules: The website did not allow users to edit the rules they had created. This could affect their ability to make changes or updates to the guidelines as a community evolves.
• Permissions: There was a lack of proper structure of permissions on who can delete or edit rules.

To address these missing features, and to establish a firmer foundation for CommunityRule development, we introduced a few new features to our existing platform.

Database: Database and editing tool enhancements will make it easier for users to find relevant information and customize it to their specific community needs, thus improving the overall usability of the platform. Users will find it more convenient to access relevant information, and the customization options will empower them to adapt the platform to their community's unique needs. MySQL is the chosen database management system for the backend. MySQL is a widely used relational database that provides a robust and scalable solution for storing and retrieving data.

REST API: We developed various Representational State Transfer (REST) APIs. REST is an architectural style for designing networked applications, and in this context, it's used to create a set of standardized endpoints for communication between the frontend and backend. The REST APIs are exposed from the backend, meaning they are made available for external applications (such as the front end of the website) to interact with. Node.js is employed as the backend technology. Node.js is a JavaScript runtime that allows developers to use JavaScript for server-side scripting. It is known for its efficiency and asynchronous, event-driven architecture.

Login functionality: We introduced a new login functionality where users can manage their own rules. Upon clicking the Login button, users will see the following prompt to enter an email address:

Once the user clicks on the Send Code button, the provided email address will receive a unique 4-digit code. An email will be from hello@communityrule.info; the subject of the email will be the “Logging code for community rule,” and the content will be of the following format “Code for logging into community rule is XXXX.” The user will be prompted with the following new prompt to enter the code:

Now the user needs to enter the correct code to log in. If the code is correct, the user is logged in. If the code is incorrect, the user will see an error message. The user can also ask to send the code again. Once successfully logged in, the user will see a user icon, as shown in the following screenshot. The user can then click on that icon to see the logged-in email address.

If you click on the logout button, you will be logged out of the website and you will see the login button again.

You need not be logged in to see the rules in the library, or even to create a new rule. Logging in is necessary only for publishing rules and for editing or deleting rules you have previously published. When you publish your rule using your email address you will be considered as the owner of the rule

Library options: The library will list all the rules that have been published till now from the new database we created. Now when the user clicks on any rule it will be loaded into the window as follows which will have the Edit and Delete buttons as shown below.

Edit: If you are the owner, you will now be able to edit your rule. We introduced a new button, Edit, which will be visible only to the owner of the rule—the rule’s original creator, i.e. you created the rule. If you are editing the rule, however, you won’t be able to change the name of the rule; the rule name will be read-only.

Delete: You will be able to delete the rule if you are the owner of the rule or an admin. If any rule is deleted, it will no longer appear in the Library.

If you are not logged in, or you are not the owner of the rule, you will not see those buttons. As before, all users (whether logged in or not, whether owner or not) have the ability to use the Fork & Edit button to copy the rule and edit it. Rule owners who want to change the rule’s name will need to use this functionality.

Fork history: In the Library of user-generated rules, the fork history of any rule is now recorded at the bottom. If the rule was not forked from another, no fork history will be visible. Deleted rules will still be visible in the fork history but they will not be publicly visible.

These changes are important steps toward making CommunityRule a more sophisticated, user-focused, and versatile tool. By addressing current limitations and expanding its functionalities, we aim to solidify its role as an essential resource for communities seeking effective organizational structures and governance models.

Off

Imagine a world in which the cooperative movement has won. The old dream of a  has arrived. You go about your day from cooperative to cooperative—shopping, working, scrolling on apps, and utilizing infrastructure all under the aegis of economic democracy. What a wonder! What a victory. The revolution is here.

And then, you realize, you’ve got some meetings to go to. A lot of meetings! Too many meetings. How can do you them all, and work your co-op shifts, and still have a life left to live?

I am going to argue here that a successful cooperative movement requires co-ops with a spectrum of involvement, from low to high. Involvement in governance is an economy, because nobody can be infinitely involved in everything. Like any economy, there should be different niches. Some co-ops can be designed for high member involvement, while others expect much lower involvement. This is already the case in practice, of course, though I don’t think we have a language to appreciate the value of the full spectrum.

People involved in co-ops, I have noticed, often love to categorize. They distinguish their type of co-op from yours, and pass laws that enable one type of co-op but not another. They mumble about which type is and is not a real co-op. They love to make directories based on their categories; I  made  myself. But the usual categories fail to notice the economy of involvement.

The most common set of categories has to do with who the members are: consumer co-ops, housing co-ops, marketing co-ops, worker co-ops, and multistakeholder co-ops. There are also more movement-based categories, like platform co-ops, solidarity co-ops, and union co-cops. The list goes on.

One way in which all the above types of co-ops vary among themselves is the expectation for member involvement. Studies of worker co-ops have often explored the “” in  and , and this is because the space for involvement among employee-owners varies a lot. I have seen worker co-ops where the workers make every major decision through a strenuous consensus process, and others where designated managers decide virtually everything.

But this economy is not just limited to worker co-ops. Governments, for instance, talk about the “”; economies of time and attention lurk wherever shared governance does. I used to be part of a neighborhood credit union that held annual meetings as block parties; in the one I now belong to, the meeting is a poorly attended rubber-stamping affair. Usually the amount of involvement tracks inversely with scale, though not always; the Park Slope Food Co-op has a massive membership but also required work shifts and . Most low-involvement co-ops started much smaller, with high involvement from their early members.

One reason that we don’t talk about involvement levels is that co-ops at each end of the spectrum don’t like to admit to their counterparts’ existence. People devoted to a high-involvement co-op or two often view low-involvement co-ops as a sham, as too compromised by their bureaucracies and hierarchies to really be considered co-ops. At the same time, the heads of larger, more bureaucratic co-ops might see high-involvement models as admirable, at best, but lacking sufficient economic scale to be taken seriously. So each side of the spectrum goes on its way, ignoring the other.

In a cooperative commonwealth, however, I think we will need both. They will feed each other. I appreciate both in my own life. As someone with financial acumen composed mainly of vibes, I am grateful that I have basically no involvement in the running of my large, sophisticated credit union. My fellow members would have no business trusting me, and I am happy to put my trust in the well-qualified board members. But I love that I get to learn more about business through my . I have only a passing interest in outdoor gear, so I don’t mind that my REI membership offers just a loyalty kickback. But as someone who studies social media for a living, I have loved being part of , a high-involvement, volunteer run social network.

I suspect others would flip all those priorities around, and we should all have that option.

Low-involvement co-ops can operate at large scales with professional management, who have time and expertise not available to the average member. They have a lower bar to entry for members, which makes joining the cooperative commonwealth easier. They may offer some member education, but there is little incentive to do very much. Member involvement may be limited to electing board members or voting on a proposed merger. But members can at least feel assured that the CEO’s job is to serve their interests—not to enrich outside shareholders. Because of their responsibility to members, managers will tend to operate conservatively, not wanting to risk member satisfaction on uncertainties. These are the co-ops we can trust with the parts of our lives where we have the least margin for error.

High-involvement co-ops, meanwhile, embrace the friction. Member participation is part of the goal, not just a means of achieving something else. There are ample opportunities for member education, since the co-op depends on members being knowledgeable about its functioning. These co-ops can be laboratories of radical possibilities, generating new social movements and demonstrating models that others fear to try. These co-ops are eager to learn from and support other co-ops wherever they can. They have access to energy and volunteerism that allows them to do great things with far less money than co-ops that rely on salaried employees. They are the beating heart of the movement.

On a spectrum, nothing is all the way on one side or the other, so everything is somewhere in the middle. Most co-ops blend low and high involvement in governance, striking a balance that works (or doesn’t work) for members and managers alike. Each situation has its equilibrium. Many co-ops are still searching for theirs.

When member involvement gets too low, a co-op becomes vulnerable—to management capture, for instance, or to demutualization, like  to Canada’s Mountain Equipment Co-op or to many once-mutual insurance companies. When members aren’t watching, a co-op can become a honeypot for profiteers. At the same time, too much member involvement can make governance unwieldy and prevent people from joining who lack ample leisure time.

I would like to see more hybrid examples. A large, low-involvement credit union could enable high-involvement lending circles or assemblies among its members. A high-involvement worker co-op can access economies of scale in its supply chain by joining a low-involvement purchasing co-op. Pockets of high involvement can keep low-involvement co-ops more honest, while areas of low-involvement can bring helpful efficiencies to high-involvement co-ops. A “” can chart a path for members to move, over time, from low involvement to well-informed high involvement. When co-ops expect high involvement from members, , it should be invested in and supported. Governance is work, and it cannot simply be left to those with lots of extra time in their lives.

The point of noticing the spectrum, and honoring different points on it, is to aid in the search for the right balance. Co-ops could be more intentional, for instance, about naming what levels of involvement they aim for, setting clear expectations among members and managers. They should articulate why they design involvement that way and not another way. At the same time, they should be willing to articulate the value of leadership alongside collective governance. The goal of member governance should be not to stifle strong leaders, but to ensure leaders are accountable in the right ways.

Members, also, have to find the right balance for themselves. They should be able to decide where they want to direct their limited time and energy—what gives them joy to do and what they would rather have done for them. The cooperative commonwealth would not be worth having if it leaves us with less leisure than capitalism.

Attention is a capacity that we need to use intentionally—both in our lives and our organizations. Allowing it to come in many forms is a kind of care.

Originally published . Thanks to and for helpful feedback on an earlier draft.

Off

Background

Last year, to CommunityRule, an open-source Web app led by MEDLab at ���������� Boulder meant to serve as an interface for community governance design. The project was led by , and I have already Deacon’s brilliant reflections on the project. took on the development work to implement Deacon’s recommendations. Asher Farr did some experiments with reimagining CommunityRule in Blockly.

CommunityRule was initially developed as a demonstration project by me. While it achieved some exploratory adoption, the (badly designed!) technical underpinnings limited its ability to be modular and adaptable to new challenges.

Results

The SCRF-funded project enabled some important advances:

• Refactoring the application code from vanilla JavaScript to the much more advanced Vue.js
• Moving the database from raw HTML to JSON/YAML, enabling vastly improved data portability
• Redesigning the authoring interface to be more self-explanatory, responsive, and flexible
• Encouraging custom module design as the default, rather than relying on pre-written modules
• Small adjustments in nomenclature and usability

Discussion and Key Takeaways

These changes bring us closer to the goal of connecting a) a visual design interface with b) programmable governance software. For example, we hope that CommunityRule can be used in the future for designing and implementing governance processes using DAO technologies and Web2 services like and . Moving to a JSON-based data model enables us to much more easily do things like:

• Add arbitrary data fields on governance modules
• Deploy custom instances of CommunityRule with custom module sets
• Translate modules into working governance code

One important insight during this process, aided by the Blockly experiment, was recognizing the need for governance modules to be much more precisely specifiable, rather than simply being described in natural language text. As we move closer to enabling computable rules on CommunityRule, we need to gradually lessen our dependence on natural language and support appropriate machine-readable data models.

Implications and Follow-ups

We will continue to develop the basic software for usability and new features. This process will be spurred by much larger pending grant projects, in partnership with the , which we hope will fund CommunityRule development for use by open-source communities and integration with PolicyKit, respectively. Thanks to the groundwork provided by this phase of development, we can hit the ground running on those efforts.

Thank you, SCRF, for your support! And we invite anyone interested to and let us know what you think.

at the Smart Contract Research Forum.

Off

In February, we announced an open call for Sacred Stacks, an invitation to "Bring Decentralized Tools to Your Community." We were astonished by the response. Around fifty communities applied for only three available slots. Clearly, there is a widespread need and curiosity for support in exploring emerging technologies in the context of community.

Thanks to support from the , we were able to add to the initial grant from the and double the cohort to six communities. Additional help from meant that we could add one more. We are grateful for these partners. With their help, we are thrilled to be able to announce the Sacred Stacks cohort:

• (Barreirinha, Araribóia, Brazil)
• (Baghdad, Iraq)
• (Western MA, USA)
• (Boulder, CO, USA)
• (Chicago, IL, USA)
• (Nashville, TN, USA)
• (San Francisco, CA, USA)

From now until December, this cohort will be learning from each other, from our collaborators at and the , and from guests who join our meetings. At the end, we'll assemble resources based on our experience to inform other communities interested in greater self-governance in relationship to their technologies.

Off