An experienced open source expert offers some tips for how to succeed with open source software, starting with an open source project office.

Guest Commentary, Guest Commentary

March 12, 2018

5 Min Read

The recent growth of open source has been phenomenal; the latest GitHub Octoverse survey reports the GitHub community reached 24 million developers working across 67 million repositories. Adoption of open source has also grown rapidly with studies showing that 65% of companies are using and contributing to open source. However, many decision makers in those organizations using and contributing to open source do not fully understand how it works. The collaborative development model utilized in open source is different from the closed, proprietary models many individuals are used to, requiring a change in thinking.

An ideal starting place is creating a formal open source program office, which is a best practice pioneered by Google and Facebook and can support a company’s open source strategy. Such an office helps explain to employees how open source works and its benefits, while providing supporting functions such as training, auditing, defining policies, developer relations and legal guidance. Although the office should be customized to a specific organization’s needs, there are still some standard steps everyone will go through.

Find a leader. It is essential that the person leading an open source program has a good understanding of how open source works, is familiar with the organization’s business and goals, and has some technical background. The TODO Group maintains sample job descriptions that may be helpful in finding candidates.

Define your operations. Next, determine operational aspects of the open source program, including staffing, budget, and tools. The office shouldn’t be too small or too large, which risks centralizing processes, setting up a bottleneck and alienating staff. It should provide guidance and support to users of and contributors to open source within the organization, but leave room to make decisions.

Seek feedback and buy-in. Involve all levels of the organization in the planning and setup of the open source program. This will improve the final result and increase support for the office within the overall organization.

Decide on the program structure. There are different ways to fit a program office into an existing structure. Companies with large IP portfolios may place the office within the legal department. Engineering-driven organizations may place the office in an engineering department, especially if the focus of the office is to improve developer productivity. Others may want the office to be within the marketing department to support sales of open source-based products.

Companies like Google and Facebook use a centralized open source program office that fixes processes and brings in tools to automate tasks. Netflix uses a cross-functional working group running an internal mailing list for discussions and meeting informally to help resolve open source issues. Microsoft has a program team enabling engineers to make local decisions about their projects. For inspiration, the TODO Group offers open source program case studies.

Determine management roles. At the top of an open source program office should be the program manager, ideally an executive-level position with authority to adopt necessary tools and processes. This does not have to be a single person, and could instead be a committee.

Legal should be involved, as they hold the responsibility for ensuring a company can consume code internally and contribute back to projects with acceptable terms. Beyond legal, most open source offices have a cross-disciplinary group of employees working to ensure open source compliance, typically consisting of representatives from engineering and product teams, legal counsel, and the compliance officer.

Finally, open source program offices should consider having someone to focus on developer relations and evangelism to create enthusiasm.

Set policies and processes. The final step is establishing standardized policies and processes for implementing an open source strategy. Policies, which should require minimal oversight, lay out the requirements and rules for working with open source across the organization. Employees should be able to question policies and provide recommendations for improving them. Keep in mind that open source and technology evolve rapidly, so policies and processes will also need to adapt to remain relevant.

Numerous organizations active in open source, such as Google, publish their policies publicly, which can be a good starting place. Some of the areas that will need to be addressed when formulating these policies include:

  • How to accept external contributions to an organization’s open source projects

  • How to prepare for open source releases

  • How approvals are received

  • How developers can use open source code found in code repositories

  • Procedures and rules explaining open source code consumption

  • How incoming code is catalogued so others know it is being used

  • How the organization can grow a community of like-minded external developers

  • Rules that help determine when code should be released as open source or kept as intellectual property

Once policies are established, organizations should consider how to communicate them to employees. Documentation and training can help. Keeping policies simple to follow and easy to access will encourage employees to learn and follow them. TODO Group offers free examples of open source policies.

There are many resources to help on the journey. A great starting place are the free Linux Foundation and TODO Group Open Source Guides for the Enterprise.

Chris Aniszczyk brings more than 15 years of experience to his roles as COO of the Cloud Native Computing Foundation and The Linux Foundation’s Vice President of Developer Programs. He focuses on working with the developer community to advance open source projects at scale. Previously Chris served as Twitter’s head of open source, where he led a team of developer advocates and was responsible for Twitter’s open source engineering, strategy, and culture. He has also contributed to Gentoo, Fedora Linux and served on the Eclipse Foundation’s Board of Directors and the Java Community Process Executive Committee. An engineer by trade, Chris brings a passion for both open source and community development to the organization.

About the Author(s)

Guest Commentary

Guest Commentary

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT professionals in a meaningful way. We publish Guest Commentaries from IT practitioners, industry analysts, technology evangelists, and researchers in the field. We are focusing on four main topics: cloud computing; DevOps; data and analytics; and IT leadership and career development. We aim to offer objective, practical advice to our audience on those topics from people who have deep experience in these topics and know the ropes. Guest Commentaries must be vendor neutral. We don't publish articles that promote the writer's company or product.

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

You May Also Like


More Insights