Minimum Viable Governance is Great, But Not Always Sufficient
By Jason Keirstead, OASIS Open board member
Bravo to GitHub! Any member or advocate of global open source communities must applaud the move by GitHub to open source a lightweight community governance structure. GitHub’s Minimum Viable Governance (MVG) model for free and open source software projects (FOSS) is a valuable resource to our community, addressing a very real pain point of open source innovators who are guiding projects with great potential but need an easy-to-implement governance structure.
The fact is, many open source projects get started with no thought to governance issues whatsoever. That can cripple a project down the road when the base of maintainers and contributors grows beyond one or two people. I personally hope MVG takes off and becomes ingrained as “le mode de vie” (i.e., the way of life) for open source projects far and wide, especially as an on-ramp for those who are just getting started.
The ‘Yes, And…’
In my experience, as an open source project grows, its governance landscape gets a little more challenging to maneuver. As great as MVG is, FOSS teams should consider future scenarios that might require a bit more from their governance approach than MVG is intended to deliver:
- Patents and IP Rights. MVG suggests a few options to choose from with regard to licencing and trademarks—ideal for when an open source project is small, because at this stage, let’s be honest, pulling in a legal team can be overwhelming and stifling. Ask most developers and they’ll tell you nothing sucks the wind out of a room of innovation-driven energy faster than a well-meaning team of lawyers!
Nevertheless, if you have any inkling at all that your project is going to grow and potentially attract involvement from additional people and entities, you need to give IP protection its due. In reality, many open source licenses are based on copyright laws that don’t protect your project contributors from patent claims as strongly as you may expect. To be sure, some open source licenses, such as the Apache license, offer projects explicit patent agreements to protect consumers. But others offer implicit agreements that may turn out to be tough to defend in court, and some offer nothing at all.
So beware: If your project has the potential to scale, you need to lay the groundwork to protect both your contributors and consumers, especially if corporate entities are or ever will be involved.
- The Path to Standardization. What will your project be when it grows up? As Stephen Covey popularized in the best-selling “7 Habits of Highly Successful People,” it’s best to “begin with the end in mind.” Having a vision of what you plan to achieve is important in framing your decision making; it’s also critical because we don’t have time machines to rectify the “if only we had …” regret. It’s impossible to go back in time and redo your work!
Do you think your software could one day be commercialized across a vendor ecosystem? Could it be used by organizations that operate within regulatory frameworks? Do you dream of your software project becoming an industry standard? If you have big ambitions for your project, you should strongly consider having a solid path to a de jure standards process.
In the case of open source projects, preparing for a standards-based path means choosing a governance approach from the outset that documents a level playing field approach and backs that up with rules-based mechanisms. Without said documentation, achieving de jure status down the road could be a large challenge. MVG’s consensus-based approach is an ideal and first choice for an open source project when just a few people are participating. However, as soon as commercial entities get involved, decision making can become heated, because organizations will inevitably have conflicting priorities and visions for how to proceed. What no one wants to see in this situation is a cage match where two factions or stakeholders enter and only one leaves. That’s where a second layer of rules-based, vendor-neutral decision making is invaluable.
- The Bus Factor. The bus factor is a real concern with a lot of open source projects; it refers (in perhaps too blunt and morbid terms) to how many individuals involved in your project can be hit by a bus and the project would still survive. Or, what if 90% of your maintainers all work for BigCo, and BigCo decides one day to withdraw from the project or hold the project ransom? And what if some brave champion comes along that has the ability and interest to do something with the neglected project? How do they get access to not only the code, but the project name, trademarks, web domains, and other important IP?
The key issue here is project continuity. We need to make sure that valuable open source projects have the foundation they need to live beyond any one person or corporate entity. MVG doesn’t really address this issue sufficiently.
The point is, if you are trying to build something that lasts and has the ability to scale, you probably want a larger governance structure around it than MVG provides. That’s the value provided by open source foundations like OASIS Open, on whose board I serve. (Others with which you are likely familiar include Apache Software Foundation, Cloud Native Computing Foundation, the Eclipse Foundation, the Mozilla Foundation, and Open Infrastructure Foundation.)
In the case of OASIS Open, its Open Projects governance model is like a hardened laptop—built to stand up to battle conditions. Going beyond the basics of MVG, the Open Projects program enables seamless collaboration with commercial interests, striking a smart balance between “the easy button” and the legal hoops required to provide protections to contributors and strong protection to the project itself. The Open Projects program also offers open source projects a governance process that is recognized by de jure international standards bodies, so if you choose to one day take your project down the path to standardization, you’ll be ready—no time machine needed.
If you’re launching an open source project, by all means, consider using GitHub’s MVG approach as your on-ramp. And when your project takes off, reach out to OASIS Open or another open source foundation to build something enduring, impactful and rewarding for all those who contribute.