Three Pillars Of Open Source Governance - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
IT Leadership // IT Strategy
Commentary
1/13/2015
12:35 PM
Nathen Harvey
Nathen Harvey
Commentary
100%
0%

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.

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.

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 ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Charlie Babcock
100%
0%
Charlie Babcock,
User Rank: Author
1/13/2015 | 6:43:08 PM
Cheers for Chef and the Chef community
Well said, by a spokesman for one of the most successful open source communities in current operation, Chef.
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

News
How CIO Roles Will Change: The Future of Work
Jessica Davis, Senior Editor, Enterprise Apps,  7/1/2021
Commentary
A Strategy to Aid Underserved Communities and Fill Tech Jobs
Joao-Pierre S. Ruth, Senior Writer,  7/9/2021
Slideshows
10 Ways AI and ML Are Evolving
Lisa Morgan, Freelance Writer,  6/28/2021
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Slideshows
Flash Poll