• 10 Dec, 2025 *

"I’m really really angry. And I’ll not say more, I don’t want to right now, I’ll regret it later."

That’s from a GitHub issue about naming.

Not code architecture. Not licensing. Just what to call the project.

The story could be an opera. Hackpad was sunsetting after its acquisition, and HackMD emerged as an open source alternative. The HackMD core team commercialized a fork of their own project, labelling the open version HackMD CE. After a while, the community took over the open version. It was going a different direction so they renamed it CodiMD to avoid confusion, and eventually forked to a new repo outside of the HackMD Github account. You could feel the tension through issue comments and half-written PR descriptions—small technical notes carrying the weight of a breakup. Meanwhile, the HackMD team kept maintaining their open version, but also decided to call keep the CodiMD name. Fights also broke out over who represented the "real" project, which forks to take seriously, who could relicense. By the time the community maintainers finally fled to the fourth name, HedgeDoc, you could see everyone was exhausted.

Repos fork easily, by design.

But our social layers around them can’t handle it.

Blowups are more and more the norm. Open/LibreOffice, Ethereum Classic, XEmacs, Core/Libre/Canoeboot. Or the long, smoldering feuds: Wikipedia edit wars, Bitcoin Core maintainer beefs. Even Grandmaster Linus Torvalds loses energy to it. He invented Git and decentralised code repos, so if even he’s caught up in this, it’s everywhere.

What would healthy forks need?

I keep coming back to three characteristcs:

1. Non-exclusive: people can participate in multiple branches
2. Self-resourcing: avoiding existential threats
3. Continuous: divergence happens in small increments, as normal evolution

If you have these three at the same time, the whole orientation shifts. You stop thinking about "how do we fix this organization," and start thinking "how does everyone find the what they need right now."

The pattern isn’t just in open-source.

In a builder program I joined, the weekly Zoom calls always began the same way: a grid of faces, the host cheerfully setting the agenda, and after an hour-long webcast, it was time for the Q&A before the breakout rooms.

A few California startup founders took the mic, confidently dropping buzzword and polished jokes. The "I’m here to crush it, bro" types. They were hunting for technical co-founders, and Silicon Valley taught them that dominating meetings gave them visibility. So they brought that culture with them.

You could watch the introverted developers recoil in real time. Shoulders tensed. People muted themselves and started working on something else. Nobody said, "this isn’t working," but each week, I noticed a couple more faces were missing.

Finding a tech founder wasn’t a bad thing. Some of the devs wanted to be found.

The problem was structural.

The environment wasn’t built for the diverse needs it attracted.

One day someone suggested, "maybe we can choose our own breakout groups?" But the organizers resisted. They were proud of their matchmaking. They didn’t know their matches correlated with the highest dropout rates. They couldn’t feel the friction because they weren’t in it.

The deeper issue was nobody could modify the space to meet their needs.

After enough gentle lobbying, the organizers enabled free-choice breakout rooms. A tiny experiment. For the first minute, it was madness. You could see everyone popping in and out of rooms like they were testing doorways. You could see games of cat-and-mouse, or people jumping back-and-forth in indecision.

To the organizers, it felt chaotic, unprofessional, embarrassing.

To the participants, it was the first breath of oxygen. They were optimising for themselves, reconnecting with someone who’d opened up last time, or someone who they’d noticed spoke their language.

I remember thinking: this is all anyone wanted. To find their people. Not find a team, not choose a track. Just people they can relate to.

The breakout room scramble became a fun game that people looked forward to, part of the culture. It felt more like walking into a local cafe, saying hi to a bunch of people, and choosing who to sit with. After being able to connect a few times, people started meeting on their own. Which, ironically, is what the organisers had always hoped for.

Healthy forks, right in front of us.

We know this stuff, but keep getting in our own way.

Mina was the first blockchain project to use ZK proofs at the protocol level. Its architects and crypographers are deeply respected in technical circles.

But four years in, they hadn’t really shipped a usable production chain. The org structure kept getting in the way.

Minacon was an unconference I organised for them—three days where participants had equal control of the agenda. Each day’s schedule started with an open grid of parallel rooms with 45-minute sessions. Anyone could propose anything. No speakers list. No speakers room. No VIP treatment. The message was: we all have something to learn from another.

Mina’s mobile-device proving had been at a stand-off. It needed app builders, cryptographers, and library maintainers to coordinate. Different orgs, different incentives. Months of forum threads—arguing, not seeing eye to eye.

But five of them in a room for 20 minutes, showing code, seeing what each was up against? It was simple once it came down to practicalities. Instead of fighting over on/off-device ideology, they each saw they could unlock each other. And they quite happily did.

The answer wasn’t one or the other, it was both.

Then there were the two orgs running forked nodes, locked in a cold war for years. Communication had always been routed through managers who treated their roadmaps like chessboards—every feature, a pawn to box the other side in. This made "Feature Parity" into a way to exert pressure, but also an uncatchable moving target.

Once the builders were in the same room, they understood each other.

Turns out, both dev teams had wanted the same thing for years but were always forced back by their managers. Their technical debt accumulated, and each dev team though it was coming from the other org. This revelation freed both sides to cut loose, and move towards their common goal.

Forums, boards, devrel—they actually cut off relationships and filtered the wrong information. It wasn’t the people in them, it was the structure getting in the way. People just needed to connect directly.

That 3-day unconference took two months of prep. I called every participant in advance so they’d feel okay proposing sessions. Checking in on what they were stuck on. Making sure everyone knew who else they needed and affected before day one.

That was 95% of the effort.

The execs and architects had expected to route their agendas through me, to secure a keynote or other special placement. I’d playfully tell them: "People will really love that topic. Propose a session on it at 9am on day one."

For the unconference to work, it had to stay neutral tool for connections to form and grow, a place where each individual was in full control of their experience. Everyone had a lot to achieve in that short time. It was there to serve their goals.

When divergence becomes painful, it’s usually because the structure stopped responding to the people inside it. Requests get dismissed as "edge cases," problems accumulate, and eventually the only release valve is a dramatic split.

The unconference approach let everyone choose where they wanted to participate, and gave everyone unconditional, direct access to who they needed.

Giving people what they need can dissolve conflicts. Who knew?

I’ve experimented with this in other ways: people pulling each other into temporary clusters, then drifting apart again.

I’ve started a POC called Fusion: a lightweight way to find collaborators through quick left/right swipes down a list of people. It uses MPC cryptography so small groups can form around everyone’s yes/no choices without revealing them. Private, low-friction, ephemeral formation. Not an org or group you have to maintain—just the right people, right now.

Fission is the opposite: letting groups split without rupture. It’s a take on Moloch DAOs, but inspired by the failed NounsDAO forks.

MolochDAO’s orignal RageQuit design was meant to incentivise understanding and discourse, because minorities couldn’t be forced by simple majority. If they didn’t like a proposal, they could exit with their share, so better to get their input first. Ragequit in a NounsDAO structure had the opposite effect, amplifying divisiveness, forcing the dissenters out into the cold. Don’t like it? Take a walk. The remaining members also suffered, because they saw massive treasury depletion.

With Fission, a failed proposal can trigger a gentle amoebic split: a minority can still fund their idea in a new DAO while continuing to belong to the original one. A non-exclusive fork. No winner-take-all pressure. No exodus required. And divergence doesn’t get suppressed or built up over time.

Fusion and Fission are based on social games I’ve tried in different builder groups.

They worked, so the next step is tool-ifying them. When the tool’s in your hand, you don’t need fell the need to wait for programs or orgs to serve you. We can start connecting as needed from wherever we are, introducing healthy forks where they’re needed.

We can design for healthier forks.

When I look elsewhere for healthy forks, I see real-world examples in film, VC, conferences, academia...

People pick up collaborators as they need them, drop into parallel efforts, and let the structure emerge from whatever they choose to work on. Resources flow to activity.

These are places where nodes connecting and detaching are the real structure behind thin institutional labels and super-imposed hierarchies.

That builder group? Sadly it fizzled out. Turns out one of the company owners was doing most of the work, and when he couldn’t agree with the other, he just found another job. They kept it quiet, both names stayed on the site, but the program spiralled.

I keep in touch with some dev friends I’ve met at hackathons and conferences.

We recently started a weekly hangout call. People joined because we were already talking, or because I mentioned someone they should meet.

It’s the builder group I always wanted for myself. People with passion projects and always learning random new stuff.

Some of them suspected I had a big, master plan behind it, and that’s kind of true? Really it’s more of a speculative thesis. I wonder if we might co-develop these connection tools to see what "program", if any, emerges.

Still, we have unanswered questions:

How do we launch a without implying an organizer-participant heirarchy? Even the faint suggestion of a central host leads people to wait for permission. I want affordances that say, "it’s yours, make it what you need it to be."

How do we help builders surface blockers early? Open-source culture rewards stoicism: the heroic week of hair-pulling before writing a bug report. (Because of our assumptions about accessibility to help.) The healthier pattern is stuck → get eyes on it. Anyone who’s pair-programmed has felt this. It requires norms around vulnerability, and a culture where asking for help is treated as a contribution, an opportunity for others to learn too.

How do we make FUBU real from day one? If first participants don’t just use the tools, but make them, then they own it as much as me. That’s the the deep pattern with healthy forks: people designing their own tools into their own experience.

I’m open for ideas, and honestly, we’re having fun sharing our own projects already. It’s just that I think we’ll have more fun if any of this works.