Regovernance is the practice of continuously re-shaping the rules of a shared platform so that power and money keep flowing *back* to the commons instead of being slowly captured by a central operator. Where Deshitification focuses on rebuilding infrastructure as a commons, regovernance focuses on how that commons evolves over time, with explicit mechanisms for: - Mutual ownership of the platform. - Pooling costs by ability to pay. - Incentivising reductions in platform costs over time. - Collective control over which features are built, via Spec Driven Development. In the context of a shared Bookshop Coop Store and Book Stock Export Aggregation, regovernance is how independent bookshops keep the platform working *for* them, not the other way around.
# Mutual Ownership Of The Commons Regovernance starts from the assumption that the platform is a piece of Commons Infrastructure. - Ownership is shared between member bookshops, readers’ groups and allied institutions. - Governance is formalised through a cooperative or similar structure, with clear membership rules. - The default question is not “how can we grow platform revenue” but “how can we keep the service healthy at minimum sustainable cost”. Mutual ownership is important because it makes regovernance possible. - If the platform is owned by an external company, rules and fees ultimately flow from its balance sheet. - If the platform is owned by its users, they can adjust rules, fees and priorities by voting, not by pleading.
# Pooling Costs By Ability To Pay A practical regovernance scheme recognises that not all participants have the same capacity to fund development. - Larger bookshops or regional alliances can contribute more money or staff time. - Small or precarious shops can contribute less, or contribute in kind (testing, documentation, hosting events). Cost pooling can be expressed through a simple contribution framework. - A base membership fee to cover minimal hosting and coordination. - A progressive contribution layer where richer members voluntarily or formally pay more to fund shared features. - Non-monetary contributions (code, design, translations) being recognised and recorded for legitimacy, even if not directly priced. The key idea is that no single actor should have to carry the whole platform, but no actor should be blocked from participating because they are small.
# Incentives To Reduce Platform Costs Over Time Unlike a growth-driven startup, a regoverned commons has an explicit aim to make itself cheaper and simpler as it matures. - Technical simplification is rewarded. Replacing three brittle services with one boring, reliable script is celebrated. - Automation is encouraged when it reduces recurring cost without creating new vendor lock-in, for example using Agentic Development to maintain adapters and documentation. - Cost transparency is routine. Yearly or quarterly reports show what hosting, development and support actually cost, and which parts are shrinking. Incentives can be built into the governance rules. - A share of surplus is earmarked for debt reduction and cost-reducing refactors rather than new shiny features. - Working groups can propose “cost-kill” projects that deliberately reduce the platform’s own footprint, and receive priority in the roadmap. Regovernance treats “platform diet” as a virtue, not a sign of weakness.
# The Governance Slider A central metaphor for regovernance is a shared “slider” that participants can adjust over time. Imagine a visible control with two ends. - One end labelled “Lower platform costs, fewer features”. - The other end labelled “More features, higher shared costs”. Community members and bookshops periodically vote to move the slider. - Moving towards “lower costs” shifts priorities to maintenance, simplification and cost-reduction, and may freeze new feature work for a cycle. - Moving towards “more features” authorises higher pooled funding or extra in-kind contributions for a defined period, in exchange for building a particular cluster of capabilities. The slider is not a literal UI control, but a simple way to structure decisions. - Each decision cycle (for example once or twice a year) includes a clear question about where to position the slider. - Budgets, staffing and expectations for the next cycle are derived from that agreed position. - Minority views are recorded, so that if the slider is pushed too far one way for too long, there is a clear history of dissent. This keeps the platform’s size and ambition under continuous, explicit control rather than drifting upwards until it quietly enshittifies.
# Spec Driven Development In a regoverned commons, new features are proposed and agreed through Spec Driven Development. - Anyone can propose a feature by writing a short, understandable spec that describes the user story, data model and any protocol changes. - Specs are discussed and amended in the open, and linked from wiki pages so shops and developers can review them asynchronously. - Once a spec is ratified, implementation can be shared between humans and agents, with clear success criteria. The governance slider and spec process are tightly linked. - A cycle that has chosen “lower platform costs” might restrict the number or size of specs that can be approved. - A cycle that has chosen “more features” might run a structured call for specs and allocate more pooled funding to implementation. Spec driven development is how regovernance turns “we want X” into concrete, tractable work without losing sight of cost and complexity.
# Regovernance For The Bookshop Coop Store Applied to the Bookshop Coop Store and Book Stock Export Aggregation, regovernance could look like this. - The cooperative defines a baseline service. Shared catalogue, basic search, direct shop routing and minimal hosting. - Each year, member shops vote on the slider position and on a small bundle of specs, such as new delivery options, better reporting or integration with national platforms. - Contributions are adjusted by ability to pay, with transparent accounting and optional solidarity funds to support low-income members. If the platform starts to feel heavy or too expensive. - The slider can be moved towards “lower costs”. - Cost-kill specs are prioritised, such as consolidating services, simplifying schemas or pruning underused features. - The default assumption is that a simpler platform is safer and easier for everyone to maintain. If a new opportunity appears. - The slider can be nudged towards “more features”. - A focused spec set is adopted to explore the opportunity without exploding complexity. - After one or two cycles the community can decide whether to keep, refine or remove those features. Regovernance lets the platform breathe with its community instead of drifting into a permanent growth stance.
# Relationship To Other Concepts Regovernance sits alongside several related ideas. - Deshitification describes the move from centralised, rent-seeking platforms to commons infrastructure. - Commons Infrastructure names the shared technical and legal scaffolding that underpins the coop store. - Agentic Development and Vibe Coding explain how small groups can build and maintain such infrastructure with the help of AI agents. - Bookshop Coop Store and Book Stock Export Aggregation provide the concrete domain where regovernance is tested against real-world constraints. Together, these ideas sketch a path where small, independent bookshops can collectively own and steer their shared digital tools, rather than being slowly reshaped by distant platforms whose incentives they cannot control.