What are the benefits of having a benevolent dictator for life (BDFL) on OSS?

I've always seen the BDFL model as halfway between a traditional open-source project structure and a traditional corporate project structure. You have the openness, transparency, and general culture of OSS, but with a single strong project manager to make high-level decisions and direct the overall effort.

You can see many of the advantages just by breaking down the title itself:

• Benevolent - a mutual trust that this person will act in the project's best interest
• Dictator - this person is the singular, ultimate authority
• For Life - this person intends to lead the project for the long term, not just until something nicer comes along

A BDFL is highly invested in the project, typically the original creator. Their own name and professional reputation are often inseparable from that of the project. Unlike a corporate manager, users can find it easier to trust their leadership since the BDFL has a highly vested interest in the success and longevity of the project. Both corporate projects and OSS projects can end up with a revolving door of leadership, which stalls progress and frustrates users. A BDFL generally holds that position for a long period of time (thus the "for life"), which adds a degree of stability to the project. It also allows leadership to develop and stick to a cohesive long-term vision instead of a series of short-lived leaders constantly changing plans and directions.

Frequently, a BDFL is also the undisputed subject matter expert and central authority for that particular project/technology. Corporate managers can run a project without a deep understanding of the technology or its history, leading to decisions that frustrate developers/users. Many OSS projects have a number of people in equally-powerful leadership roles, leaving room for disagreement and confusion. If you have a question about where Python is heading and Guido van Rossum answers your question, then you can be confident that the answer is authoritative. BDFL-run projects tend to attract fewer forks for this reason. Any fork with only minor changes would seem like a "lesser" project without the BDFL's involvement. This helps prevent a community from splintering into multiple groups that are each too small to be effective.