Who does your code actually empower? (#FOSS reality check for #openweb builders). In web application development there are broadly three groups you can empower. Every architectural decision – whether you acknowledge it or not – shifts power toward one of these groups.

Understanding which group your system empowers is probably the single most important design question in social technology. In the “fluffy thinking” the three power centres:

1) Users, people who consume, participate, and live inside the system. They care about usability, safety, autonomy, continuity and real-world outcomes. Users are rarely technical, but they are the reason the system exists. If users lack agency, your project is a toy or a control mechanism – not infrastructure.

2) Producers are people who create content, knowledge and value. Examples: writers, organisers, artists, moderators and community builders. These are the people who make platforms meaningful. Without empowered producers networks stagnate, communities collapse and content becomes algorithmic sludge.

3) Geeks (developers/admins). The builders, maintainers, infrastructure operators who care about architecture, performance, elegance, security and scalability. This group is essential – but historically, especially in #FOSS and federated spaces, it becomes the dominant power holder.

This is the #geekproblem. Most #openweb projects “accidentally” empower the third group above all others. Why? Because developers build tools primarily for themselves, #UX is treated as secondary, social dynamics are assumed to be solvable through technical controls and complexity becomes a gatekeeping mechanism.

The result is systems that might be technically impressive, but socially brittle, unusable by normal humans. The tiny group of unthinking “elitists” end up deciding what is good for everyone else, not because they are evil – but because the system structurally centres their perspective. Good #UX in social technology is extremely hard precisely because it requires humility about what engineers don’t know.

The #dotcons model works much “better”, as corporate platforms take a different path. They empower capital which then hires geeks to serve producers, extract from users and optimise engagement and surveillance.

Power structure is: Capital → Developers → Producers → Users. The users become the product, producers become dependent and developers become instruments of extraction. It’s an efficient machine – and a socially destructive one.

The missing model is basic democracy of user empowerment, an uncomfortable truth in practically all the current mess is that users are rarely genuinely empowered. Some partial attempts that worked in the past are early #Indymedia (open publishing + collective moderation. Wikipedia (community governance + editable commons), email protocols (user portability, decentralised identity) and RSS/blogosphere era (subscription over algorithm). None are perfect – but they shift power closer to participants.

What we need more of is non-extractive incentives, as good #openweb projects try to do, real grassroots projects empower users AND producers together. Not by removing structure, but by #4opens distributing power through federation, open standards, collective moderation and visible process.

These are still rare because they are harder to build. They require solving social problems, not just technical ones. It’s why we keep repeating the same failure, oscillate between two broken patterns of #geekproblem systems → technically elegant, socially inaccessible and #dotcons systems → socially addictive, structurally extractive. The problem we now need to compost is that both have produced piles of stinking manure across the tech landscape of the last 20 years.

The #OMN approach is not perfection, it is #KISS shifting the default power alignment to infrastructure that empowers users to participate without needing technical expertise. Producers retain agency over their work and context and most importantly developers build frameworks that decentralise their own authority over time.

In short, build systems where developers are gardeners, not rulers. Questions for #FOSS developers are, before writing code, ask:

• Who can say “no” inside this system? Who owns the data?
• Who can leave without losing their social graph?
• Who defines moderation rules? Who can fork socially, not just technically?
• Questions like these help reveal where power really sits.

You have a shovel, we really don’t need more abstract debate. We need people willing to compost the failures and build differently. That means accepting messiness, designing for humans, not idealised users, building structures where power flows outward rather than upward. That’s the path #OMN is trying to walk.