Unlike commercial software, open-source software is designed and built by communities of developers. Communities don’t have vice presidents, directors, managers or corporate committees to guide development.
There are a number of open-source governance models. One of those is the foundation model, which supports community-led development. Foundations ensure independence and efficiency, and under that model everyday decisions about features and releases don’t come from the top down. Those decisions are made by the project teams themselves and are centered in the community. Consensus is an important part of such community-led efforts.
There are also company-led open-source projects. A company-led project is controlled and financed by a software company, usually to accelerate development and ensure alignment with customer needs. In such a setup, the company has more control over development than the foundation does in a community-led effort, but governance is still rooted in the community.
Open-Source Governance Model: The Benevolent Dictator for Life
A third open-source governance model is the benevolent dictator for life, or BDL, model. On the surface, the BDL model looks similar to the community model, but for one big difference: at the top sits the BDL, who has the final say on features and release schedules. That one individual is the final arbiter of the software product and does not have to gain consensus regarding releases and other matters.
The BDL model is one of the oldest forms of open-source governance. It dates to the early days of open source, when much of the work was done by one person or a handful of people. Three of the most famous examples of open-source BDLs are Linux inventor Linus Torvalds, Larry Wall, the creator of Perl, and, until recently, Guido van Rossum, creator of the Python programming language.
Related Article: The Consequences of a Changing Open-Source Software Business Model
The Pros and Cons of the BDL Model
The BDL model for open-source development offers some distinct advantages. For one thing, the BDL provides a singular vision of the product. Products developed by committee are notoriously bland. Groundbreaking products often come from a visionary leader.
Moreover, communities can be disorderly — messy even — especially when there are competing agendas or points of view. There are time-consuming arguments and discussions without purpose. Compromises, even healthy ones, can leave important issues unresolved. The BDL model avoids those problems, because the benevolent dictator has the final say and can resolve conflicts by making unilateral decisions.
On the other hand, there are serious problems with the BDL model.
One issue is that benevolent dictators have an outsize influence on their open-source projects. A misstep by the BDL, such as allowing a bad or useless feature into the project, can unnecessarily consume resources and have adverse effects on the software.
Group dynamics can also be problematic in a BDL project, because the BDL sets the tone. A BDL who is mean or abusive or weak or obsessive can drive away talented contributors and push the project off a cliff.
The BDL model is contrary to the very idea of free and open software. Even projects with the best BDLs are by nature undemocratic. Indeed, the word “dictator” is, of course, the very embodiment of anti-democratic governance. No matter how much freedom the BDL allows project contributors to have, that one individual will still have the final say on the project and the product. In this case, the title — dictator — says it all. A benevolent dictator is still a dictator.
Learning Opportunities
Webinar
Mar
21
Ready to Level Up Your Learning? Discover Your Learning Maturity Score
Learn how to level up your learning program in this free, interactive workshop
Webinar
Mar
29
The CX Commute vs. the CX Joy Ride
Is your CX traffic holding up your customer's journey?
Webinar
Mar
29
Is Your Microsoft 365 Data Recoverable? How to Survive the IT Hotseat When Data is Lost
See why MIcrosoft recommends third party backup
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Conference
May
10
CMSWire CONNECT Customer Experience Conference - Austin 2023
Don't miss the top customer experience and digital experience conference of the year — live in Austin, Texas May 10-12.
Conference
May
10
Reworked CONNECT Employee Experience & Digital Workplace Conference Austin 2023
North America's best employee experience and digital workplace conference of the year — live in Austin May 10-12, 2023.
Having complete power also means that the BDL’s personality and temperament heavily influence the project dynamics. There have been cases where a BDL’s behavior was toxic. Project contributors have limited ability to modify the BDL’s behavior and impact.
The Linux project offers one recent example of how the BDL can be the problem in a BDL-managed project. In September 2018, BDL Linus Torvalds stepped away from the Linux project temporarily because he was, in his own words, a “really unpleasant person.” It’s good that he came to that personal revelation, but that was after years of trouble.
Related Article: 5 Tips for Deploying Open-Source Software
Is the End Near for BDLs?
Is the reign of the BDL coming to an end? Probably.
Open-source development that starts as a hobby by a single programmer is becoming less common. Instead, open-source projects have become corporate endeavors, with financial support from large technology companies, investors and foundations.
Corporations don’t like public drama. BDL-led projects are too tied to the BDL’s personality. What the BDL does and says has an impact on the project, no matter the context.
Corporations also need a neutral forum for arriving at consensus with competitors. The BDL model doesn’t provide that, because the BDL’s opinion trumps everyone else’s.
The increasing complexity of software means that software companies need to use the open-source process to create applications. IT departments rely on open source to meet the requirements of modern systems. The industry needs a collaborative environment to make open source a reality. The BDL model doesn’t fit that environment. It should be put to rest.
Learn how you can join our contributor community.