Three Pillars Of Open Source Governance - InformationWeek
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 the Community Director 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 ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
dimitar1
50%
50%
dimitar1,
User Rank: Apprentice
3/15/2015 | 9:54:25 PM
The role of leaders in OS communities
How are leaders in OS communities different from leadres in a regular "closed" organization ? In terms of their profile, motivaiton, their tasks and behavior ?
nathenharvey
100%
0%
nathenharvey,
User Rank: Apprentice
1/16/2015 | 10:01:55 PM
Thank you
Thank you for the positive feedback and comments!

Trust and transparency go hand-in-hand; commercial entities that sponsor open source projects must trust the contributors to that project and vice versa. Trust will be gained by doing what you say over and over again and minimizing surprises. Disagreements are inevitable, but if two key things are done throughout the decision making process – using data to inform the decision, and making the decision itself in the open – it's much easier to discuss and resolve the disagreements.

Sometimes there's a question of which came first, the company or the open source project? Chef, for example, was an open source project before the company was founded. Docker, on the other hand, is an open source project that was created by an existing company. So the question of the community's attitude towards the sponsoring company can have a variety of responses. No matter the situation, successful collaboration requires trust and transparency. The company may focus it's investments on features that bring revenue while simultaneously encouraging the community and providing time for its own engineers to work on community-driven features. Collaboration is key to the long-term success of the symbiotic relationship.
Drew Conry-Murray
100%
0%
Drew Conry-Murray,
User Rank: Ninja
1/14/2015 | 1:52:16 PM
Re: Three Pillars Of Open Source Governance
I'm curious to hear from the community about attitudes toward sponsoring companies. When a for-profit business springs up around an open source project, does the community see it as a sign that the project has achieved a kind of milestone of acceptance, or is there some wariness about whose priorities get preference? Maybe a mix of both feelings?
zerox203
100%
0%
zerox203,
User Rank: Ninja
1/13/2015 | 11:02:52 PM
Re: Three Pillars Of Open Source Governance
Thanks for this, Nathen. My immediate reaction was: "These seem like pretty common-sense points when it comes to Open Source." The more I thought about it as a I read, though, the more I realized that these points take on a new meaning when you scale them up to the enterprise level. What would be a simple faux pas for an indepedent user can be a huge misstep for an Enterprise, and it takes that much more effort to make sure your intentions are understood and that they come off as genuine. That goes double if we're talking about Enterprises that may be breaking into Open Source for the first time (either as a customer or as a sponsor). These are points that are worth repeating and re-evaluating in the face of a new wave of large-scale open source projects and ever-changing enterprise needs.

One thing I couldn't stress enough is to respect that boundry between commercial and open-source.  The tip you gave about not stepping on the existing community's toes rings very true, and many would be surprised just how much and how quickly this can damage a project. Know your audience. These are smart, informed people who know their project, and more often than not, know their way around corporate politics. You can't pull a fast one on them, and even an unintentional lack of transparency can be interpreted very harshly. They'll know when something smells bad right away, and unlike your own employees, they have no incentive to stick around, and no reason not to tell others about everything you're doing wrong. I'd add that, too - accept there are some limits on how much control you'll have over things.
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.
How Enterprises Are Attacking the IT Security Enterprise
How Enterprises Are Attacking the IT Security Enterprise
To learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
Register for InformationWeek Newsletters
White Papers
Current Issue
Top IT Trends to Watch in Financial Services
IT pros at banks, investment houses, insurance companies, and other financial services organizations are focused on a range of issues, from peer-to-peer lending to cybersecurity to performance, agility, and compliance. It all matters.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of November 6, 2016. We'll be talking with the InformationWeek.com editors and correspondents who brought you the top stories of the week to get the "story behind the story."
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Flash Poll