BDFL considered (potentially) harmful
In a mature open-source project, the power of a BDFL should be moral — not proprietary.
Your code may be open-source, but what about your project?
Is your software project’s Benevolent Dictator For Life really benevolent?
“Yes” is a fine answer.
“It doesn’t matter that much” is a better answer.
Many open-source software projects have a BDFL, typically one of the project founders. In a healthy project, that authority is nearly exclusively moral authority. There is little or no real legal or contractual authority resting with the title holder.
Moral authority is important. It allows the BDFL to resolve disputes, and a healthy project needs one or more persons with that kind of authority. What’s vital is that the authority can be challenged, and, if not exercised on behalf of the community, lost. The fact that moral authority can be lost is the best insurance it will be well-used.
Most commerce operates under a different model of authority, usually the legal rights of ownership. Ownership of land, improvements, copyrights, patents and trademarks. That is proprietary authority.
Open-source software code is defined by the license. The code is GPL, or it’s not; it’s BSD/MIT/X-Windows or it’s not. Odds are that if you’ve invested a lot of time in working on a body of open-source code, you've made an effort to check out the license. You know what it is, and you've given some thought to the strengths and limitations of that license.
That covers the code, but what about the project that fosters the code? What about the basis of authority in that project?
For code, it’s the license. For the project, it’s the trademarks and the copyrights. Someone — some person or legal entity — owns the trademarks for the project name. Some person or entity owns the registrations for the domain name. And, the person or entity that owns the copyright on the code has control over the future licensing of the code. The value of trademarks potentially dwarf the value of the code.
A concrete example: last year the Plone Foundation did a valuation of the code that makes up the Plone Content Management System. A reasonably defensible valuation, using the kind of methods that accountants use every day, arrived at roughly three million USD. That’s basically an estimate of how much you’d need to pay to reproduce the code base.
If you’ve any familiarity with the Plone project, it’s probably obvious to you that the project as an economic enterprise is worth more. A lot more. Hundreds of times more. Smart people and companies world-wide make a living selling solutions marketed under the Plone brand.
I’ll bet that the same thing is true of your open-source project.
So, you did due-diligence on code licensing. Did you spend some time investigating how the project’s intellectual property is held?
Take a moment. Do a search to determine ownership of your project’s trademarks and copyrights. Do a whois on the domain names associated with the project.
Ideally, you’ll find that the founders of your project transferred the trademarks and copyrights to a well-organized, transparently managed, public-benefit foundation. BDFLs like Guido van Rossum (Python), Larry Wall (Perl), and Alex Limi and Alan Runyan (Plone) earned their “benevolent” titles with great code, good leadership, and by irrevocably conveying key intellectual property rights to foundations that limited their authority. Their authority in their projects is largely moral. BDFL in these cases translates to “dictator for life — so long as benevolent.”
If that’s not what you find, it’s time to start asking questions. Is the authority of your BDFL proprietary? You may trust your BDFL, but do you trust all his or her business associates and heirs? Do you trust that your BDFL will never come under personal, financial or legal pressure that might change their commitments? Are you willing to stake your livelihood on it? Is BDFL translating to “Dictator for life — benevolent or not?”
If you’re like me, the open-source project you work with is the center of a big investment of your business time and energy. If your ability to market and explain your work is based on a trademark license that is “revocable at any time, and subject to changes in policy” by your BDFL, it’s time to start pushing for some better answers. You may be too dependent on the benevolence of a BDFL, and while the code you work on may be open-source, the project might not meet the same test.