Let’s start with the end goal first, and then explain how to get there. Your goal is to detail your open source strategy in a document that everyone from engineering and legal, to marketing and the C-suite can reference. This strategy document will help your team understand the business objectives behind your open source program, ensure better decision-making, and minimize risks.

“At Salesforce, we have internal documents that we circulate to our engineering team, providing strategic guidance and encouragement around open source. These encourage the creation and use of open source, letting them know in no uncertain terms that the strategic leaders at the company are fully behind it. Additionally, if there are certain kinds of licenses we don’t want engineers using, or other open source guidelines for them, our internal documents need to be explicit.” – Ian Varley, Software Architect at Salesforce.

• At a minimum, the document should: Explain your company’s approach to open source and the purpose behind the document. What does success look like for your company and what’s the role of open source in achieving that?

“In Autodesk’s case, the reason behind our new open source approach was to make a move to cloud technologies because of how we’re shifting our product focus to integrate even more closely in a cloud environment. The realization follows that if you go to cloud, basically all of that’s built on open source, so you’ve got to ramp up your open source strategy.” – Guy Martin, director of Open at Autodesk (Open@ADSK).

• Specify how you want developers to consume open source code: What if code comes into one of your products from a project with a different licensing setup? What acceptance, rejection, and exception policies should developers follow? What is your organization’s overall stance toward open source development? A good strategy document provides explicit answers to these kinds of questions.
• Specify how you want developers to contribute code to open source projects, and identify projects that are critical to your business strategy. (And encourage them to contribute!) What if a developer wants to contribute code from one open source project to the one you are working on but the two projects have different licenses? How can your contributions to open source serve a virtuous cycle, so that your projects benefit from contributions in turn? These considerations are part of defining strategic contributions.

“If you are relying on an open source project heavily for your product and you don’t have a seat at the table in terms of leadership and strategy for that project, your business is at risk.” – Guy Martin, Autodesk.

• Provide guidelines for making new decisions, and encourage program buy-in and commitment: Should business governance of open source be separated from technical governance? How can you make employees champions for open source? A good strategy document provides answers and should also clarify your organization’s overall stance toward developing with and around open source.
• Align your business objectives and management directives: Which types of open source projects directly align with your business goals?
• Supply guidelines for licenses, charter documents and policies: How are APIs documented? Have you laid out a Contributor Licensing Agreement that everyone can use? Have you picked the right license for your project? Your strategy document should be specific about licensing practices and APIs.
• Lay out a usage policy and trademark that fits your code and concepts: Branding an open source project properly is as important as branding any invention, and there should be no questions about usage policies.
• Provide specifics on open source best practices: Successful open source projects have rich developer communities and are often productized in commercial products that profit businesses. Which specific practices can best foster this kind of sustainable ecosystem?
• Answer questions as they evolve over time. A good open source policy document should include a FAQ, and answers to common questions should be provided continuously in the FAQ over time.

“FAQs are highly tuned to the questions users and developers actually ask — as opposed to the questions you might have expected them to ask, and therefore, a well-maintained FAQ tends to give those who consult it exactly what they’re looking for. Good FAQs are not written, they are grown. They are by definition reactive documents, evolving over time in response to the questions people ask.”

Karl Fogel, Producing Open Source Software

The first step in crafting an open source strategy is to decide who should be involved in setting the strategy. This means not only deciding which internal business partners should be involved but deciding whether external strategic help and resources should be sought.

External Resources

There are many external resources that can help you flesh out your open source strategy, and the good news is that many of them are free. For example, Black Duck consults with thousands of businesses on setting open source strategies and offers guides and tutorials on the topic. The Linux Foundation offers extensive educational resources that can help you usher in the right strategy, and books like Best Practices for Commercial Use of Open Source Software can provide guidance.

The TODO (Talk Openly Develop Openly) Group, stewarded by The Linux Foundation, is also a good resource for member companies that want to collaborate on practices and policies for running open source projects and programs.

The Open Source Guide produced by GitHub also contains many resources on helping you build or contribute to an open source community.

Google recently open sourced its open source policy documentation and it can serve as a create template to create your own internal policies.

InnerSource Commons, founded by PayPal, also specializes in helping companies pursue open source principles and practices as well as exchange ideas for internal, proprietary software and infrastructure development. You can find the group’s GitHub repositories here, and a free

Another excellent resource for open source strategy is a blog called Changelog. It includes a podcast that covers a lot of different open source topics, called “Request for Commits.” The podcast tackles everything from the human side of creating open source software to questions about business models and strategy.

Note that many companies inside and outside the technology industry have very sophisticated open source programs. You can, and should, learn from them. The way they approach open source differs according to their own needs, but you can choose and adapt the practices and strategies that fit your business best. The TODO Group at The Linux Foundation was created to bring these companies together to share and evolve best practices. TODO also offers a set of free open source policies and templates on GitHub that you can use and contribute to.

General Electric might not be the first company that you think of when it comes to moving the open source needle, but GE is a powerful player in open source. GE Software has an “Industrial Dojo” – run in collaboration with the Cloud Foundry Foundation – to strengthen its efforts to solve the world’s biggest industrial challenges. GE derives benefits from the partners it works with in these efforts, and vice versa.

Among other organizations that have rolled out professional, in-house programs focused on advancing open source and commercializing tools, Netflix is a true standout. It is well worth visiting visit the company’s Open Source Software Center. Netflix has contributed many useful tools and applications to the open source community, ranging from machine learning and orchestration applications to utilities that run on its platform, many of which have been tested and hardened at scale. Netflix, in turn, gets contributions that help its platform run more efficiently, and its open source endeavors have opened doors to various partnerships.

Internal Resources

While these types of external resources can provide critical guidance and serve as a benchmark for your own strategy, internal collaboration is key in setting your open source business strategy. Your open source strategy should be tailored to your own unique business model, and the people within your own company are the best source of information. Additionally, you need to include all the stakeholders to reach consensus to ensure that everyone is on the same page and invested in seeing the efforts succeed. For example, it is important to involve executive leadership in the collaborative process.

Creation of an open source program can be invaluable at this point. The TODO Group’s open source guide titled Creating an Open Source Program states: “By creating an open source program office, businesses can enable, streamline and organize the use of open source in ways that tie it directly to a company’s long-term business plans. An open source program office is designed to be the center of the universe for a company’s open source operations and structure, helping to bring all the needed components together.”

An open source program office can help determine policies for code use, distribution, selection, auditing, and more. It can also provide guidance for training developers, ensuring legal compliance, and building community engagement. According to the guide, “The office can also provide advocacy and communications about all things open source inside and outside the company.”

“The only way you get hearts and minds (to advance your open source strategy) is to find the people in the individual teams that are willing to be proactive.” – Guy Martin, director of Open at  Autodesk (Open@ADSK).

When choosing internal staffers to help set strategy, remember that it is critical to involve people who are qualified to supply business and legal governance of projects as well as people who can supply technical governance. For example, an employee with technical skills may have an understanding of current open source practices and might be qualified to set policies such as Inbound Contribution Guidelines, while a person with business credentials might be more qualified to set policies regarding trademarks. Conversely, an employee with legal qualifications is best for defining licensing policies. And, of course, it is essential to identify stakeholders who have true passion for open source. Considerations for open source program office structure and discussion of the various management roles are detailed in the open source guide mentioned previously.

How can you engage all of your stakeholders? Start by talking and, crucially, listening to what’s working and what isn’t. The way you engage will depend on what works for your company and its existing culture. But it always pays to do the research before you dive into the strategy.

When Guy Martin first started as the open source director at Autodesk, he asked his boss for two lists: “I said, I’d like a list of people who believe in what you’re trying to do with (open source) and why you hired me in this initiative. And I want a list of people who either flat-out don’t believe it’s going to work or who may be on the fence.” Then Martin talked to everyone on those two lists. The detractors helped identify where the stumbling blocks were going to be for their business. And the champions were the people he approached to help him build the program.