Three Pillars Of Open Source Governance

As more commercial businesses spring up around open source software, these guidelines will ensure communities stay vibrant and open.

Nathen Harvey, Vice President of Community Development, Chef

January 13, 2015

5 Min Read

Open source software has morphed from its underground DIY roots to become a common tool that runs essential parts of many businesses. In turn, commercial companies have sprung up around open source projects. These companies make money offering updates, support, and services.

The intersection of open source and commercial interests raises questions about authority, authenticity, and culture.

Is the project driven by the commercial sponsor or outside contributors? Will commercial interests trump the wishes of the community? How and where do you draw lines between a commercial entity and the open source community?

These issues are real. As open source becomes more essential to everyone's hardware and software stacks, thoughtful and dedicated action is required.

At Chef, we believe three guiding principles can help address these questions while keeping both commercial organizations and the open source community thriving.

Besides benefiting the community, these principles can also help facilitate even more enterprise adoption of open source software.

1. Transparency is key
It is imperative for open source communities and the host companies that are built around them and that work with them be transparent.

Communities worry that a company will step on its toes, while a company may fear backlash from the community. Transparency solves these woes.

When issues arise, discuss them. When remedies need to be taken, publicize those actions. Blogs, IRC, mailing lists, discussion forums, and collaborative source code sharing sites such as GitHub are great places for transparent discussions.

2. Set governance parameters
With a commitment to transparency, community leaders can build policies and codes of conduct to help govern the community. It's best to collaborate in the same way the community is used to working. If the community proposes software changes through RFCs, use RFCs when proposing changes to the community itself.

Allow the community to iterate on the RFC -- you can use meetings in IRC, allow changes to be proposed via GitHub, or hold a Google Hangout. Use whatever medium your community prefers to convene in -- the important thing is that you convene.

[Register now for Interop Las Vegas 2015. Get expert insight from peers and pros in infrastructure, security, cloud, mobility, and more.]

There are a few commonly used governance guidelines in open source.

One is the code of conduct or community guidelines. Every community member is expected to follow these codes or guidelines when representing the project. The guidelines must outline acceptable behavior and should describe a procedure for handling incidents, such as when a community member acts inappropriately.

Next is a governance policy, which describes the management of the roadmap, structure, policies, and other pertinent details of the project. A governance policy may include calls for open participation, description of operations, and procedures for handling grievances.

Finally, the maintenance policy describes how decisions about the project are made. It may include the process by which proposed software updates are reviewed, agreed, and merged into the project.

3. Make every person successful
All constituents in an open source community have a significant role to play. It's important to make them successful in their roles and to recognize different sources of value.

There are a variety of roles in the realm of open source. They include:

  • Community participants -- A participant uses the software, reads the mailing list, and interacts with others in the community. Participants must feel welcome and should be able to find help to succeed with the software.

  • Contributors -- People who contribute code to the project are the lifeblood of a community. Write contribution guidelines that are clear and easy to find, review contributions regularly, and give direct, constructive feedback on each proposed change. Contributing code to a project should be easy.

  • Enterprise customers -- Enterprises are adopting more open source technologies, but their developers are often restricted from contributing code back to a project. However, these customers still give something important back to the community -- new use--cases to solve, new challenges to address, and new ideas.

  • Company employees -- Some of the most passionate and active community members may also be employees of the sponsoring company. These individuals generally participate in the community because they want to, not because their roles at the company compel them to do so. With a few exceptions, employees’ job descriptions and performance reviews are driven by contributions to the company, not to the open source community. Allowing employees time and resources to work on community projects without directing the exact nature of the participation helps keep the open source community true to its purpose.

  • Community advocates -- These are folks who emerge as leaders within the community and who want to have a dedicated role. When developing your code of conduct or community guidelines, identify specific areas you want community advocates to oversee -- such as the mailing list, IRC, Stack Exchange, or other forums. Advocates must encourage healthy participation and deal with inappropriate behavior. The community holds itself accountable.

Open source communities that practice transparency, encourage active participation, and recognize the contributions of all constituents are more likely to thrive, iterate, and strengthen the project.

Apply now for the 2015 InformationWeek Elite 100, which recognizes the most innovative users of technology to advance a company's business goals. Winners will be recognized at the InformationWeek Conference, April 27-28, 2015, at the Mandalay Bay in Las Vegas. Application period ends Jan. 16, 2015.

About the Author(s)

Nathen Harvey

Vice President of Community Development, Chef

As Vice President of Community Development at Chef, Nathen helps the community whip up an awesome ecosystem built around the Chef framework. He also spends much of his time helping people learn about the practices, processes, and technologies that support DevOps, Continuous Delivery, and web-scale IT. Prior to joining Chef, Nathen spent a number of years managing operations and infrastructure for a number of web applications. He is a co-host of the Food Fight Show, a podcast about Chef and DevOps. Working with, and as a part of, the Chef community, he has been spreading the word about DevOps for quite a while.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights