The chances are if you know someone who is a former Apple employee, you’ll have heard their Steve Jobs anecdote, and that it was rather unflattering to the Apple co-founder. I’ve certainly heard a few myself, and quick web search will reveal plenty more. There are enough of them that it’s very easy to conclude the guy was not a very pleasant person at all.
At the same time, he was a person whose public persona transcended reality, and his fan base treated him with an almost Messianic awe. For them everything he touched turned to gold, every new feature on an Apple product was his personal invention, every one of his actions even the not-so-clever ones were evidence of his genius, and anyone who hadn’t drunk the Apple Kool-Aid was anathema. You’ll still see echoes of this today in Apple fanboys, even though the shine on the company is perhaps now a little tarnished.
It’s easy to spot parallels to this story in some of today’s tech moguls who have gathered similar devotion, but it’s a phenomenon by no means limited to tech founders. Anywhere there is an organisation or group that is centred around an individual, from the smallest organisation upwards, it’s possible for it to enter an almost cult-like state in which the leader both accumulates too much power, and loses track of some of the responsibilities which go with it. If it’s a tech company or a bowls club we can shrug our shoulders and move to something else, but when it occurs in an open source project and a benevolent dictator figure goes rogue it has landed directly on our own doorstep as the open-source community. It’s happened several times that I can immediately think of and there are doubtless more cases I am unaware of, and every time I am left feeling that our community lacks an adequate mechanism to come through it unscathed.
In theory, the advantage of open-source software is that it provides choice. If something offends you about a project you can switch to an alternative, or if you are a software developer you can simply fork it or write your own competitor. Both of those points you’ll still see trotted out by open source developers when they face criticism, yet both of them are increasingly fantastical. The scale of many large pieces of software means that there is an inevitable progression towards a single dominant project, and the days when all users of open source software were capable of writing it are long gone if they ever existed at all. In many cases the reality of large open source projects is one of lock-in just as much as in the proprietary world; if you’ve put a lot of effort into adopting something then you’re along for the ride as the cost of changing your path are too significant to ignore.
So how can we as the open source community deal with a rogue emperor in a project we rely on? In some cases the momentum can eventually gather enough to generate an alternative path, you will probably come up with the same examples I’m thinking of as I write this. But all too often either a loyal Praetorian Guard of developers protect their leader, or a firm grip on the non-open-source IP surrounding the ecosystem keeps the problematic figure in place despite all attempts to move forward. Perhaps it’s time not to consider the problem after it happens, but before.
A central plank of the open source community lies in the licence. It sets down the framework under which the software can be used and shared, and there are a huge number of choices to reflect the varying ideals of software developers. It’s a great system in what it sets out to do, but I feel there’s an aspect of open source software it fails to address. Perhaps as well as considering how the IP is regulated, a licence should also commit the project to a system of governance, much in the manner that a country will have a constitution. If this constitution is written to maintain good governance and combat the threat of a rogue emperor it could only make for more stability, and since any code contributions would be made under its terms it would be very difficult for someone intent on breaking that governance structure to remove.
One thing is for sure, it’s becoming wearisome to find afresh every few months that a piece of software you use every day is associated with problematic people or behaviours. Something needs to be done, even if it’s not quite my suggestion here. What do you think? Tell us in the comments.