We have more than enough code, what we need is technology that helps people build power together. If you work in free software, #FOSS, decentralized networks or the #Fediverse, you probably already understand some of the problems with corporate #dotcons platforms. You may be building alternatives because you want technology to be more open, more democratic and less controlled by a handful of corporations.
That is a good place to start, but there is a recurring problem in grassroots technology – we keep trying to solve social and political problems by building more technology. A new protocol, another platform, a different database or a cleverer technical architecture is offered as the answer. Yet the same old problems keep returning, concentrated power, passive users, gate keeping, status games and communities that struggle to organize themselves.
This repeated outcome is what we call the #geekproblem, the habit of treating human problems as if they were primarily technical ones. The way past this is not a blinded luddite reaction to abandon technology, it is to connect our technical skills to the social realities they are supposed to serve, that is where the #4opens as social technological path comes in.
Open source, #FOSS is by it self necessary, but it is not enough. Open-source code matters, open protocols matter, without them, communities have little chance of building infrastructure they can inspect, adapt and maintain themselves. But open code does not automatically produce an open community. A project can publish its source code while keeping its data inaccessible. It can implement an open protocol while making participation difficult. It can claim to be decentralized while leaving all the meaningful decisions in the hands of a few developers or administrators.
Think about a project that runs on an open-source codebase. Can its users access and move their data? Can other projects connect to it using shared standards? Can the community understand how decisions are made, challenge them and take part in shaping the project’s direction? If the answer is no, then the project may be open in a narrow technical sense while remaining closed in practice.
This is why we use the #4opens as a practical framework:
- Open Data: The data can be accessed, reused and shared under clear, appropriate terms.
- Open Source: The code can be inspected, modified and redistributed.
- Open Standards: Interfaces and formats make it possible for different systems to communicate and interoperate.
- Open Process: The decisions, governance and working practices are visible enough for people to participate and hold power accountable.
These four openings work together, none is a substitute for the others. The path we hope to take from this is rebalance people-to-people before the normal peer-to-peer were decentralization is presented as a technical property. Build a peer-to-peer network, distribute the data, remove the central server and the problem is solved. But a network can be technically decentralized and socially dysfunctional when peers still fight, exclude people, hoard influence and reproduce the same hierarchies found on corporate platforms.
This is also where we encounter the #encryptionist tendency, the belief that cryptography and protocol design can replace the need for human trust and collective responsibility. Encryption is essential where privacy and security require it. It protects people from surveillance and helps keep private communication private. But it cannot decide how a community should resolve a disagreement, distribute responsibility or hold an administrator accountable. Nor can it establish that every person using a system is acting in good faith.
#P2P needs to mean people-to-people before peer-to-peer. The point of decentralized technology should be to strengthen relationships between people and communities, not to pretend those relationships can be engineered away. For developers, this changes the questions we ask. Instead of only asking how to eliminate a central server, we also ask how communities can share infrastructure, moderate their spaces, move between services and maintain control over their collective work.
The technical architecture matters, so does the social architecture. We need to stop rebuilding the same problems Grassroots technology has a familiar cycle. A project emerges with a strong vision, builds useful tools and attracts a community. Over time, technical complexity grows, a small group accumulates influence, participation narrows and the original purpose becomes harder to recognize.
Eventually, people leave or start building something new. The next project promises to solve the previous project’s problems, but often carries the same habits into a fresh codebase. We call this #techchurn, the problem is not that developers experiment or that software needs replacing. It is that we repeatedly invest energy in new technical systems without doing the harder work of changing the social patterns around them.
We reproduce #stupidindividualism: everyone wants autonomy, but few people want the shared responsibilities that make autonomy possible. We fall into blocking and exclusion instead of building workable ways to handle conflict. We mistake technical authority for community legitimacy. And when governance is left informal, power does not disappear. It becomes harder to see.
Someone still decides what gets merged, which features matter, who receives access, which conflicts count and whose complaints are ignored. If these decisions cannot be understood or challenged, an ostensibly open project can become a small technical fiefdom. Open Process means treating governance as part of the infrastructure, not an awkward extra to discuss after the code is written.
That does not mean every code review needs a committee or every decision requires a vote. It means being clear about who decides what, how decisions can be challenged and how responsibility can be shared or handed over. Good technical work should make those relationships more accountable, not hide them behind complexity.
Build infrastructure for the commons – the #4opens are not another badge to put on a project website. They are a way to ask whether our technology helps communities build and maintain shared resources. A commons is more than something that is free to download. It involves people who use, contribute to and take responsibility for a shared resource, with practices that help keep it useful and prevent it from being captured by a narrow interest.
This matters for grassroots media, community archives, local networks and the wider #Fediverse. These projects need more than software that runs. They need ways to preserve collective memory, share information across communities, moderate public spaces and maintain infrastructure beyond the lifetime or interests of any single developer.
For the Open Media Network (#OMN), this means thinking about media as shared objects moving through trusted community flows, rather than treating every platform as a separate walled garden. It means connecting projects through open standards and bridges, while leaving communities room to make their own decisions. The goal is not to build one giant system that controls everyone. It is to help local projects work together without surrendering their autonomy.
That is a different technical challenge, that asks us to build for interoperability, repair, reuse and community control rather than endless engagement, growth and platform replacement. To find this path we need to look for the gaps, perhaps the code is open but the data is trapped, perhaps the protocol is open but the project has no workable way for its community to influence development. Perhaps the governance looks good on paper but all the practical knowledge sits with one exhausted administrator.
These are not reasons to dismiss a project, they are places to start improving it. You can help document systems so others can maintain them. You can make data easier to move. You can build bridges between existing projects instead of another isolated platform. You can help communities share moderation and maintenance. You can make governance visible without turning every small task into a bureaucratic exercise.
Above all, you can work with the people who will actually use and maintain the tools to move from technical skill to collective power. The wider problem is political. Corporate platforms concentrate power because their business models reward extraction, dependency and control. Replacing their code without challenging those relationships will not get us very far.
We need to stop treating every failure as an invitation to start another platform. We need to connect our technical work to existing grassroots communities, shared resources and the practical struggle to build alternatives. The #4opens offer a simple starting point. They help us ask not only whether technology works, but who it works for, who controls it and whether people can collectively change it.
For technologists, this is an invitation to bring your skills into a bigger conversation. You do not have to become a political theorist, abandon your craft or agree on every detail. You do need to recognize that technical decisions shape social power, whether or not we choose to discuss that openly. The challenge is not simply to write more open code, it is to build open, usable and accountable infrastructure that people can make their own.
Build tools people can understand, share what they need to maintain them. Connect projects rather than trapping them. Make decisions visible. Help communities develop the confidence and capacity to govern their own infrastructure. That is how we move beyond the #geekproblem and begin to compost #techchurn into something more useful.
Open the code. Open the data. Open the standards. Open the process. Put people first. That is the #4opens. That is a practical starting point for rebuilding the #openweb as a grassroots Commons.
