The open source governance model as a reference for leading engineering teams

Technology leadership is at a breaking point. The traditional command-and-control model, born in the industrial era, is cracking under the adaptive complexity of engineering teams. Rajeev Peshawaria opens his book Open Source Leadership with a pointed provocation:

“Leadership can no longer be about command and control. It must be about influence and inspiration.”

If projects like Linux, Kubernetes, and Apache were built by distributed communities with open governance and without rigid hierarchical structures, why do corporate engineering leaders still cling to old models?

The crisis of the traditional model: what organizational science shows us

Organizational science has already accumulated evidence against command-and-control.

• Psychological Safety: Amy Edmondson showed in her seminal study that teams with higher psychological safety share mistakes, learn faster, and perform better (PDF – MIT). Recent studies reinforce this effect as a buffer against burnout (PMC 2024), and there is already work linking psychological safety to the software engineering environment (arXiv 2025).

• Hackman and team effectiveness: Richard Hackman proposed that high-performing teams depend on five conditions: clear purpose, well-defined boundaries, consistent norms and roles, organizational support, and competent coaching (Hackman – What Makes for a Great Team).

These findings already show that rigid environments, based on fear or hierarchy alone, destroy performance. This is where open source logic comes in as a viable alternative.

Open source governance: mechanisms that work

OSS governance survives at global scale because it created institutional coordination mechanisms:

• Radical transparency: issues, PRs, and decisions are public. As Peshawaria says:

  “In a transparent world, secrecy is the enemy of trust. Leadership today is about being open, even when it is uncomfortable.” This visibility accelerates learning and collective trust.

• Technical meritocracy (broadened):

  “Open source leadership is about democratizing power, but not equalizing it. Influence flows to those who add the most value.” Studies show that leadership in OSS emerges not only from technical contribution but also from communication skills and community influence (arXiv – Follow the Leader, 2022). In other words, technical merit matters, but reputation and social capital coexist.

• Autonomy with accountability: the fork symbolizes maximum freedom but carries the cost of maintenance. This mechanism regulates autonomy. In companies, the parallel is to allow squads to explore alternatives, as long as they own outcome and integration metrics.

These mechanisms echo Hackman’s conditions: purpose, norms, boundaries, and support. OSS applies them in a radical way; corporations can use them as an adapted reference.

How I think: a CTO and maintainer’s critical reading

My experience connects both worlds: OSS and corporate management.

• Documented decisions: in communities, PRs function as a public court. At Buser and in OSS projects, adopting open RFCs helped me create legitimacy and institutional memory.
• Fluid leadership: in OSS, leadership is emergent and temporary. In corporate settings, adopting this flow — specialists taking on roles according to context — works better than fixing authority. Peshawaria sums it up:

  “The open source world thrives because leadership is temporary, emergent, and conditional upon contribution.”

• Burnout and centralization: both in OSS and in corporations, when a few people concentrate critical responsibilities, the result is exhaustion. The path is always to distribute leadership.

OSS is a mirror: it shows that teams can function without rigid hierarchy, as long as they have purpose, transparency mechanisms, and healthy meritocracy.

Conclusion

Open source is not romanticism; it is the largest social laboratory of technology governance in history. If volunteer communities created systems that sustain the internet, there is no excuse for corporate teams to remain stuck in the 1920 model.

The central lesson is clear: engineering leadership is not HR resource control, but building systems where autonomy, purpose, and accountability can flourish.

This is the reference. The rest is an illusion of control.

External references cited

• Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams
• Ma, J. et al. (2024). The impact of psychological safety on employees’ well-being and performance
• Hackman, J. (2004). What Makes for a Great Team
• Maltby, A. et al. (2022). Follow the Leader: Technical and Inspirational Leadership in OSS
• Edmondson, A. et al. (2025). Psychological Safety in Software Engineering Teams