The Hackerspace Game

This is the zine I wish someone had handed me on day one. It's about the patterns that show up in every maker space, why those patterns exist, and what you can do about them. None of this is theoretical. All of it is from the wreckage and the wins.

If you run a hackerspace, are about to start one, or just spend a lot of time in one, this is for you.

On paper, a hackerspace is a community-operated workspace. People share tools, knowledge, and projects. It's soldering irons and sewing machines. 3D printers and laser cutters. Code, art, hardware, noise.

But that misses the actual thing. A hackerspace is a social experiment in self-governance. Most of them run on norms instead of rules. Trust instead of hierarchy. Culture instead of coercion.

That's the part that's hard to explain to anyone who hasn't lived in one.

I love that quote because it's so honest. Every hackerspace founder eventually learns the same lesson. Common sense is not common, consensus is slow, and "be excellent to each other" is a vibe, not a procedure.

Every hackerspace develops its own culture, but certain member types appear again and again. Once you can see them, you can predict how your community will evolve.

A healthy mix has Builders shipping projects, Talkers spreading ideas, Lurkers providing financial stability through dues, Founders preserving memory, and Newbies asking the questions that keep the place from getting weird.

The trap is in the sixth one. One Drama can warp the culture of the entire space. Not "make it slightly worse." Warp it. People leave because of one person, and the community gets quietly poorer by the month. We'll come back to this.

The dominant governance pattern in hackerspaces is something called do-ocracy. The rule is simple.

If you do the work, you choose how the work is done. You don't ask permission to fix the broken table saw. You fix it. You don't run a vote on whether the lounge needs a couch. You drag one in.

This is great when it works. It rewards initiative, it routes around bureaucracy, and it lets a small group of motivated people get a lot done. The Hackerspace Blueprint puts it well: "The people doing stuff have authority over that project, though non-coercive, and they lose power when they stop doing."

But do-ocracy has sharp edges. Three of them, specifically.

People who don't do the work blocking those who do. Someone shows up to a meeting with strong opinions about how the new electronics bench should be organized, having never set foot in it. They want a vote. They want a committee. They want a written policy. The actual builders sigh and slow down.

Do-ocracy says: you don't get a veto unless you're doing the work. The hard part is enforcing that without becoming a jerk about it.

This one is the silent killer.

The fun tasks get claimed instantly. Building a new tool. Running a workshop. Posting the demo video. Everyone wants in.

The boring tasks pile up under the waterline. Taking out the trash. Replying to membership emails. Reconciling the bank account. Updating the wiki. Sweeping the wood shop. Filing the insurance paperwork. Sorting the donation pile.

The people doing invisible work burn out first. Every time. And because the work is invisible, nobody notices they were doing it until they leave and everything quietly breaks.

"Oops, I threw out that pile of parts." "Oops, I painted the lounge purple." "Oops, I donated the lathe."

Do-ocracy works until a decision can't be undone. The minute you're in that territory, you need something more than a fast individual. You need a pause, a conversation, and ideally a written norm about what kinds of things require pre-approval.

A good heuristic: if undoing it would cost more than a week of someone's time, talk to the group first.

Underneath all the governance theory, hackerspaces run on trust. Trust that borrowed tools come back. Trust that commitments will be kept. Trust that shared space is respected. Trust that the person across the bench from you isn't a creep.

Trust is the actual currency. It just doesn't show up in the accounting.

Two patterns show up over and over.

The betrayal cascade. When trust gets violated publicly, observers don't just update their beliefs about the offender. They update their beliefs about everyone. If Bob walks off with the donated tools and nobody does anything, the message isn't "Bob is bad." The message is "this is the kind of place where people walk off with the donated tools." New members assume the worst by default, and the cycle accelerates.

The newcomer barrier. Established members trust each other from years of shared work. New members start at zero. Without deliberate onboarding, newcomers feel like they're trying to break into a clique. A lot of them just leave instead. The space gets older and more insular every year, and nobody can quite explain why nobody new is sticking around.

The fix for both is the same: be deliberate about trust. Build it explicitly with new members. Defend it visibly when it gets violated. Don't assume it scales on its own.

There are two kinds of conflict in a community, and you need to be able to tell them apart.

Essential conflict is real disagreement about values, priorities, or limited resources. Should we spend the budget on a CNC router or a better ventilation system? Should we allow paid workshops? Should the space be open 24/7 or have quiet hours? These conflicts are healthy. They're how the community figures out what it actually wants to be.

Inessential conflict is drama. Personality clashes. Grudges that started over something nobody can remember. People who need to be the loudest voice in every thread. Drama burns energy without resolving anything.

Rules can help navigate essential conflict. Rules cannot protect you from drama. Drama comes from people, and the only fix is addressing the people.

Which brings us to the part nobody likes talking about.

The term "missing stair" comes from a metaphor that's traveled a long way through community spaces. The idea is this: imagine a staircase with one stair missing. Regular users learn to skip it. They don't talk about it. They just step over.

New people, who don't know the stair is missing, fall through.

Every community I've seen has at least one. The member everyone quietly warns the newcomers about. "Don't leave tools near Rom." "Don't be alone with Quark after midnight." "If Dukat shows up to the meeting, just don't bring up the funding proposal." The workarounds become so normalized that long-time members stop seeing them as workarounds.

The problem is that the workarounds don't transfer. New members don't get the briefing. They get hurt, or harassed, or pushed out, and they leave, and the community never figures out why retention is so bad.

Healthy communities fix the stair. They don't fix the people who happen to walk near it.

That sometimes means having a hard conversation. Sometimes it means revoking access. Sometimes it means a formal warning, a public note in the meeting minutes, and a clear timeline. It's never fun. But the alternative is losing the good members one at a time, forever, in exchange for keeping one bad one.

Hackerspaces experiment with a lot of different governance structures. There's no one right answer, but there are real tradeoffs.

Consensus is maximally inclusive and devastatingly slow. Everyone has to agree, or at least not block. One determined blocker can stall a decision for weeks. Great for culture questions. Terrible for buying a CNC router before the discount expires.

A board is efficient and stable. Elected representatives make decisions on a defined cadence. The risk is drift. Boards can slowly become more interested in the institution than the community. If the board starts feeling like "them" instead of "us," something has gone wrong.

Do-ocracy is fast and flexible. Already covered above. Has sharp edges.

BDFL, benevolent dictator for life, works great until it doesn't. Everything depends on one person, and the day that person leaves, gets sick, or just gets tired, the whole thing falls over. Founders especially love this model and it almost never ends well.

In practice, the spaces that last use hybrids. A board for the big stuff (money, leases, legal). Do-ocracy for daily operations. Consensus for culture and major direction changes. The specific combination matters less than the fact that you've thought about which decisions go where.

Whatever model you pick, remember: governance shapes behavior, but culture matters more. A healthy culture survives a bad bylaws document. A toxic culture survives a perfect one.

Hackerspaces follow a predictable lifecycle. If you've been in the scene long enough, you've watched it play out at least once.

Phase 1 is the founding. High energy, high trust, low structure. The founders know each other. Decisions happen over beers. Everyone is doing everything.

Phase 2 is growth. More members show up. The unwritten rules stop scaling because the new people don't know them. The original group is still doing most of the work.

Phase 3 is stress. Conflicts start appearing. The invisible labor is unsustainable. The founders are tired. The newer members feel like they're not really part of "the group."

Phase 4 is burn. Key people leave, often suddenly and with hard feelings. The institutional knowledge leaves with them. The wiki was never up to date because nobody had time. Tools break and nobody knows who to call. The space stops feeling alive.

The burnout spiral runs underneath all of this. A small group does most of the work. They feel obligated to keep doing it. Resentment builds. They leave suddenly. The community is shocked because nobody saw it coming, but it was always coming.

The prevention is mechanical, not emotional:

• Distribute knowledge. No single points of failure. If only one person knows the door code system, fix that this week.
• Rotate roles. Positions are not identities. Treasurer for two years, then someone else.
• Make stepping back okay. Succession is healthy, not betrayal.
• Appreciate invisible labor publicly. Name it in the meeting. Put it in the newsletter. People who feel seen don't burn out as fast.

Burnout, not money, kills most hackerspaces. The successful ones are the ones that figured this out before they had to.

1. Culture beats structure. A healthy culture with minimal rules beats elaborate bylaws with toxic people. Spend more time on culture.

2. Do-ocracy needs guardrails. It works for small groups. As you grow, you need explicit mechanisms for the irreversible decisions. Write them down before you need them.

3. Trust is the real currency. Tools, space, money, governance, all of it depends on members trusting each other. Defend trust like you'd defend your bank account.

4. Fix the missing stairs. Communities that tolerate bad actors lose good members one at a time. Rules without enforcement are theater.

5. Plan for succession. The biggest risk to your space isn't money. It's losing one key volunteer. Distribute knowledge now, while everything is fine.

Hackaday put it about as plainly as anyone has: in the end, running a hackerspace is an HR problem. Keep good people active and happy. Warn, and then prune, disruptive individuals. The rest is just paperwork.

A community is not a product. It's a practice.

Keep showing up. Keep building trust. Keep fixing stairs. The work is never done, but the place is worth it.

If you're running a space and any of this resonated, the move is to pick one thing from the five above and act on it this week. Not a meeting about it. Not a committee. Just do the thing. The community you want is downstream of the small repairs you make right now.

I'd love to see what you build. Drop your space's stories, your bylaw experiments, your burnout-prevention rituals. The more of these we share with each other, the less each new generation of organizers has to rediscover from scratch.

Made by Moheeb Zara at hack.build and HeatSync Labs. Inspired by Nicky Case's The Evolution of Trust. This post started as a printed zine, also available here.

Copy it. Share it. Remix it.