Five Key Features of a Project Designed for Open Collaboration

There are many open source software projects out there today and any list of open source licenses alone shows you how much project diversity is out there. Just take a look at Github, Apache, Eclipse or The Linux Foundation and you’ll find thousands of developers collaborating on the software that literally runs the world.

But as venture capital investor Peter Levine pointed out in his recent TechCrunch article on the economics of open source, some are more likely to succeed and take off and endure over the long run than others. Many projects spin up and have a much shorter or less effective impact than the founders envisioned. Sometimes that’s ok. Not everyone is trying to be the next Red Hat. It all depends on the goal of the project.

At The Linux Foundation we’ve launched quite a few Collaborative Projects over the last couple years that expand our support of open source and collaborative development in different areas. Our projects typically start with members coming to us saying “we want to launch XYZ and make it like Linux, but we need help on how to do it.”

Some of those efforts have gone well; with others we’ve learned important lessons and have made course corrections. Either way, the underlying principles remain the same. We aim to bring together industry partners and facilitate the interaction necessary to create that new model for open source success that Levine mentioned: “an ecosystem of standardized open source components that are generally re-used and updated by the industry at-large.” Project participants then build their products and services on top of and around that solid platform. They’re becoming the de facto standards of today.

Over time, we have learned a lot about what tends to drive successful collaboration, or hinder it. A key success factor is what I’ll call “Open Governance”: where a project operates transparently, openly, collaboratively, and ethically. In the spirit of open, I thought I’d share some of our lessons learned and why this topic is so important. Hopefully this spurs discussion and might help others structure successful projects of their own. Some of these principles are based on what encourages positive community engagement; some are helpful in that they prevent ‘bad behavior’ that can arise when conflicting interests are involved.

Five Features of Open Governance

Open Governance is a term I use to refer to an architecture for the project’s organizational structure that encourages:

Open participation throughout the project: anyone should be able to participate and contribute. The Linux Foundation’s own measurements for success include community engagement and making high quality code available. This is easier said than done as some open source projects (many no longer around) have at times been lured into adopting onerous membership requirements, contribution agreements or IP policies that make it very difficult for developers to engage.

Open participation in the technical community is essential, but just as important is Board participation. Boards benefit when there are technical community members who have proven their value serving as Directors. The Board also benefits when there is  representation from multiple classes of membership – not just founding or ‘diamond’ level members. Governing committees or Boards should use common voting methodologies and ensure no single company involved establishes a controlling number of votes. The diversity of viewpoints that come from these approaches will certainly benefit a project in the long run and alert those in leadership positions to issues earlier.

To begin with, involve all potential participants in your project to develop bylaws, charters, policies, etc. Our members are sometimes surprised we form workstreams to create the key governance principles that are eventually drafted into bylaws. Some members ask us to “just send me the bylaws”. Often companies involved in forming a project ask us to just “send us bylaws so we can review them.” That’s not how we do things. We bring all the founding members together and have them discuss issues around business and technical leadership responsibilities, voting, membership requirements, contribution and IP policies. Engaging the founders for input early on encourages a diversity of opinions and helps form a reasonable consensus. Further, with a diverse group of founders you often get great feedback to identify and avoid issues future members may have.

Open technical meritocracy: the open source development model celebrates technical merit over pride of authorship.  Code is contributed for the express purpose of advancing technologies relevant to a project, effectively separating technology advancement from individual or commercial intent. The open source development and design methodology is increasingly the driving force for modern architectures, especially those reliant upon building block or ecosystem approaches.  As witnessed from the Linux community, the rapid iteration and broad visibility of community-driven activity can drive a superior rate of code velocity while the broad peer review process ensures pragmatic progress in the face of fast technology cycles.

The governance model should ensure there are no ‘closed door’ technical decisions. Instead the rationale and decision making on technical issues are done in a transparent way and visible to the community. This encourages technical contributors to offer solutions and establishes a fair, level playing field that all ideas, good and bad may be heard and decided upon by a group of peers. It’s a lot easier to make a bad decision for legitimate corporate reasons when the doors are closed. It is much more difficult for developers to look their peers in the eyes (while everyone is watching) and justify a technically inferior solution.

Open design: the design or architecture of the project should not be “pre set” by a founder or key participant dictating what the project’s code has to be. This encourages best of breed and evolution of the code with the needs of the community and users of the software.

Now that’s not to say a project should start with no code. Projects ideally will have a starting codebase to work from that will set an initial architecture. What’s important is that the initial architecture or design not be cemented by craftily worded Charters, Bylaws or other policies. Successful open source projects will live on and move forward into the future – we have no idea how they may need to evolve to meet the needs of users 10, 20 or 100 years from now.

To achieve this end, many projects have set up a technical board and a business board. At the Linux Foundation we use the terms Board and Technical Steering Committee (TSC) to differentiate between entity governance (Board) and technical governance (TSC). Typically the Board has no say in technical issues, individual project scope or technical direction as long as they remain within the scope of the open source project. Structuring your bylaws and policies to ensure the proper powers and decisions are relegated to the proper governing body will help to ensure an open design endures.

Open Source License: the license choice for an open source project is an important decision to make as the license sets the ground rules for how users, companies and the ecosystem will contribute to the code base. Projects should use an approved open source license by the Open Source Initiative or a free software license approved by the Free Software Foundation.

Yes, your counsel may be good enough to come up with a new open source license, but think about all the lawyers in your potential ecosystem who will be asked to review, understand, accept and recommend whether their companies participate. It’s far easier to select a license others are already familiar with that’s good enough and carries the key principles your project needs.

The license choice can also maximize or minimize a project’s license compatibility with the large ecosystem of libraries and third party components that have already been released under the open source licenses. There can be a huge developer benefit to having access to a large library of existing code. The license should encourage reuse and maximize incentives to share contributions without deterring developers, companies or users from participating. There is no one license that works for all projects and situations. The license choice needs to be context-aware and align to the long term needs of the project and community involved.

Open, level playing field for Intellectual Property (IP): the IP Policy needs to ensure all participants are operating on a level playing field. Our counsel Andy Updegrove posted a very interesting blog post on FRAND patent licensing and the impact on open source software projects. There are IP issues and concerns that are often not all covered by the license choice of the project. Trademark and patent rights can unfairly shift the power of actors within a community. At the Linux Foundation we require the projects to own the trademarks, which can mean that projects using existing marks may need a company to assign the mark to the project. There are a number of options in existence today for dealing with patents through the terms of a license, a patent commons, Open Invention Network or other ‘defense fund’ models that I expect we’ll hopefully see formalized in the near future.

A ‘best practice’ is to engage your legal counsel early on. On some projects we’ve seen brilliant experts driving toward launching a project, but their legal counsel has not yet been involved. Then the final plan is presented to legal for approval and they take weeks to catch up. The issue is never that something in the documents is wrong; more often the issue is the lawyers were left out of the process of discussion and debate. Those discussions around the formation are also beneficial to your counsel and helps them understand WHY the bylaws, license choice or policies are a certain way. This often enables a much faster path to agreement and buy-in. It also provides your counsel and opportunity to clarify points or resolve issues they see early on.

What if I don’t?

If there’s one thing you can learn from the 20+ years of community experience with Linux, it’s that what you establish today will have to adapt, evolve and be open to changes in the future, which you cannot foresee with any certainty. Projects evolve because people move into different jobs, companies change direction and investments, the technology from other ecosystems demand changes. As an example, who would have known all the processors Linux would need to support back in 1993? Today we enjoy the use of Android smartphones and view images from Mars rovers because of open governance decisions that the Linux developer community established decades ago.

This often also leads to “if it’s really an issue, we can just fix it later.” That may be true for technical decisions, but governance is a different matter. An open source projects’ governance model is often like dating – you typically have one shot at making a connection. Developers and companies need to ensure they trust the project and people involved. Projects often only get one chance to make a good first impression. Build open governance into your project the first time; you may never get that second chance.

Michael Dolan is an attorney and Director of Member Services at The Linux Foundation where he works with the legal community and collaborative projects.