oss – Terence Eden’s Blog

The Peaceful Transfer of Power in Open Source Projects

@edent — Wed, 19 Nov 2025 12:34:27 +0000

Most of the people who run Open Source projects are mortal. Recent history shows us that they will all eventually die, or get bored, or win the lottery, or get sick, or be conscripted, or lose their mind.

If you've ever visited a foreign country's national history museum, I guarantee you've read this little snippet:

King Whatshisface was a wise and noble ruler who bought peace and prosperity to all the land.

Upon his death, his heirs waged bloody war over rightful succession which plunged the country into a hundred years of hardship.

The great selling point of democracy is that it allows for the peaceful transition of power. Most modern democracies have rendered civil war almost unthinkable. Sure, you might not like the guy currently in charge, but there are well established mechanisms to limit their power and kick them out if they misbehave. If they die in office, there's an obvious and understood hierarchy for who follows them.

Most Open Source projects start small - just someone in their spare room tinkering for fun. Unexpectedly, they grow into a behemoth which now powers half the world. These mini-empires are fragile. The most popular method of governance is the Benevolent Dictator For Life model. The founder of the project controls everything. But, as I've said before, BDFL only works if the D is genuinely B. Otherwise the FL becomes FML.

The last year has seen several BDFLs act like Mad Kings. They become tyrannical despots, lashing out at their own volunteers. They execute takeovers of community projects. They demand fealty and tithes. Like dragons, they become quick to anger when their brittle egos are tested. Spineless courtiers carry out deluded orders while pilfering the coffers.

Which is why I am delighted that the Mastodon project has shown a better way to behave.

In "The Future is Ours to Build - Together" they describe perfectly how to gracefully and peacefully transfer power. There are no VCs bringing in their MBA-brained lackeys to extract maximum value while leaving a rotting husk. No one is seizing community assets and jealously hoarding them. Opaque financial structures and convoluted agreements are prominent in their absence.

Eugen Rochko, the outgoing CEO, has a remarkably honest blog post about the transition. I wouldn't wish success on my worst enemy. He talks plainly about the reality of dealing with the pressure and how he might have been a limiting factor on Mastodon's growth. That's a far step removed from the ego-centric members of The Cult of The Founder with their passionate belief in the Divine Right of Kings.

Does your tiny OSS script need a succession plan? Probably not. Do you have several thousand NPM installs per day? It might be worth working out who you can share responsibility with if you are unexpectedly raptured. Do you think that your project is going to last for a thousand years? Build an organisation which won't crumble the moment its founder is arrested for their predatory behaviour on tropical islands.

I'm begging project leaders everywhere - please read up on the social contract and the consent of the governed. Or, if reading is too woke, just behave like grown-ups rather than squabbling tweenagers.

It is a sad inevitability that, eventually, we will all be nothing but memories. The bugs that we create live after us, the patches are oft interrèd with our code. Let it be so with all Open Source projects.

Book Review - Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal ★★★★⯪

@edent — Fri, 24 Dec 2021 12:34:25 +0000

Over the last 20 years, open source software has undergone a significant shift—from providing an optimistic model for public collaboration to undergoing constant maintenance by the often unseen solo operators who write and publish the code that millions of users rely on every day. In Working in Public, Nadia Eghbal takes an inside look at modern open source software development, its evolution over the last two decades, and its ramifications for an internet reorienting itself around individual creators. By delineating the structure of open source projects, she explores, for the first time, the maintenance costs of production that software incurs for its developers. Drawing on hundreds of developer interviews and analyses of platforms like Twitter, Facebook, Instagram, Twitch, and YouTube, Eghbal argues that examining who produces things on the internet, and not just what they produce, helps us understand the value of online content today.

This is an excellent book. If you're an experienced open source developer, it'll bring clarity to a bunch of concepts you're familiar with but couldn't name. If you're managing teams who work with - or produce - open source, it'll give you a greater understanding of the scene and its limitations.

Given the current furore with Log4J developers basically being volunteers, the book presents several ways that critical open source can be funded.

But, for me, the best thing about it is the way that it reflects our culture at this moment in time. Sure, it covers the history of F/OSS and it looks to the future - but it is mostly about what working on Open Source is like right now.

If you're interested in software as a cultural movement - and its intersection with commerce and government - this is the book for you.

Free Software as in Free House

@edent — Wed, 22 Dec 2021 12:34:17 +0000

Much like a Tesla, all analogies break down eventually.

As many many many people have said - free software is free, in much the same way as a free puppy is free.

I prefer to think of it as being free just like being given a free house is free.

Imagine that! Being given a free house would solve so many immediate problems. You'd have shelter, warmth, an administrative address, and a stake in the local community. All for free! Brilliant!

Of course, your furniture isn't going to quite fit. So let's knock down that wall. Pretty sure it isn't load bearing. Those creaking noises add character.

And, ugh! This wallpaper. Let's steam that off and give everything a nice coat of paint. Lovely. OK, we didn't have time to paint everything, so some walls are a different colour from others in the same room. We'll get used to it.

For some reason, the toilet is inside the shower. I'm sure that made sense for the old owner, but not for us. Let's re-do the bathroom. In doing so, we find that all the plumbing is a bit rotten. Can we live with that? Nah, let's unblock what we can, replace some of it, and do the rest when we have time. For some reason hot water now comes out of the stove. We'll put a sign up warning people.

Everyone has smart lights - we should too! But, it turns out that our wiring used the old standard. And we can't find anyone willing to work on it. How hard can rewiring a house be? Sure, we got a few shocks, and the whole house buzzes with static, and the new bulbs burn out quite frequently, but we added smart-tech to this old property!

We asked people in the local community if they could help with any of this - but they were so rude! OK, we weren't offering any money, and we kept asking daft questions, but there was no need to tell us to RTFM.

One prominent member of the community sent us loads of abuse. Apparently they can't be removed because no one else is as good as them at fixing all the broken windows and, besides, a code of conduct would add unnecessary drama.

Anyway, it turns out that the locks on the doors used the default key and we never bothered to change them. Someone broke in and stole all our stuff. And left surveillance cameras in the bedroom.

All analogies break down eventually - and I think I've stretched this one far enough.

Open source is a gift and a burden. If you just want to use something like Firefox as an end consumer, it is great. If you want to use something like WordPress, you're getting closer to free-house territory. Integrating a complex ecosystem of intertwined libraries into your existing systems is full-blown free-house territory.

There are no clear borders here - just a way of thinking about the cost of free.

You can't escape these problems by paying for a house. Even designing and building your own property comes with its own challenges.

You always need to understand the cost of a free gift.

What do you call open source software that just works?

@edent — Tue, 22 Jun 2021 11:45:41 +0000

The fashion industry has the concept of "prêt-à-porter" - ready to wear. You pick a thing off the rack and off you go. No tailoring needed.

Similarly, the food industry has "prêt-à-manger" - ready to eat. No telling l'artiste du pain how much mayo you want, just grab a boxed sandwich and start munching.

What's the equivalent for Open Source Software?

(I know it is facile to say "There are two types of X in the world..." but I'm going to do so anyway.)

There are two types of Open Source Software in the world, those that "just work" and those that make you want to bash your head against your monitor and go live in the woods without electricity.

In my infinite wisdom, the best sort of OSS requires no installation, no esoteric configuration, no mystic incantations, no downloading dependencies. A simple ./whatever and you're off to the races.

I loathe stuff where the running instructions say "Install these seven external programs (half of which require compiling, the other half haven't been updated in a decade), fill in this tedious YAML document with a billion options, download yet another version of Docker for no particular reason, oh and remember to set --safe-mode=true when you run or it'll delete all your files."

GAH!

I appreciate that some software is complex. And not everything is amenable to a flatpak or snap package. And a developer's time is finite. And you get what you pay for. And that sometimes it is simply better to have a steep learning curve.

But most times I just want to download and run.

So, on to the most important matter of this thesis. What should we call this sort of software? I conducted a highly scientific Twitter survey - and these are some of my favourite answers:

Pret-a-Docker? (oh god)

prêt-à-monger?

prêt-à-bugger

Prêt-à-plug-'n'-play