synopsis

A project designed to create a trust-based, decentralized framework for governance within grassroots networks and communities. Rooted in the #4opens principles—open data, open source, open processes, and open standards—the #OGB seeks to mediate human-to-human collaboration by fostering trust, transparency, and simplicity (#KISS).

Its primary focus is addressing the #geekproblem by bridging technical and social flows, creating tools that empower people to organize effectively without falling into hierarchical or centralized traps. The #OGB builds on trust to sift through noise, allowing genuine contributions to rise, moving from complexity to simplicity and back to complexity organically.

The expected outcomes include:

Strengthened grassroots governance: Tools for decision-making and collaboration that are inclusive and scalable. A thriving #openweb ecosystem: Platforms and networks that prioritize trust and social value over profit. Mediation of mainstreaming and NGO influence: Keeping progressive activism focused on spiky, meaningful change rather than fluffy distractions.

The #OGB aims to create sustainable digital commons that nurture resilience, diversity, and real-world impact.

experience

Yes, I’ve been involved in projects and communities aligned with the ethos and goals of the #OGB. My contributions span technical development, advocacy, and fostering open governance frameworks, all rooted in the principles of trust, transparency, and collaboration.

Indymedia, I was an active contributor to the global Indymedia movement, which played a pivotal role in grassroots media and decentralized collaboration. My contributions focused on: Open publishing workflows to empower communities to share their stories. Advocating for the “trust at the edges” model to ensure decision-making remained grassroots-driven. Bridging technical and social challenges by helping develop and maintain tools that aligned with the movement’s values.
OMN (Open Media Network), As one of the key proponents of the #OMN, I’ve worked to reboot grassroots media using trust-based networks and federated tools. My contributions include: Developing the concept of #4opens (open data, open source, open processes, open standards) to serve as a foundational framework. Advocating for federated tools like #ActivityPub and #RSS to enable media flows across decentralized networks. Organizing collaborative spaces to design tools that prioritize human-to-human trust rather than algorithms or centralized control.
Fediverse Advocacy, Within the Fediverse, I’ve championed the importance of grassroots governance and resisting the co-option of these spaces by corporate or NGO interests. Contributions include: Participating in discussions to shape decentralized protocols like #ActivityPub. Pushing for #KISS (Keep It Simple, Stupid) principles to ensure accessibility and scalability. Highlighting the dangers of #mainstreaming and proposing strategies to mediate its impact on the #openweb.
Open Governance Experiments, I’ve collaborated on smaller experimental governance projects aimed at exploring new ways of mediating human collaboration. For example: Designing trust-based moderation systems to reduce #geekproblem domination in decision-making processes. Implementing open-process methodologies to ensure transparency in workflows. Mediating conflicts between technical and social contributors, fostering productive collaboration.

Core Contributions Across Projects, across all these initiatives, my primary focus has been on bridging the technical and human aspects of governance. This involves: Developing frameworks that enable decentralized decision-making while maintaining trust. Advocating for simplicity to combat the paralysis caused by unnecessary complexity. Building alliances and mediating the challenges posed by #dotcons, #NGO dominance, and #geekproblem tendencies.

Through these efforts, I’ve gained insights into the challenges of building sustainable governance models in decentralized spaces, and the #OGB embodies the culmination of this work. It’s a step forward in creating robust, trust-based networks that empower communities to take control of their digital and social spaces.

usage

Budget Allocation for #OGB Project

The requested budget will be allocated strategically to ensure the project’s foundational development and long-term sustainability. An outline of key areas:

Technical Development and Infrastructure (40%) Development of Core Tools: Funding will support developers to build the initial version of the #OGB code, focusing on simplicity, accessibility, and scalability. Server Infrastructure: Setting up and maintaining federated servers for testing, development, and early adoption. Integration with Existing Standards: Work to align with protocols like #ActivityPub, #Nostr and #RSS, ensuring seamless interoperability with the broader #openweb ecosystem.
Community Building and Outreach (25%) Workshops and Training: Organizing sessions to train communities on the #OGB framework, focusing on trust-based governance and open-process workflows. Content Creation: Developing accessible documentation, tutorials, and guides to demystify the #OGB model for diverse audiences. Engagement Campaigns: Reaching out to grassroots organizations, activists, and communities to onboard early adopters.
Research and Iterative Design (20%) User Feedback Loops: Conducting trials with early adopters to gather insights and refine the tools and processes. Governance Framework Refinement: Exploring different trust-based models to ensure inclusivity and adaptability to various contexts. Conflict Mediation Strategies: Testing and integrating mechanisms for conflict resolution and power balance within the #OGB framework.
Administrative and Miscellaneous Costs (15%) Project Coordination: Funding part-time coordinators to manage timelines, resources, and community engagement. Operational Expenses: Covering software donations, events, domain hosting, and other minor but essential operational costs.

Past and Present Funding Sources. The #OGB project is currently unfunded in a formal sense, operating entirely through volunteer contributions. However, it is rooted in a history of collaborative efforts from related initiatives, which have benefited from in-kind support rather than direct funding.

Past Sources: #OMN and #Indymedia Communities: Provided foundational concepts and voluntary contributions of time, skills, and infrastructure. Fediverse and #Activertypub Advocates: Offered insights and testing environments for early experimentation with governance ideas.

challenges

Present Sources: Volunteer Contributions: Core contributors are donating their time and resources to push the project forward. Allied Projects: Informal support from related decentralized tech communities, sharing knowledge, feedback, and occasional resources.

Future Vision, while external funding is vital to accelerate the project’s development, we aim to maintain independence and adhere to the #4opens principles. By minimizing reliance on corporate or NGO funding, we ensure that the #OGB remains a grassroots-driven initiative. Our long-term goal is to establish a self-sustaining model through community contributions and shared ownership, embodying the trust-based governance the project seeks to promote.

Detailed budget breakdown can be attached if required.

comparison

The #OGB (Open Governance Body) project stands on the shoulders of both historical and contemporary efforts, drawing lessons from their successes and failures to craft a novel path to decentralized governance.

A comparative analysis: Historical Projects and Their Influence

Indymedia (Independent Media Centers) Overview: Indymedia was a global network of grassroots media collectives that emerged in the late 1990s to provide a platform for independent journalism. It embodied principles of openness, decentralization, and non-hierarchical governance. Comparison: Like Indymedia, #OGB aims to empower communities through open and decentralized structures. However, Indymedia struggled with governance conflicts and centralization of power in some regions. The #OGB addresses these issues through trust-based networks, conflict mediation mechanisms, and scalable governance tools. Key Takeaway: The #OGB builds on the ethos of Indymedia while implementing technological solutions to mitigate governance bottlenecks.

Occupy Movement’s General Assemblies. Overview: Occupy’s assemblies were experiments in direct democracy, emphasizing inclusivity and consensus-based decision-making. However, the lack of structured governance led to inefficiency and internal conflicts. Comparison: The #OGB shares Occupy’s commitment to participatory governance but incorporates trust-based models to build the decision-making. Instead of full consensus, the #OGB employs trust networks to delegate decisions while retaining accountability and inclusivity. Key Takeaway: The #OGB leverages structured trust-based governance to overcome the decision-making paralysis often seen in consensus-driven movements.

Contemporary Projects and Their Relationship to #OGB. Fediverse and #ActivityPub. Overview: The Fediverse is a decentralized network of federated platforms like Mastodon, powered by the ActivityPub protocol it is pushing user autonomy and grassroots control but has faced challenges around governance and moderation. Comparison: The #OGB complements the Fediverse by providing governance structures for federated projects, addressing the ongoing issues of moderation and decision-making. The #OGB’s trust networks align with the decentralized ethos of the Fediverse, offering a scalable solution for community self-governance. Key Takeaway: The #OGB enhances the governance layer missing in many Fediverse projects, fostering resilience and collaboration across federated networks.

NGO-Led Open Source Initiatives. Overview: Many open-source projects are managed by NGOs, which often prioritize stability and funding over grassroots participation. This has led to criticism of centralized decision-making and “corporate capture.” Comparison: The #OGB resists NGO-style top-down management, instead prioritizing the #4opens principles: open data, open source, open process, and open standards. Unlike NGO-driven projects, the #OGB is inherently community-first, ensuring power remains with the users and contributors. Key Takeaway: The #OGB rejects the NGO-centric model, emphasizing trust-based grassroots governance to avoid co-option by external actors.

Lessons from Historical Failures. CouchSurfing’s Decline. Overview: CouchSurfing transitioned from a grassroots volunteer-driven project to a for-profit company, alienating its core community and undermining trust. Comparison: The #OGB guards against such shifts by embedding trust and open governance at its core, ensuring the project remains community-owned and operated. Key Takeaway: Trust-based governance prevents mission drift and maintains alignment with the community’s original values.

P2P Projects and Overengineering. Overview: Many P2P initiatives have failed due to technical complexity and a lack of user-friendly interfaces, alienating non-technical users. Comparison: The #OGB adheres to the #KISS principle (Keep It Simple, Stupid), ensuring accessibility and ease of adoption without sacrificing functionality. Key Takeaway: Simplicity is essential for widespread adoption and long-term viability.

Key Differentiators of the #OGB Trust-Based Networks. Unlike purely consensus-driven or hierarchical models, the #OGB employs trust-based networks to enable efficient and inclusive decision-making at scale. The #4opens Framework. The #OGB is grounded in the #4opens principles, ensuring transparency, accountability, and openness across all aspects of the project. Focus on Digital Commons. The #OGB is designed to nurture digital commons, creating a space for grassroots innovation, collaboration, and governance that resists corporate capture. Composting the #TechShit, creating fertile ground for genuine social innovation.

Expected Outcomes. The #OGB aims to fill the governance gap left by historical and contemporary efforts, fostering a resilient, open, and trust-based framework for digital collaboration. By learning from the past and building on existing technologies, we seek to empower communities to reclaim the #openweb, bridging the gap between technology and grassroots activism.

The #OGB project faces significant challenges in implementing scalable trust-based governance systems. Key technical hurdles include:

Interoperability: Ensuring seamless integration with existing open protocols like #ActivityPub and the widening #openweb reboot. Usability: Creating user-friendly interfaces to make complex governance processes accessible to non-technical people. Resilience: Building systems resistant to malicious actors and spam within decentralized networks.

Are a few issues.

ecosystem

The #OGB project is rooted in a diverse ecosystem of grassroots organizations, decentralized communities, and open-source initiatives.

Ecosystem Description

Grassroots Communities: Activist groups, independent media collectives, and community-driven initiatives seeking alternatives to hierarchical decision-making.
FOSS Developers: Open-source software developers invested in decentralized tools, such as #ActivityPub, #Mastodon, and related protocols.
NGOs and Advocacy Groups: Organizations interested in participatory governance and transparency tools for improving their operations.
Tech Enthusiasts: People exploring ethical and sustainable technology beyond the centralized #dotcons paradigm.
Academic and Research Institutions: Scholars studying governance, social movements, and decentralized technologies.

Engagement Strategies

Collaborative Development: Open, participatory development processes underpinned by the #4opens philosophy (open data, source, process, and standards).
Workshops and Webinars: Educating target audiences about trust-based governance and the project’s tools.
Partnerships: Building alliances with aligned organizations, including community networks and FOSS projects.
Documentation and Guides: Creating accessible materials to help communities adopt #OGB principles and tools.
Pilot Projects: Collaborating with grassroots organizations to implement and refine governance systems, ensuring practical impact.

Promotion of Outcomes

Demonstration Projects: Showcasing successful case studies of #OGB governance in action.
Fediverse Integration: Leveraging federated platforms for dissemination and collaboration.
Open Events: Participating in conferences, hackathons, and public forums to share insights and foster adoption

Openweb Governance Body

WIP Repo of the codebase, and instructions for easy installation and setup.

All the planning text and activity is in the wiki and issues.

What is the #OGB

The #OGB codebase is a set of software tools which encode a governance model based on traditional grassroots activism combined with experience gained of using the fediverse as a technological tool for the horizontal scaling of social power. It focuses on sortition and messy consensus to achieve decision making and power distribution.

An Open Governance Body (#OGB) - for which the codebase is named - is a decentralized and democratic system for "governance" of any collective/community of (generally speaking) Producers¹ and Consumers². Throughout this text we use the fediverse as the example.

For the fediverse, three groups - Stakeholders³, Users⁴, and Affiliate Stakeholders⁵ - are used to provide a balance of perspectives and interests, with Stakeholders being chosen from and representing the people running instances, Users representing the people using the instances, and Affiliate Stakeholders representing other coders, organizations and groups supporting the fediverse.

How it works

The specific process used to achieve outcomes is determined by the wider community and remains mutable. The job of the codebase is to provide the #KISS tools and variables that facilitate this process. The workings of an open governance body is meant to be messy. There are few set laws or statutes, but instead a growing body of mythos and traditions that people can build and reference when making decisions. To ensure accountability and maintain trust within the community the model includes the power of recall, which is enacted at any time, for any members of the Voices⁶, Groups⁷ and Body⁸.

The “Tyranny of Structurelessness” helps design democratic and effective decision-making structures. By delegating specific authority to Groups for specific tasks, requiring accountability and transparency, distributing authority among people, rotating tasks, allocating tasks based on rational criteria, and providing equal access to resources and information, the group can ensure that power is not concentrated in the hands of a few individuals or agendas. [link to our tickbox wiki page]

The system incorporates a “Security Group” to detect bad actors, and “recall” process to demote individuals who do not align with the goals of the community. The structure is designed to be flexible, where variables and options may be redefined to suit the specific needs of the community.

The codebase includes Templates⁹ for many different views of [#4opens](link first use) governance, for example with options to aid/onboard new Roles¹⁰ by having an overlap with the old roll-holder where they share the role during a transition. The size of the #OGB Body can be reduced to human levels by using sortition to limit the number of participants in any pools within the Party¹¹. For example within the fediverse use case, 100 Stakeholders and 100 Users. This would be matched by a smaller number of Affiliates, providing a balance of perspectives and interests. maybe link this as its complex

It should be noted that the idea of sortition and open governance is not new. It is a way of organising that has been used in ancient Greek city-states, modern courts and jury's and more recently by #XR to address the climate crises. It's implementation in our roll out example within the #Fediverse is a new and exciting way of building decentralized and democratic governance.

Consensus

This refers to a level of agreement or acceptance reached by a Group or community on a proposal or action. In our case it is not a specific process or method, but rather a general principle that guides decision-making within the Group. link

The #OGB has several mechanisms in place to mitigate the risks of capture by special interests or bad actors. By allowing all Members of the Body to participate in the formation of Groups and the formation of Agreements¹², the system is designed to reduce the power of "capture" by any one group or individual.

The Body, Voices and Groups

Groups are formed around issues that receive a level of support from Members¹³ of the Body. Agreements are reached through discussions and consensus-building within a Group.

Additionally, allowing Members who were not selected by the sortition to still submit proposals for Group decisions directly ensures the input and perspectives of all Members are considered.

Voices, which are a subset of Members, have the power to both initiate Groups and enact Agreements reached by Groups.

The number of Voices is dynamic and would depend on the size of the Pool(s)¹⁴, but a small number, such as 3-5, would be ideal to ensure that the system is nimble and responsive to the needs of the community.

The Affiliate Stakeholders would bring additional expertise and perspectives to the table and their membership application would have to be ratified by the Body to ensure that they align with the goals of the community.

Community and the tradition of recall and dilution

The Voices are representatives of the Body, but ultimately it is the Body who holds the power and makes the decisions. It is meant to be messy and not a traditional power structure, a “native” approach working within the decentralized and disorganized nature of the #openweb commons..

The Groups and Voices have the power to make decisions, but they need to work together to build consensus to make effective decisions. The model acknowledges the challenges of working in disorganized groups of individuals and the importance of building a body of mythos and traditions to guide decision-making over longer terms (even multi-generational).

The recall and dilution mechanisms provide a way for the community to self-regulate and course-correct when necessary. Voices have limited terms and are replaced by members the Body, so their power is not permanent.

Messiness

The proposed system embraces the messiness of real-world governance and is designed to work within it, rather than trying to impose specific ideas of order. It is built on the principle that power should be distributed horizontally and that decisions should be made through community wide consensus-building.

Issues

• Prioritization: The proposal system allows for prioritization by allowing the governing body to decide which proposals to take action on and which to ignore.

• Spam: The use of standard moderation tools and community flagging systems would help to address the issue of spam. add-link

• Centralization: The #OGB takes into account the potential for centralization and addresses it by encouraging participation and giving power to those who actively contribute to the community.

Fediverse use case

Our first focus while developing the #OGB is on the fediverse, where the OGB itself will be a citizen, though the principle and structure can and should be applied to any "producer" communities both on- and offline.

The governance body's for the fediverse will be "native", building on the same technology - effectively themselves instances within the fediverse - streaming data/comments in from other instances, with all activity, process, decisions and publications being posts back out into the fediverse.

Proposals come from anyone with an ActivityPub account, giving all interested users the opportunity to responsibly shape the direction of the fediverse. The consensus of Voices, minus one, is what turns a Agreement into "the voice of the instance", ensuring that the agreements reached by the Body are truly representative of the wider interests and agenda.

Based on the statistics of a population of over ten million accounts and more than nine thousand instances, it would be difficult for a Body of that size to make decisions efficiently. A smaller representative Body can be more focussed and better able to make decisions quickly and effectively. this is built into the codebase by both horizontally federating new instances or restricting the size of the body it self, both are good approaches.

The goal is to mediate the shifting of power from the .01% to the 99.9% of the fediverse. This codebase and approach is designed to scale horizontally for use in other grassroots "producer" democratic structures both online and offline, such as local street markets, a protest camp, eco villages.

There can (and should) be multiple #OGB's within the fediverse, that may grow, shrink and divide/merge organically over time. We are describing one example to provide a seed from which to grow. The output from one OGB federates to feed into another and back. This will be fully implemented as the design and codebase is refined after initial roll out.

Process

The model allows for any User to submit a Proposal, with subject tags which will be visible on the activity streams of the governing body. The Body can then decide to take action on the Proposal by passing it to an existing Group or forming a new one to work on it. Prioritization of proposals will be handled by the Body and the Groups, with spam being dealt with by flagging and standard moderation tools.

Additionally, the use of sortition and flagging mechanisms can help to ensure that the voices of the community are heard and that bad actors are held accountable. The use of sortition to select Voices, and the ability for other Body members to flag bad Voices, provides a way to detect and address any individuals or groups that may be acting against the best interests of the fediverse.

Basic security checks to detect sock puppets and spammers, and the ability to “recall” flagged accounts, helps to ensure that the governance body is representative. If people start to game the system, the solution is to get more people involved, which will dilute the problem. Sortition will shift bad groups out when fresh people of goodwill join.

to sum up, the system relies on a combination of automatic checks and human moderation to ensure accountability, while also recognizing the limitations of #tredtional formal non "native" processes and the importance of trust based collaboration. The emphasis is on keeping the system simple #KISS, flexible and adaptable to the needs and culture of the instance community. The use of human flagging is a core way to address potential abuse of the system, helping to ensure that larger and more influential instances do not dominate the decision-making process.

Why build a native approach?

The challenges of using formal processes - such as those used by #NGO's and cooperatives in #openweb and activism projects - are that they are rigid and not suited to the decentralized and dynamic nature of these communities, particularly the fediverse and activism. LINK

Existing projects and resources that may be relevant to governance such as Loomio, Decidim, and Sociocracy tend to be based on formal consensus, which as mentioned above, is a very bad fit for messy, unstructured groups.

The #OGB project is meant to reflect the practical, on-the-ground reality of horizontal activism and the #openweb fediverse culture. It is not based on idealistic or theoretical models, but on the lived experience of the community.

Make reality

It should be noted implementation will be complex, while the resulting tools should themselves be simple.

The development of the project will involve a production/coding team, funding, and testing with a real user base.

We want to see if there are individuals within the fediverse who have the skills and interest in helping to build the tools and processes needed for the project, and if so, to explore potential collaborations and partnerships.

We also want to raise awareness and focues on understanding of the project, the issues it addresses, and to gather feedback and input from a diverse group of people.

Summary

The proposed governance model is designed to be messy and non-hierarchical. It is meant to work with the fediverse's decentralized structure, and it is built on a long history of grassroots activism. It is not a traditional power structure, and it relies on consensus and recall processes rather than laws or statutes.

It's important to keep in mind that this system is built on trust and collaboration, and relies on the Stakeholders being engaged and willing to work together toward common goals.

The goal is to work with, not against, this history and avoid the pitfalls of “process geeks” coming in and damaging the movement, which is the normal outcome. We need to recognize that the need for control is often a barrier to finding solutions, and instead focus on building structures and tools that allow us to navigate the mess and make good decisions collectively. This can be achieved by building bridges and fostering communication between different perspectives, rather than trying to control the outcome. The key is to find a balance between different approaches and allow for diversity of tactics.

Definitions

The choice of terminology is non-trivial. Here are our working definitions of what we mean by certain key terms. These will change based on response and feedback from the living community. All of them will also likely be variables within the code, such that they may better reflect their function in a given use case "template".

---

1. A common pool within the Party. A Producer is meant to signify people who provide/do something. This could be a market stall community, teachers in a classroomor our working example, the fediverse instance admins/mods. ↩︎

2. A common pool within the Party. The people who support and use the products of the Producers. ↩︎

3. Synonym for Producer. Specific to the fediverse use case. A subset of the Party who are instance maintainers, admins and moderators. ↩︎

4. Synonym for Consumer. Specific to the fediverse use case. A subset of the Party who are the users of an instance. ↩︎

5. An example of something other than Producer or Consumer but who is still a fundamental part of the OGB's community. Specific to the fediverse use case. People who "work" to build the infrastructure of the instance subject path, such as programmers, organisations and groups supporting the fediverse. ↩︎

6. A subset of the body chosen by sortition, who accepts responsibility for getting stuff done. This is a very active role. They have a power to veto decisions made by the body, but by tradition should not use it with out good reason and strong trust/consensus building. ↩︎

7. A place to work though problems and come up with solution paths for the Body/community to make decisions about the path to recommend. These are different in that Groups are self-selecting and not filled via sortition; the checks and balances being provided by the sortaion of the Body and Voices. ↩︎

8. The governance body, picked by sortition form the pools of people who are interested and active. In the fediverse use case the pools would be Stakeholders, Affiliates and Users. ↩︎

9. A way of defining a work process; boiler plate text and names for the underlying codebase to display and use. To start with we will be focussing on 3 templates - spiky, which we know works, fluffy which will need more testing, and a balanced approach which should work fine. The template system can be used to define most democratic organising processes, once we have the code working well. There are also Body-wide decisions, which will likely be rare and or trivial, and the Party can add proposals but these would be advice only. ↩︎

10. A nebulous but needed term we are yet to define clearly, a "mini voice" within a Group. Likely not in v1 of the codebase. link ↩︎

11. Sum of the pools of Producer, Consumer and any other that may be specific to a given use case, defined by its template. Someone who walks the path, but does not yet help to produce/reproduce it. In the fediverse use case, this is everyone with an ActPub account who signs up to the OGB instance. ↩︎

12. These come from any part of the Body that have use of the voting/consensus tools to agree to a text that they have worked on together. Then implementation can be pushed by voices, groups and the body it self. ↩︎

13. An individual within the Body chosen by sortition from the pool(s) within the Party, to represent and deliberate the path. The Party were divided into subsets (pools), but here that distinction disappears and they are all just Members. ↩︎

14. A subset of individuals within the Party. The template in use by a given OGB will define these as necessary. ↩︎