Command and Control in Open Source — the right to split

The reason why people like me are so strongly convinced that open source is the only way to go has nothing to do with “free”, with money.

It comes down to a more basic human desire — control.

What I want is that the software I depend on cannot casually be changed in a way that I don’t like. If the entity who happens to be in control right now has a lousy idea for the future of a specific software I want to be able to do something around it. Depending on how much energy I am wiling to put behind my action it needs to be effective — more effective than begging.

The way that it works in is one fundamental lever in the power balance — the right to split.

Let’s be honest — almost all software packages are currently under control of people who are picked at random. Very few original authors. How do we influence them to not do anything crazy to these software packages?

A proper Open Source software license allows people to “split” the project. What that means is that anybody can take the current state of that software (with source code), make changes that they like better than the old owner’s current changes, and then re-publish the result under a new name, as a new open source project. The new project has the same rights for re-distribution. From a legal standpoint, from a future ownership standpoint, and from a user’s perspective the original project and the split are now identical and divert from there future forward.

That is the one fundamental property of a “real” open source license that matters to me. The right to split.

[optional paragraph] Before we go any further, let me preemptively say that I realize how alien this sounds to some. Some might be willing to let people see the source code and incorporate changes that flow back from the community into the product’s code. But giving full rights to such a split-off? Doesn’t that fracture the community for that kind of software? Isn’t it to the benefit of the entire community around that specific kind of software if there is some leadership? Maybe with a committee that includes outsiders? Well, no. For me that isn’t doing it. If I don’t have the right to split it doesn’t count. Not having the right to split makes all other rights useless as far as future direction planning is concerned. I don’t really care what a piece of software does today. I think long-term.

So, the Right-to-Split, how does that help? Example time.

The entity currently in control of my mail program (to pick an example) has some batshit crazy idea for the next release. I don’t want any part of it. The new functionality (along with the existing functionality that they have to delete) makes the software worse for me. I know that other users feel the same. How do power and leverage play out?

• I voice my concerns
• other users/contributors agree with me, between 0% and 100%
• the current owners tell us to go to hell and they will go forward with their plan to improve/wreck the mail program

I now have the right to take the entire project at the current state, publish a copy somewhere, and make my own changes that are more to my liking. Some of those people who don’t like the original owner’s changes join me and contribute to my split instead of contributing to the original.

Now there is two projects and people-power is split. Progress is slowed for both. Does that really help?

Well, that does not help, but you just skipped a step. I said “I have the right”, not “I am doing”. The threat of the split is the leverage toward wielding power in open source — not the split itself.

You see, the original owners also suffer if I take some of the contributors. They get less code done. This is leverage. How effective is the leverage? That depends on how many people agree with me, how many would go with my split, and how much they contributed. The leverage is zero if none of us actually contributed anything so far (we can still split and have our stable version, though).

So, the amount of leverage to influence the entity current in power by random is proportional to how many people agree that their plan is bogus, people weighted by their contributions.

That is excellent control. If I have a point, a point that many valuable people agree with, I have high leverage. If I am just mumbling incoherent complaints I have no leverage, no matter how many other winers agree with me if they also never contributed. Even if I split nobody will care about the new branched split.

So — the point here is that although power and control works through the Right-To-Split, the game is actually played around not wanting to split.

Non-coding contributions and power

Not everybody can or wants to make large technical contributions to a project. Those people might still be very concerned about the changed direction of the original and would really benefit from a split. What can they do?

You can hire programmers to make the contributions you want, to your split. Those might be programmers you already employ and who divert some time. Or contractors that only do your open source work. This does not have to stay that way indefinitely. If your ideas turn out to be popular then you might get non-paid contributors later. Maybe you just needed working code to explain your point? Code talks. Those open source geeks glaze their eyes over powerpoint presentations. Code matters. Working code convinces.

Compare that to — say — Turbo Pascal. Current owner decides to turn a quick-turnaround mid-level programming language into some fantasy language (with only one implementation) and combine it with a toy database. WTF? Some old users like it, some don’t. How can you influence the owner of Turbo Pascal not to do that? Well, it is a commercial entity. You can buy the software package from them. If they don’t sell you can buy the entire (dying) company. Or you can beg. All not very attractive options. Or you can promise lots of $$$ from future purchases if the batshit crazy plan does not go through. Now you leak $$$ and you still have no rights to anything.

Splitty and non-splitty open source communities

An interesting aspect here to look at here is that some communities regularly and casually split and some others do not.

A good example is operating systems — BSD versus Linux. The Linux kernel is holding together very strongly and large amounts of code are absorbed into the same codebase. Somehow it is manageable and people don’t split. The BSD operating systems split a lot and specialize. NetBSD and FreeBSD — see history posted elsewhere. Then OpenBSD makes a split to go hard at extra security. That worked out great because the other BSDs are free to then cherry-pick improvements from OpenBSD that have proven valuable in OpenBSD. DragonflyBSD splits off from FreeBSD because FreeBSD wants a complicated kernel thread locking scheme and Dragonfly wants to stay with a simpler one. Valid reason to split. PC-BSD is not really a split off FreeBSD — but it does operates like a split. They just wanted to be branched off to be more radically user-friendly. By choice this split stayed very close to FreeBSD so that engineering is almost all shared. They did not use the right-to-split to make a big thing out of the split — but what made this valuable work possible is that the right-to-split was in place.

There was a split that was successful and went against me, personally. I did the work to turn the CMU implementation of Common Lisp (CMUCL) into an open source project, ca. 1996 (thanks again to Scott Fahlman). CMUCL was very hard to rebuild with itself. At some point I think we were down to 5 people in the world. One heroic individual got fed up and split the project with the specific goal to disentangle the codebase so that bootstrapping would be easier — SBCL. Removing the circular dependencies in the compiler disabled some of the cooler stuff, some “10 percept of optimizations were dropped” — whatever that means. At the time I ran happily with CMUCL and I was in bad need for fast code to enable the first air travel low-fare-searches that many of you used to fly around the world via ITA, Orbitz and countless travel websites. Still love you, Orbitz. I’m in production and speed matters. I can’t drop “10% of the optimizations”, regardless of whether that means losing 5% runtime speed or 25%. I can’t tell me boss to buy 5% more datacenter space and racks, and I can’t have the consumers on their web browsers wait even longer than they already do. Those are live queries, already at 10+ seconds. However, SBCL took off big time and the contributors that SBCL attracted that CMUCL could not attract made SBCL quickly plow all over CMUCL. (Except possibly for some floating point work). By the time ITA could finally go 64 bits SBCL was the only choice. Valid split. Image I had had the means and intent to control contributions to CMUCL — and not allow split. We would all look pretty stupid today. Just like Java does.