Been thinking about three recent “to fork or not to fork” cases—the Linux kernel, the Rails fork @mosscap, and the recent no-AI hard fork of Firefox basebrowser (among many other forks).

Two happened, one didn’t. People are simmering over the corporate capture of the Linux Foundation, wondering whether the kernel is “too big to fork”. That can’t be good.

I tend to think that:
- More choice is better for users (the ultimate deciders)
- Creating something new isn’t the hard part; ongoing maintenance and community-building is.

Some people think “the project forked” is a bad thing or a “failure” to prevent, when it could create more choice *and* free unhappy contributors if intuited and managed correctly.

A fork *should* be the healthy outcome of a marriage-like “irreconcilable difference”, otherwise you end up with a hostage-like situation, which is what the Linux world feels like today. Hostages (in general) could become resentful and sabotage a project. Whether they succeed or not, it’s no good use of brain cycles.

There’s a lot in here we’re thinking about as we build #Rhizo and group management tools.

It should be easy to fork without (too much) resentment so no one is incentivized to sabotage, and the opposing side can’t steamroll a (sizable) minority without consequence.

Too easy to fork carelessly and groups can fall apart too easily if/wwhen minor disagreements hit; too hard and forking remains difficult, if not purely theoretical, and no one gains.