Collaborative Governance

Change Is in the Cards: Governance Transitions in Open Source Communities

Nathan Schneider — Fri, 08 Nov 2024 15:22:46 +0000

Change Is in the Cards: Governance Transitions in Open Source Communities Nathan Schneider Fri, 11/08/2024 - 08:22

Adina Glickstein , Drew Hornbein , Nathan Schneider

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

Traditional

White

Get Our Latest Zine, on Open Source Governance: "Change Is In the Cards"

Nathan Schneider — Thu, 03 Oct 2024 16:01:03 +0000

Get Our Latest Zine, on Open Source Governance: "Change Is In the Cards" Nathan Schneider Thu, 10/03/2024 - 10:01

Adina Glickstein , Drew Hornbein , Nathan Schneider

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.

Off

Traditional

White

Governance Designs for an Open-Access Textbook

Anonymous — Tue, 27 Aug 2024 17:25:28 +0000

Governance Designs for an Open-Access Textbook Anonymous (not verified) Tue, 08/27/2024 - 11:25

Nathan Schneider

A new blog post 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 Introduction to Social Media course:

One of the pivotal moments in the book’s continued evolution came in 2022, when Nathan Schneider, an assistant professor from ��ý�Ļ��Ʒ (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, “contributors of any kind can become members of the project and collectively govern its future.”

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

Off

Traditional

White

Making the CommunityRule Library Searchable

Anonymous — Tue, 07 May 2024 16:08:54 +0000

Making the CommunityRule Library Searchable Anonymous (not verified) Tue, 05/07/2024 - 10:08

Rohit Taware

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 CommunityRule, 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 cosine similarity, 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

Traditional

White

New in CommunityRule: User Login, Rule Editing, and More

Anonymous — Wed, 03 Apr 2024 22:43:02 +0000

New in CommunityRule: User Login, Rule Editing, and More Anonymous (not verified) Wed, 04/03/2024 - 16:43

Rohit Taware

CommunityRule 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

Traditional

White

Designing for the Economy of Involvement in Co-ops

Anonymous — Mon, 27 Mar 2023 06:00:00 +0000

Designing for the Economy of Involvement in Co-ops Anonymous (not verified) Mon, 03/27/2023 - 00:00

Nathan Schneider

Imagine a world in which the cooperative movement has won. The old dream of a cooperative commonwealth 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 have made several 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 “economics of participation” in theoretical frameworks and diagnostic tools, 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 “spectrum of public participation”; 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 famously tumultuous meetings. 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 small co-op investment club. 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 Social.coop, 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 what happened recently 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 “ladder of engagement” 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, feminist economics reminds us, 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 at Ownership Matters. Thanks to Karen Miner and Sonja Novkovic for helpful feedback on an earlier draft.

Off

Traditional

White

CommunityRule Refactor Now Online

Anonymous — Fri, 20 May 2022 16:31:28 +0000

CommunityRule Refactor Now Online Anonymous (not verified) Fri, 05/20/2022 - 10:31

Nathan Schneider

Background

Last year, Smart Contract Research Forum provided a grant to CommunityRule, an open-source Web app led by MEDLab at ��ý�Ļ��Ʒ meant to serve as an interface for community governance design. The project was led by Deacon Rodda at SQGLZ, and I have already shared Deacon’s brilliant reflections on the project. Drew Hornbein took on the development work to implement Deacon’s recommendations. As I reported earlier, 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 PolicyKit and Modpol. 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 Metagovernance Project, 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 give the new CommunityRule a try and let us know what you think.

Also published at the Smart Contract Research Forum.

Off

Traditional

White

Meet the Sacred Stacks Cohort

Anonymous — Sat, 23 Apr 2022 21:32:16 +0000

Meet the Sacred Stacks Cohort Anonymous (not verified) Sat, 04/23/2022 - 15:32

Nabil Echchaibi , Samira Rajabi , Nathan Schneider

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 Filecoin Foundation for the Decentralized Web, we were able to add to the initial grant from the Henry Luce Foundation and double the cohort to six communities. Additional help from Starling Lab 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 (Guajajara) village (Barreirinha, Araribóia, Brazil)
Iraqi Journalists Rights Association (Baghdad, Iraq)
Kibilio Community & Farm (Western MA, USA)
Sans Souci Cooperative (Boulder, CO, USA)
Survivors Know (Chicago, IL, USA)
Unheard Voices Outreach (Nashville, TN, USA)
Yerba Buena Center for the Arts (San Francisco, CA, USA)

From now until December, this cohort will be learning from each other, from our collaborators at Hypha Worker Co-operative and the Tech Chaplaincy Institute, 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

Traditional

White

Designing Community Governance with Blockly

Anonymous — Tue, 15 Feb 2022 04:36:14 +0000

Designing Community Governance with Blockly Anonymous (not verified) Mon, 02/14/2022 - 21:36

Asher Farr , Nathan Schneider

CommunityRule is a Web app we've been building at MEDLab to help communities design, edit, and share their own governance systems. You can think about it as an effort to re-think the idea of bylaws in an Internet-native way. It's something that could be useful for all kinds of virtual communities, and we have developed it in partnership with open-source developers and mutual-aid groups. Currently, it is just a visual interface, but ultimately we hope it can export code for governance software tools.

As an experiment, we are currently attempting to re-implement CommunityRule in Blockly, an open-source library for block-based visual code editing. This gets us one step closer to converting the governance structures described by someone’s community into code that can be implemented—for example, by the smart contracts of a DAO, or by software like PolicyKit. Blockly has a built-in functionality for converting blocks into code. You have to define what the code is, but doing an initial implementation in Blockly gives us a skeleton that we can fill in with code later. Blockly also has a built-in notion of type, which makes it easier to define what blocks can go together, further providing structure for converting the blocks to code. Blockly also has built-in definitions for various common programming structures like loops, conditional statements, and arithmetic operations. Conceivably, these could allow users to define their own governance modules with considerable precision and modify already existing ones easily. Overall, a CommunityRule blockly implementation is intended to begin bridging between the purely visual representation that we have now and a programmatic representation.

The first experiment was making a modifiable block for a majority vote or a straw-poll. The block has several options. It allows users to set the winning threshold, which by default is 51 percent. It also has a quorum option, allowing users to specify a minimum number of voters required for a valid election. It takes as an input a candidate list and has a section to add more blocks that describe what to do if there is a tie. Theoretically, in a fuller implementation of CommunityRule, users could drop blocks into the tie section to describe what procedure to run if there is a tie, using other blocks.

This block raises a few questions about the implementation in terms of how much detail is required. One of CommunityRule’s goals is readability, but as you get deeper into the weeds of formality and require blocks to become programs, you need more and more details specified. For example, this block takes as an input the list of candidates which would be required for an actual program to run a majority vote, in addition to a list of votes, but it’s unclear how much of that detail should be available to the users and how much could remain on the back-end.

Here, for example, is the code behind the above module:

And the underlying JSON code:

While it may be possible to have the candidate list be present in the block but not shown to users, this is part of the difficulty with making the Blockly implementation. If something is necessary for the code but can reduce readability, we have to decide what will take priority.

Another question raised by this block is how the blocks fit together. CommunityRule, as it stands, mixes procedure and structure with no clear distinction. It’s equally easy to drag and drop blocks that define structural elements such as circles or boards with procedural elements such as majority voting consensus, without clearly defining how the structure interacts with the procedure.

This is acceptable in a purely visual implementation, because it relies on human intuition to determine how these things fit together, and there is no requirement of having a machine understand it. But with the Blockly implementation comes the question of how do we make structures and procedures talk to each other, and what connective tissue we have to create to do that.

For example, the majority-voting block currently has a “left output” configuration meaning that it “plugs in” to another block as an input instead of following after another block in a stack of instructions. What exactly it can plug into is still undefined, however. A solution for this might be to create a type system with clearly defined input and output types for each block, so the users can tell how blocks fit together, but this could lead to confusion along with the possibility of reducing the possible governance structures that are definable using CommunityRule.

One thing to try next is the implementation of the structural templates on CommunityRule, such as circles. So far, a little experimentation has been done to try and create a generalized structure block called a group, which should act as a sort of class initializer that would combine structure with procedure, along with some of the other CommunityRule blocks like values into an encompassing group structure.

We could also simply add more Blockly versions of CommunityRule blocks with additional configuration options. This would help us explore how they might fit together and what kinds of patterns they have in common.

Another next step is pursuing a more formal type system as discussed above, though the specifics of the type are still unclear. It appears that at minimum a distinction between blocks that dictate structure and blocks that dictate procedure must be established.

One other need, which has come up several times during the development of CommunityRule, is having some sort of questionnaire that guides the user through creating a governance structure. This could go a long way in improving usability by narrowing the options and creating a template that users can modify instead of expecting them to start from scratch.

Off

Traditional

White

Introducing Modpol, a Game Mod for Governance

Anonymous — Fri, 28 Jan 2022 21:30:53 +0000

Introducing Modpol, a Game Mod for Governance Anonymous (not verified) Fri, 01/28/2022 - 14:30

Nathan Schneider , Luke Miller

Modpol is a self-governance toolkit for communities in online worlds. We are creating the first implementation in a multiplayer game called Minetest.

Consider a group of friends meeting for a picnic in the park. How do they make decisions, such as where to lay down their blanket, or when the rain becomes too much? Easy, right? They read each other’s gestures, they hear each other out. Some of the friends might have more sway than others, but even they adopt the assumption that the goal is to make most everyone happy and prevent anyone from feeling really left out.

The rain becomes too much, in the end. They split up, go home, and meet on—well, take your pick: Discord, Facebook, Instagram, WhatsApp, or whatever. They’re the same friends, with the same basic instincts to watch out for each other. But now, weirdly, one of them is the admin of their online group, just because she happened to set it up. She alone can censor and remove people at will, change the group settings, change how their interface looks—the works. Maybe this is fine, because everyone trusts her to act like they would if they were all together. But what if she doesn’t? What if her friends start being more careful not to disagree with her because of the absolute power she holds over their little space? What if the power that the software endows in her gets to her head?

The strange politics of our online tools amounts to an “implicit feudalism”—a rarely noticed nudge that inclines our interactions toward rigid hierarchy and draconian punishments, with no accountability through elections, due process, or term limits. The feudal defaults emerged from the earliest online communities on bulletin-board services, which mimicked the permission-control systems in the innards of computer software. We accept our admins and mods as normal and expected, often without noticing how foreign those roles are for virtually any voluntary coming-together among people in other areas of life.

What if our online communities had the tools to practice a fuller range of self-organized possibilities?

We are part of a network called the Metagovernance Project, which is experimenting with building such tools. “Modular Politics” is a proposal we developed that outlines basic principles for online governance tools, such as:

Modularity: Platform operators and community members should have the ability to construct systems by creating, importing, and arranging composable parts together as a coherent whole.

Expressiveness: The governance layer should be able to implement as wide a range of processes as possible.

Portability: Governance tools developed for one platform should be portable to another platform for reuse and adaptation.

Interoperability: Governance systems operating on different platforms and protocols should have the ability to interact with each other, sharing data and influencing each other’s processes.

We decided to try implementing Modular Politics in a place where people are already meeting as peers, on their own terms: Minetest, an open-source, community-created, world-building game. It resembles the more popular, Microsoft-owned game Minecraft. Our Metagov colleague Seth Frey did a large study of Minecraft servers and found that autocracy is the norm; but would that still be the case if gamers had a different set of tools?

Translating the Modular Politics proposal into code has raised loads of questions that we never considered when it was all just in our heads and in words. We have had to appreciate more deeply than ever that software design is a political act. How we shape the inner workings and outer interactions will guide users’ expectations and behavior. Engineering decisions shape the kinds of communities that users end up creating.

Modpol, as we call our implementation, is still very much a work in progress. (Come pitch in here!) But there are a few design decisions we have made so far that we’re excited about—decisions that shift from the feudal defaults to defaults that are more consentful, even communal. Whatever you call them, these choices seem to better reflect how human beings in the wild actually behave together.

Groups, not roles. Rather than assigning particular powers to particular users, Modpol assigns powers to groups, which we call “orgs.” Orgs can determine how to use those powers and how to make decisions about them, but ultimately it is on the level of group membership, not individual permissions, that things happen.

Consent, not oligarchy. The default decision-making process for orgs is consent of all members. This might sound utopian, but we believe it best resembles how groups of peers actually tend to interact, and it works so well most of the time that we don’t even notice it. Ultimately, we hope to see a wide range of other governance “modules” that orgs can adopt, from clever voting schemes to juries and more. Users can decide to create an autocracy if they want, such as by delegating decisions to an org with only one member. But in Modpol autocracy is something that must be actively chosen by the members of an org—the “consent of the governed”—rather than being the presumption at the outset.

Inheritance, not blank slates. Most online platforms treat communities as parallel, indistinguishable software objects with no particular relationship to each other, each a blank slate upon its creation. Real social life, however, is infused with habit, tradition, and muscle-memory. Modpol attempts to reflect that. New orgs form within existing orgs, and they inherit the rules of their parents. Those rules can be changed. But the rules begin with whatever users were already doing before, so they can work with what they already know rather than starting from scratch.

Minetest is a game for building worlds. Really, it’s an engine for many games, which players have developed and shared with each other. What nearly all Minetest games have in common is that they are places to build—block upon block. Players explore landscapes, gather resources, and use them to create the kinds of spaces they want to inhabit and show off.

Modpol is also meant for building. Players can create worlds of interlocking orgs, each with their own rules and processes. Modpol could be used to organize teams for Capture the Flag, or to govern an anarchist castle. It could enable experiments that explore the features and bugs of various ways of organizing and decision-making. Minetest is an engine for manipulating blocks in virtual space; Modpol is an engine for manipulating the flows of online politics.

Within orgs, users can choose the set of modules available to each other. In doing, they can craft their own rule-sets. They can create their own modules (for now, most are about a page-worth of code). Modules can call modules, which can call modules; what starts as simple can quickly become complex.

The code is in Lua, the language Minetest understands. Lua was first developed in Brazil in the early 1990s as a lightweight language for embedding extensions into bigger programs. It is quirky and elegant, without the features and libraries it would need to run complex, modern programs on its own. In Portuguese, lua means “moon.” Lua programs are orbiters, circling around other programs. They make no claim to be self-sufficient. This is fitting, because there is no point in governance tools without a world and a community worth co-governing.

We are constructing Modpol in orbits. There is spaceship modpol_core/, where most of the code lives, which can go anywhere in space but only works on the command line, just spitting out its lonely reports on its status in text.

But when paired with the code in modpol_minetest/, Modpol has a map for planet Minetest. Maps could be built for other Lua worlds—maybe Roblox, maybe Angry Birds, and lots more.

With this design, we hope that someday Modpol will travel to other worlds. But for now we go on assembling this prototype. We’re working with members of the Minetest community, who are skilled in the arts of commoning. Before leaving their orbit, we want to offer something of value to this particular species of world-builders, and learn together some lessons about the intergalactic possibilities in our minutest feats of community.

Download Modpol, and explore the code, along with documentation by MEDLab research fellow Skylar Hew. Learn more about what we’re up to at the Metagovernance Project and the Media Enterprise Design Lab at the University of Colorado Boulder. We can’t wait to see what play this politics enables.

Off

Traditional

White