No ~~Kings~~ Benevolent Dictators for Life
Strong leadership is sometimes required to keep Open Source projects vibrant. Yet there are many possible forms of effective governance, including—yes—democracy. By Jared White
ICYMI, there was recently a groundswell of political fervor here in these United States of America called #NoKings. Seems folks are upset about the idea of their country being run by a Dictator.
Well…given this I figured it was time for me to tackle another political movement found in the world of Free/Libre/Open Source Software (aka FLOSS) which promises some odd parallels. Note: you don’t need to be a programmer to grasp these concepts! I will attempt to write about this from a “tech enthusiast” perspective.
To set the stage: I am here to convince you that the concept of a “BDFL” (Benevolent Dictator for Life) is a messed up idea. (Time to make some signs and post #NoBDFLs perhaps?) Furthermore, the “keep politics out of open source” folks are every bit as responsible for keeping politics in open source as the people they routinely get mad at. They’re not above the fray. They are the fray.
Besides criticism of the idea of a BDFL itself, there’s also a case to be made that being a BDFL isn’t ideal for many of the BDFLs out there. Burnout & disillusionment is a real concern for long-term open source maintainers, and as we just saw this week in the Mastodon project, it takes a massive effort to transition out of top-down leadership effectively and ensure the technical and communal infrastructure thrives after you’re gone. But this is a subtopic worthy of its own treatise.
This essay isn’t the first time I’ve talked about the fraught state of open source communities online, and it likely won’t be the last. But I think today’s topic is a key to unlocking what’s really been at the heart of a lot of the flame wars and consternation over recent months.
Are you revisiting the role computer technology should (and should not!) play in our lives? Stay in the loop with my newsletter Cycles Hyped No More:
Let’s get some disclosures out of the way first and cover a wee bit of history. I myself am a BDFL (arguably). Busted! 😂
I have been founder & lead maintainer of the Bridgetown web framework (written in Ruby) for five years and counting. As much as I might personally wish otherwise, there is no “Bridgetown Foundation” or formal legal organizational structure to the project. There are no bylaws, there is no charter. Yes we do have a Code of Conduct and process for onboarding new Core Team members. Yet for all intents and purposes, the project persists over time because I “will it into continued being” through my action (or at times past, regrettable inaction).
Is it “bad” that I’m a BDFL? Some would say no! The term itself is one of those originally endearing holdovers from early Internet hacker culture, originally applied to the creator of the Python programming language Guido van Rossum. There’s also precedent for using the more general term of “benevolent dictator” found among other places in the writings of Eric S. Raymond (an early figure in the history of open source advocacy).
The overall idea is this: open source projects benefit when there’s a single voice who is providing overall guidance and direction for the project. It avoids the “design by committee” problem which can plague software development, and it also avoids the problem where a distributed group of volunteer contributors might devolve into infighting and stalemates over any number of technical questions.
Advocates of the BDFL model such as David Hamburger Helper—I mean David Heinemeier Hansson (DHH) will cite projects like Linux and of course Python as successful examples of BDFL-led development, as well as projects which I’m intimately familiar with as a programmer such as the Ruby language and the Rails web framework.
As anyone who knows what’s been going on with Ruby & Rails lately can tell you, this is no longer a ringing endorsement. Furthermore, DHH himself was tripped up by a public example of BDFL-gone-bad with the whole Matt Mullenweg/WordPress debacle a year ago.
BDFLs are the way to go! Until they’re not.
Surprise? The Hazards of the BDFL Model are the Hazards of Power
We all know the phrase: power corrupts, and absolute power corrupts absolutely.
One of the oft-cited rationales for why it’s not a bad thing for an open source project to have a benevolent dictator is that “you can always fork it”. Forking an open source software projects means that you take the source code, rehome it under a new umbrella organization with a new name, and continue development as a separate project. This is often considered undesirable since it splits community efforts and can introduce intractable incompatibilities (less likely with a “soft fork” vs. a “hard fork”, but that’s really getting into the technical weeds). But forking is always a possibility, which is supposed to keep project BDFLs and core teams “honest” and at least somewhat beholden to listening to community feedback and concerns.
I believe this is largely a myth.
Over many decades, we have seen time and again that open source projects run in dictatorial ways do not tend to reform simply due to the looming specter of a possible fork. Network effects, convenience, and sometimes raw $$$ will keep people close to the center of power and they simply turn a blind eye. Sometimes we’ve seen that after a fork occurs, turmoil within the originating project leadership can cause changes over time to where the two projects later decide to converge in some fashion. (Recall the Node.js vs. io.js fork and later recombination in 2015. Also note the fact that BDFL-style governance was cited as one of the issues leading to the fork!)
But more often what we typically see is what I call the brain drain problem. People on the edges of the power center and beyond witness the harms inherent with BDFL-out-of-control and an unresponsive core team which cares more about allegiance to the dictator than allegiance to community health at large, and they nope on out of there to find other technologies and other communities (or create their own!). Sometimes those harms are due to overt political failings (as seen in recent Ruby/Rails dramas), others are simply economic (if the the BDFL is essentially a corporate mouthpiece and the project is corporate-captured, then this is all just “how business works”).
It may be all well and good to praise benevolent dictators for their benevolence. The thing is, dictators rarely stay benevolent for ever. Sooner or later, absolute power corrupts absolutely, no matter how well-meaning that person might start out.
Let’s put this another way, in familiar business terms. The founder of a new startup is often the wrong person to lead the business long-term. The singular set of skills they have: being a self-starter, holding strong opinions strongly, having a reputation as an iconoclast—there are all helpful at the beginning of a major initiative but they do not serve an organization well as it matures.
Every once in a while, you may discover a unicorn who manages to cross that chasm. Steve Jobs arguably did this, although it did take a circuitous route. Could the “second coming” of Jobs as Apple’s CEO in the 2000s have happened as it did if he hadn’t been kicked out of Apple in the late 1980s? Perhaps not. He had to go on a journey through the wilderness to find himself, so to speak.
Now imagine an early Jobsian figure birthing an open source project, being hailed as the BDFL, and then never, ever moving away from that position over decades. It’s not hard to conceive of all the ways that could go terribly, horribly wrong.
Yes, it’s true that strong leadership is sometimes required to keep projects viable and work flowing smoothly. Anyone who’s ever been part of a volunteer organization knows this. Yet there are many possible forms of governance, and it’s a self-serving misdirect to claim, as DHH does, that “the advantage of the BDFL model is exactly in allowing for unpopular decisions to be made without the lethargic mores of committees and bureaucracy! Open source is not a democracy, and we all benefit from that fact, whether we accept it or not.” 🤨
(It’s also worth speculating on what the connective tissue might be between DHH’s views on “democracy” in open source and his political views in general. It doesn’t take much imagination to put the puzzle pieces together.)
But Aren’t Successful Open Source Projects Run by BDFLs?
DHH cites Linux as a prime example of a wildly-successful BDFL-led project. Linus Torvalds famously wrote the first Linux kernel way back in 1991 and has stewarded the project ever since as Linux grew into a fully-fledged operating system (technically hundreds of operating systems called distros—also it’s GNU/Linux, or GNU plus Linux 🤓). Clearly since Linux runs your toaster and your car and your game console and the web servers you probably connected to a few minutes ago, BDFL is the shit. BDFL ALL THE THINGS!!!
Well…
Is that actually the case? Not exactly.
While it's true that Linus Torvalds continues to have final say as to what goes into a Linux kernel release, and his influence on the community is undeniable, there are a number of mitigating factors to the notion of one individual calling all the shots.
- Linus Torvalds is sponsored by the Linux Foundation. Linus himself is not on the Board of Directors, the managerial Leadership team, or the Linux Technical Advisory Board. He is a Linux Foundation "Fellow".
- Linux kernel development has a rigorous process due to the stringent performance and security requirements. There is an astounding number of maintainers assigned to stewardship over myriad subsystems. Here is an official list.
- "Linux" is about so much more than just the kernel (as the aformentioned GNU + Linux meme goes). So many of these aspects of the overall Linux experience have nothing to do with Linus Torvalds' direct authority. Many corporations, hobbyist projects, and other entities contribute to the overall Linux FLOSS community outside of any connections to Linus personally.
- Linus once stepped aside for a time. And for good reason—his abrasive, and at times objectively abusive, behavior towards anyone he disagreed with had been the stuff of legend, and even he came to realize it was time for a change. Torvalds wrote in an email that "people in our community confronted me about my lifetime of not understanding emotions" and admitted his "flippant attacks in emails have been both unprofessional and uncalled for, especially at times when I made it personal." He decided to take time off to "get some assistance on how to understand people’s emotions and respond appropriately." It should be noted there was also a huge battle over adopting a real Code of Conduct to replace a “Code of Conflict”, and thankfully Torvalds came to publicly realize its benefits and support it.
I suppose you might say Linus got caught up in "societal moral panics" as DHH puts it…or maybe he simply realized being a jerk isn't a prerequisite for effective stewardship of open source. It seems Linus, and the Linux kernel development process, has had to mature to encourage healthy collaboration.
One aspect of “BDFL”-ness which is sometimes cited is who owns the trademark to a project. Linus Torvalds does own the trademark to Linux/LINUX, but the way in which it is “administered” falls under the purview of the Linux Foundation.
OK, so maybe Linux does operate under a BDFL-led model…with a lengthy list of caveats. What about Python as was previously mentioned?
Well…here’s where things get more interesting. Python is no longer BDFL!
That's right dear reader. Guido van Rossum stepped aside as Benevolent Dictator for Life in 2018 (that’s seven years ago!), and the interesting thing is, he made a specific point not to appoint a successor.
In the vein of many large open source projects, there's a foundation (the Python Software Foundation) which helps to oversee many aspects of Python maintenance and infrastructure, and the language itself evolves through the introduction and discussion of PEPs (Python Enhancement Proposals). Even the process of joining the Python core team is in fact democratic. This would seem to be in direct contradiction to the claim by DHH that "open source is not a democracy". Again, his lumping Python into examples of great BDFL projects is seven years out of date. (It should also be noted that Python offers a fairly robust Code of Conduct.)
As to the success of Python overall as an open source project, I will present this article without comment.
Now for the Elephant in the Room: Ruby & Rails
I’ve been dancing around the meat of this topic, so let’s just get right to it:
Both the Ruby programming language and the Ruby on Rails web framework are BDFL-led open source projects. And I am here to argue this is a bad thing—and my proof is the ongoing controversies and bad blood now swirling around both projects.
There are a variety of long-standing issues at play here, so I will try to break it down (again I will try to refrain from getting into any programming-specific jargon):
- Issue 1: the Ruby Core team, at the direction of Ruby’s BDFL Yukihiro Matsumoto (known as Matz) and executed by one particular individual (known as HBST), took over open source infrastructure to which it had no right (at least in a moral sense…the legalities are murky). This happened because of a variety of poor decisions by multiple parties (namely the separate non-profit organization Ruby Center) which were made unilaterally outside of any community input.
- Issue 2: because there’s no democratically-elected group of people running a “Ruby Foundation” organization as we might expect, there is no recourse for these actions nor is there any guarantee future actions taken in poor taste can be stopped from occurring. As much as many Rubyists believe Matz to be a nice man, in a case like this is is literally his way or the highway. If you don’t “like” what happened…stop using Ruby?
- Issue 3: the organization in the midst of this controversy, Ruby Central, is itself under fire for non-transparent leadership which has repeatedly angered many in the Ruby community this year. This is where “the DHH connection” comes into view. Without going into great lengths, the TL;DR here is that DHH is a far-right bigot whose public writings are awash in dank edgelord memes and fascist-friendly talking points. It’s difficult to deny he has outright graduated (not the best term to use!) to white supremacy this year, and it’s a very bad look for the Ruby community. Because of Rails’ dominance as “the Ruby framework” (not in any sense technically, but in terms of mindshare/marketshare), Ruby Central as of this year has been unable or unwilling to stand up to his bullying and trolling.
- Issue 4: Rails itself does feature a “Rails Foundation”, born out of a previous schism between DHH and a previous incarnation of Ruby Central more willing to deplatform him for valid reasons. However, the Rails Foundation is essentially an organization responsible for marketing & promotion of Rails and converting corporate sponsorship money into conferences such as Rails World. The open source codebase remains under the purview of a core team with DHH firmly ensconced as BDFL. Despite nearly 150 signatories for Plan Vert, an open letter requesting that Rails core team members cut ties with DHH due to his abhorrent political views, no actions have taken place.
- Issue 5: Unsurprisingly, DHH has consistently and repeatedly sided with the most extreme pro-BDFL narratives surrounding the Ruby Central debacle, going so far as to dive into dangerous conspiracy theories about individuals involved and routinely tie these specific incidents into a larger screed about “peak woke malcontents” and “aggrieved individuals” and expressing the goal to “reject and ignore these nut jobs.”
In both cases, Ruby the programming language & Rails the framework, the actions and/or views of specific leaders with access to the levers of power and entirely unaccountable to the broader community have resulted in an atmosphere of intolerance and of silencing descent.
My anecdata is that the brain drain problem has reached critical mass. I know many talented, enthusiastic programmers who are in the process of leaving the Ruby ecosystem for good or who have already left. Without the hope of enforcement of a robust Code of Conduct in any of these problematic scenarios, without any democratic organizations who are able to hold those in power to account, it really does feel like “might makes right”. I’m not here to say all hope is lost—in fact, I’m in a number of backchannels with Rubyists who are pushing for new technical and communal infrastructure to combat this awful state of affairs.
But arguably we shouldn’t have ever arrived at this point. If there was a genuine “Ruby Foundation” with clear processes for leadership roles and community debate (and no BDFL!), if the Rails Foundation was more than just a “corporate money → conferences & marketing” vehicle, if Ruby Central had the proper structure and resources to enforce their own stated Code of Conduct and not become beholden to bullies…well, the Ruby landscape would look pretty different.
What is the Main Takeaway? How Do We Solve These Problems?
Here is my short and succinct view on the matter; food for thought I myself will be chewing on as I contemplate the future of the Bridgetown project of which I’m currently BD (but not FL I hope!).
- A good Code of Conduct, ideally based wholly or in part on Contributor Covenant, needs to be in place and enforced when community schisms arise. The goal isn’t blindly to “cancel” someone who seems disagreeable at times. The goal is to ensure people in the community feel safe, especially those in marginalized communities like BIPOC and LGTBQ+. There should be a clear process for determining when violations have occurred and what to meaningfully do about it. It’s wild that I was able to summarize what Rails Core should have done about the DHH debacle in a single Mastodon toot. This stuff doesn’t have to be terribly complicated! Instead now DHH is attacking people in the Linux community because the Ruby community failed to hold him to account. Blargh.
- Recruitment of fresh blood, new talent, and out-of-the-box ideas should be top priority for any open source project of any significant size and longevity. The absolute worst thing which can happen is calcification, aka the impression that the only people who can effectively steward the project are the people who have being stewarding the project. This eventually becomes a snake eating its own tail as anyone with passion and big ideas seeks greener pastures elsewhere. Brain drain.
- All BD-led open source projects should make plans—somewhere down the road at the appropriate time—to kick the FL part to the curb. No lifers allowed! Yes, that includes me. 😅 At some point, I will want other leadership to take over for Bridgetown, as well as any other large open source projects I happen to be running. If this never happens, I will have failed in my own leadership. I’m not willing to accept that, and neither should you.
- Open source projects with “influencers” at the helm should speak out loudly and continually on these issues. Stop letting the bullies in the room dominate the conversation! Speaking of bullies, and snakes, it was wonderful to see the Python Foundation reject the bullies of the Trump Administration and unfortunately have to turn down $1.5 million in grant money because of the fundamental incompatibilities between Trump’s attacks on DEI and Python’s embrace of DEI. While the circumstances are awful, it’s been most welcome to see the huge groundswell in community support. May other open source communities take note!
- Get up, stand up for your rights. Life is too short to put up with social media edgelords and chatroom trolls. People in open source communities don’t need contend with the demands of bad faith actors. Tell them their behavior is unacceptable and that our community deserves better. Never apologize for fighting back…and also if things get really bad, LEAVE. Leave! Your personal and emotional safety is more important than what some group of Extremely Online bullies might say about you.
And to the “get politics out of my open source” people I say to you: all community work is politics. Open Source IS a Democracy and a Community*, and the people who say otherwise are sadly and dangerously wrong.
* (Just to head off any complaints, I’m not talking about small one-off projects from devs who simply want to chuck some code over the fence onto GitHub and then forget about it. That’s fine! I’m talking about Big Projects with Teams of Contributors and Many Users. If your attitude is “the only people entitled to say how open source ‘ought’ to work are people who run projects, and the scope of their entitlement extends only to their own projects”…well, I’m glad I have the personal choice to seek technical & communal solutions elsewhere.)
💬 Discuss this essay on the Human Web Collective ➡️
Thank you for reading Cycles Hyped No More. Join Intuitive+ and support my independent publishing, and please share with a friend! See you here next week.
Jared ✌️
🤔🌩️ Things that make you think:
Open source software is, at its heart, a utopian project. It’s an incredible public good. I feel so blessed that I got to build my career on tools that everyone can use and build on.
It may not necessarily produce the best, or the most polished tooling, but on a long-enough time scale, open-source is the only tooling that will continue to exist, that won’t suffer from planned obsolescence, or vampiric business models. That you can rely on to still be there.
As a parting note, I’d like to say that we need to build better structures for open source governance. That’s a tricky design problem! I don’t know how to solve it. We’ll have to experiment, and iterate, and figure it out.
I have a few clues, though. Project governance needs to be accountable, and transparent. The best way, the only way, to achieve that is for project organizations to be democratic. Their leaderships must represent the interests of the people who use or depend on the tools we’re building.