If open source is about anything, it is about people working together to build something none of them could create alone. That makes governance and leadership central to the health of any project, even though they are often discussed as if they are secondary concerns. The Benevolent Dictator For Life (BDFL) model has become a familiar shorthand for successful projects led by strong individuals, but I have never found it a comfortable fit for how I believe communities should function or endure.
Leadership vs Authority
There is no question that the BDFL model can work. Many successful open source projects have benefited from a clear, decisive individual who provides direction, resolves disputes, and keeps progress moving when consensus becomes difficult or slow. In the early stages of a project especially, that kind of clarity can be invaluable. It prevents stagnation, cuts through endless debate, and gives contributors a sense of focus that might otherwise be missing.
But the effectiveness of the model in certain circumstances should not obscure its underlying weaknesses. It places the health of the project too closely in the hands of one person. That person becomes not only a source of direction but also a point of dependency, and over time it becomes easy to confuse the success of the project with the presence of the individual. What begins as helpful leadership can slowly become structural reliance.
The Hidden Cost of Single-Point Leadership
The difficulty with that arrangement is not immediately visible. It tends to reveal itself later, often at the moment the individual steps away. People retire, interests change, circumstances evolve, and no one remains in a role indefinitely. When a project has been built around a single authority, their departure can expose a lack of depth elsewhere in the community. What remains is not always a resilient structure, but a set of habits formed around waiting for decisions to be made elsewhere.
There is another cost that can emerge long before a leader leaves. A project led by a BDFL inevitably becomes closely aligned with that person's vision of the future. While this can provide consistency and stability, it can also create tension when the wider community begins to see different opportunities or challenges. Technology evolves, user expectations change, and new approaches emerge. Contributors may believe the project should embrace a new technology, adopt a different strategy, or rethink long-held assumptions. If the BDFL disagrees, the project can find itself constrained by the preferences of a single individual.
The conflict is not necessarily between people who want change and people who resist it. Quite often it is between competing visions for what is best for the project's future. Sometimes the community wishes to stay the course while the leader wants change. At other times the community sees opportunities that the leader does not wish to pursue. When authority ultimately rests with one person, those disagreements can become difficult to resolve. In the most extreme cases they lead to stagnation, resentment, or even a fork, as contributors seek a path that is no longer available within the existing leadership structure.
A community-led project is not immune from making poor decisions, but at least those decisions emerge from a broader conversation rather than the worldview of a single individual. The risk of getting the future wrong still exists; the difference is that responsibility for that future is shared.
Leadership as Empowerment, Not Control
This is why I have always been more interested in leadership than authority. Leadership, in the way I understand it, is not about standing in front of a community and directing its movement. It is about creating the conditions in which others can act with confidence, contribute meaningfully, and eventually lead themselves. A leader should make themselves less necessary over time, not more indispensable.
That requires a different kind of discipline. It means resisting the temptation to become the final decision-maker in every discussion, and instead investing in the people and processes that allow decisions to be made more widely. It means recognising that speed is not always the highest value, and that a slower consensus built on shared understanding can often be more durable than a faster decision imposed from above. Most importantly, it means accepting that leadership is measured not by how many people follow, but by how many people are capable of leading.
A Different Way of Seeing Leadership
Don’t walk in front of me I may not follow
Don’t walk behind me I may not lead
Walk beside me, and just be my friend.— often attributed to Albert Camus, though that attribution has never been definitively verified
Whether or not the attribution is correct, the sentiment captures something important about the kind of relationships that sustain healthy communities. It rejects both hierarchy and dependency. There is no command from the front and no obligation from behind. Instead, there is companionship, shared direction, and mutual respect.
That idea is much closer to how I believe open source projects should function. A leader should not exist to be followed in a strict sense, nor should they operate as a distant authority issuing instructions. They should walk alongside the community, helping to shape direction while also listening, learning, and adapting. In that sense, leadership becomes less about control and more about participation.
Leadership Without a Throne
Critics of the BDFL model are sometimes accused of wanting endless committees, consensus on every issue, or even a form of organisational anarchy. That is not my position at all. Open source projects need leadership. They need people who can articulate a vision, inspire others, make difficult decisions, and help a community navigate change.
What I question is the assumption that leadership requires permanent authority or an ultimate veto.
A leader is best when people barely know he exists,
when his work is done, his aim fulfilled, they will say:
we did it ourselves.– Lao Tzu
What resonates with me is the final line. The greatest achievement of a leader is not that people recognise their leadership. It is that people gain enough confidence, ownership, and belief in themselves that they feel they achieved success through their own efforts.
This is why I have always preferred a model based on vision and empowerment rather than authority and control. A leader should help a community understand where it is going and why. They should encourage participation, remove obstacles, and create an environment in which people feel able to contribute. Most importantly, they should recognise that the long-term health of a project depends not on the quality of a single leader but on the strength of the leadership culture that exists throughout the community.
Peers, Not Followers
The contrast with the Benevolent Dictator model is not simply a matter of structure, but of relationships. A BDFL model assumes followers. The model I prefer assumes peers. That distinction changes everything about how a community behaves. Followers wait for direction. Peers share responsibility. Followers look upward. Peers look outward and toward one another.
When people see themselves as peers rather than followers, they are more willing to challenge assumptions, propose new ideas, and take ownership of outcomes. They do not need permission to contribute because they already see themselves as stakeholders in the project's success. Leadership still exists, but it exists to encourage participation rather than demand obedience.
Building Resilient Communities
Open source communities built on peer relationships tend to be more resilient, even if they are sometimes slower to reach decisions. They distribute knowledge more widely, encourage initiative at multiple levels, and avoid the fragile dependency that comes from concentrating authority in a single place. They are harder to build, and they require more patience, but they are also far more likely to endure beyond the involvement of any one individual.
Such communities are not defined by the strength of a single leader. They are defined by the number of people who are willing and able to step forward when needed. Knowledge is shared, responsibility is distributed, and leadership becomes a characteristic of the community rather than a title held by an individual.
Leadership That Creates Leaders
None of this should be mistaken for an argument against leadership. Open source projects need leadership. They need people who can articulate a vision, inspire contributors, resolve conflicts, and help communities navigate change. What they do not need is a leader for life with the ultimate veto over the project's future.
The word benevolent is often used to soften the reality of the Benevolent Dictator for Life model, but it does not fundamentally change its nature. A dictator who listens carefully, acts thoughtfully, and genuinely wants the best for the project is still a dictator. The final authority remains concentrated in one person. The smile may be genuine, but the power structure remains unchanged.
That is ultimately why I do not find the BDFL model compelling. It solves certain problems efficiently, but it creates deeper structural dependencies in return. It ties the future of a project not only to one person's continued involvement, but also to one person's vision of what that future should be.
I would rather invest in a model of quieter leadership: leadership that guides rather than commands, influences rather than controls, and measures success not by the number of followers it attracts but by the number of leaders it creates. The goal should not be to build a project that succeeds because of one person, but to build a community that succeeds because many people share responsibility for its future.
That, for me, is what healthy leadership looks like in open source: not direction from the front, not control from above, but a shared journey in which people walk alongside one another and, when the work is done, can honestly say, "We did it ourselves.
