The Rogue Emperor, And What To Do About Them

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.

36 thoughts on “The Rogue Emperor, And What To Do About Them

  1. Code of conduct for ALL potential contributors…not just the dictators…would go a long way.

    Often the view that a dev is a dictator or gatekeeper has been created by the same people who caused the situation. Constant harassment by “contributors” along with a steady stream of subpar merge requests frequently leads to this behavior. (based on my observations)

    Sometimes the contributions are not as important as thought, are impossible to merge without breaking a long chain of projects (usually the “dictator” or “dictators” are the only ones who know what will break or do testing), or more frequently…the contribution is just terrible.

    From my experience…the ones with the worst contributions are the first to go out and flame a project on as many forums as they can. Bonus points when they don’t allow comments and refuse to remove the posts when they are proven incorrect.

    Sometimes you don’t know you are talking to a person with 40 years of coding experience that is retired and doing the work for free. They are not “obligated” to do anything…their work is a gift. It is often contributors who are inexperienced (or still in school) are angry that a dev won’t take their merge. Sometimes the dev is tired of explaining things and had a bad day…they may not have time to say anything more than “your code sucks…go read our terms for contributors and rewrite it”.

    And yes…all opensource should be viewed as a gift…not an obligation. If you don’t like it…make a fork. That is not an unreasonable ask. After all…they could have just patented it or made it closed.

    To state that “Capable dictators need to be kicked because users are incapable of making a fork” is a take that I personally would not get behind. Especially when the view of “dictator” is typically not shared by the entire user base. It will only degrade the code.

    It is easy to talk trash online…it is more difficult to maintain a project and be sure it works for all users.

    Don’t forget…core devs are people too.

      1. My experience is mostly observation. I do not code.

        The experience/observations are mostly from being involved in QA/Hardware production of Smoothieboards…as well as being heavily active in RepRap since 2011.

        I have seen our devs get trashed…and I have seen them trash others. But without knowing them personally it is hard to know stuff like “his dog just died that day and his temper was short”. Especially when dealing with the amount of misinformation or nonsense that flows in daily.

        I hope my statements are read from a factual standpoint…not emotional. I really did attempt to convey the opinions I have in a way which is understood rationally…but without talking to me in person all emotion and body language can be “assumed”.

        As a question for all reading this: When was the last time you messaged a dev directly and thanked them for their work?
        I attempt to do this every now and again…just be sure it is a heartfelt and not for personal gain.
        Often…core devs don’t get any “real thank you” unless they are directly solving an issue or about to be asked to do so. Almost every dev I have thanked has asked “What do you need?” which to me is a symptom of a larger problem.

        There is a lot less reward for doing opensource work than most assume.

        1. Having been on the other side in some arguments in the Smoothieboard community a decade ago, I do feel a bit apologetic. It simply didn’t do the things I expected it to do, and having bought a (somewhat) expensive board I was disappointed. But this blinded me to the people for who Smoothieboard did do what they wanted, and the balance that the maintainers of such projects need to make.

          1. It is a complex project with a lot of machines dependent on it. Very hard to relay that to the newer devs that a small change for “your machine” may break thousands of other machines.

            In all fairness…quite a bit of the things that are requested are not well documented and without being able to speak directly to the core dev (often the only person who knows) limits the ability to get setup.
            For example…the feed hold or pause delay. I finally got an answer on that…it isn’t the queue size…it is turning on delta segments. If you set that to 1mm it stops after that distance.
            Why isn’t this on by default? In some situations it can cause issues with the “lookahead”.
            This is another writeup which deserves a wiki page all to itself along with some videos…it is in the planning phase.

            The most major flaw of opensource is funding. It is largely on the backs of volunteers.
            The reason Smoothieboards cost more than the clones is that sales of boards is where the majority of the money to develop Smoothieware came from. Clones do not have this ethical obligation.
            A disproportionate amount of support went to supporting issues with use of clone boards as the majority of hardware issues and strange glitches were due to poor QA/design/parts procurement. Not only was this work for free…but it could be argued that it was paid for by the Smoothieware project.

    1. yes…all opensource should be viewed as a gift…not an obligation

      Which is why it generally sucks. You can’t criticize a gift, which removes the feedback between users and developers, which leads to development in the dark and huffing your own farts.

      With proprietary software, if the result doesn’t please the audience then you’re quickly an ex-developer. If the software does not serve its point then it soon will not exist – whereas with open source you get people noodling forever around half-assed and mis-understood attempts with a handful of die-hard users who have adapted to the software instead of the other way around (systems attract people who are fit to the system), who will scream loudly whenever someone tries to point out that they’re doing things the stupid way.

      1. You are free to criticize all you want…but at some point you may be required to “do something” yourself.

        Criticism is only helpful if it is constructive…
        Difference between a critic and a troll is “doing”.

        1. There’s the old saying that you don’t need to be a chef to tell a turd sandwich.

          Even if you can’t or won’t do it doesn’t mean you can’t point out that something is wrong, and knowing that something is wrong puts the impetus on the actual developers to fix it. If they ignore or deny an obvious problem, who’s at fault then?

          1. More to the point, users are not developers and should not be expected to provide “solutions”. That would be unhelpful, as they’re largely incompetent to do so and would only mess up the process.

            So then, would you ignore your users entirely because they cannot help you directly? It’s your users who are receiving the software as a “gift”, since they are unable to contribute entirely, so should they be unable to criticize it as well? Should you only listen to your developers who are already working on the project and stuck in the ways they’re progressing in it?

          2. “Don’t judge a man until you have walked a day in his shoes”

            I’m not judging the man, I’m judging the shoes. I’m saying the character of open source projects lends to people doing silly things because they don’t have to mind the people – the users – that the software is really made for.

            If you forget this, it’s like setting off across the desert in high heel stilettos and then complaining that your calves hurt after a mile. Foresight is also a thing.

        1. It doesn’t have to be any different. It’s just that you can get stuck in that sort of a bubble because you refuse to listen to outside criticism and oust everyone who disagrees from your community.

          You can serve the ten people who already agree with you and pretend that this is the entire world, but the world doesn’t have to agree.

  2. 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.

    When I read that I thought this was a mistake, and that the constitution should be a separate document from the license, so that each could be chosen more freely, and so there wouldn’t be even more difficulty in cases where relicensing is actually wanted. But then I read on…

    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.

    …and that’s a very good point. There does need to be a way to keep the constitution from being changed too easily, and including it in the license could be a way to do it—and a way that could, if properly written, make it legally enforceable by contributors. I do wonder, though, if there’s a good way to do it with two separate documents that are still linked together somehow.

    1. You want that in a project you start, lead, and put countless hours of your life into? Go for it. Make sure and let us know when you get the boot for not keeping up with the insane demands that’re completely unrelated to the project itself so we can laugh in your face.

  3. I thought about this recently, not how the problem pertains to software but to our own government. I believe that we need to switch to AI there, and we would then vote one the open source code it runs and the rules it follows. It of course would adhere to the US Constitution and violating it would be as verboten as dividing by zero. Humans cannot be trusted, I firmly believe if you take the Terminator movies to their logical conclusion there will be a group of in control of Skynet that the characters in the movies had no idea even existed.

    So I think there should be some kind of voting mechanism to determine the direction of the code when it comes to open source software, a Constitution it cannot violate, and I suppose some checks and balances to deter the inevitable human corruption.

    1. We build a few advanced chatbots and you want to turn over navigation of the collective will of mankind to them. No. This Mandarin clerk belief that ideal government is merely a crude loyalty towards procedural rules and rituals.. it’s baseless. Great moments in history happen because of the vision and fortune of great men, and to fecklessly whittle that away because it’s not “safe” will lead to mushy decay back into primitive life. Mankind votes for a person they want to lead, bug life votes for revisions to the open source government algorithm

  4. Does this article have a point?

    Tell us what you’re going to tell us.

    Tell us.

    Tell us what you told us.

    I’m getting locked door with a whiff of bleach here.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.