The power of consensus: Building better open source communities
By Karsten Wade (@quaid)
Making decisions by consensus in an open source community is rarely smooth, but it’s essential for short- and long-term success.
Even when open source governance focuses on membership and voting, consensus is always there, like oxygen in the air. People participate by consent—they can walk away if they don’t like a decision. Votes usually follow socialization, not directives from leadership. Most decisions are already in agreement before a vote is even called.
Open source communities find consent through various methods—small group chats, formal processes, rough consensus—but the principle remains: address concerns before moving forward. Majority rule creates losers, while consensus focuses on resolving blockers. In consensus, blockers are voiced by those willing to walk away, forcing the community to collaboratively resolve the issue, not leave dissenters behind.
I write this as an independent expert on open collaboration and open source. For more than 20 years, I’ve helped shape governance, evolve practices, and achieve consensus in many open source communities.
Read more: The Open Source AI definition: Why we need it
Currently, some vocal members in the open source ecosystem (Sam Johnston, Amanda Brock, and Steve Pousty are recent examples) disagree with a new definition from the OSI (RC2 as of Oct 22). I’ve proposed resolving the blockers by setting them aside for later discussion after releasing version 1.0 of the definition. I believe it’s a good-enough starting point, though it’s unclear if others outside of the open source ecosystem share this view.
Rather than diving into the details of these blockers, my focus here is on the importance of consensus in open source and how it should guide the OSI’s process.
Co-design and consensus
The OSI’s use of co-design for the Open Source AI Definition is reasonable. While my experience with co-design is limited, I understand its core goal is ensuring all voices are heard and treated equally. It builds trust by letting people speak freely, without fear of being shut down or misunderstood by those outside their community.
As part of the Open Source ecosystem, I trust that co-design facilitators are treating all voices equally. That said, rough consensus, as practiced by the Internet Engineering Task Force (IETF), Apache projects, etc. remains the standard decision-making method in open source. The OSI’s process must respect this.
In rough consensus, even one hard blocker demands resolution. The focus shifts to understanding and resolving concerns, not steamrolling dissent. In open source, a few dozen dissenting voices are a big deal—potentially signaling serious issues.
The path forward
In consensus decision-making, when faced with blockers, you either extend the deadline to keep working or move forward with what’s agreed upon, setting blockers aside for future discussion. Move-forward is the approach I recommend for the Open Source AI Definition.
This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.