“If we tried to have a centralized body to approve open source for Windows, Office, and Azure, we would be pulling our hair out. Those are fundamentally different businesses. We give engineers the tools and guidance to enable their work, but are not a central approval body. That works in some companies but would not work here.”

Jeff McAffer – Director of the Open Source Programs Office at Microsoft

So how and where should open source program offices fit inside a company’s organizational structure? Should it be inside the engineering department? Or in the legal department, the CTO’s office or in another specific business unit? Again, that depends on your company’s primary business and your open source strategy.

Legal

For companies that have large intellectual property portfolios, that could mean the open source program office might be a perfect fit in the legal office, where developers can work closely with the legal team on issues that arise. That might be a good fit for a hardware company because it’s always concerned about potentially running into IP-related legal issues.

Engineering

Other companies are more engineering-driven, so they choose to maintain their open source program offices within their engineering departments. That allows them to focus their efforts directly on making their developers more effective and productive in their work.

Developer Relations, Marketing or Communications

In other cases, some open source offices are located inside the marketing wing of organizations because they use open source to funnel leads aimed at selling the products they build using open source.

At Twitter, where open source use has been integral to the company’s success, developers were finding it difficult to contribute back to open source projects starting in 2010 because the company’s legal department had serious concerns about code licensing and related issues. Developers and software engineers responded by seeking ways to automate the license compliance processes – to “grease the wheels” – to alleviate the concerns of the legal and engineering departments. The result was the hiring of an open source program manager and the creation of an open source program office to fix processes, streamline procedures, bring in tools to automate tasks and make other needed changes.

Intriguingly, Netflix took a different approach and chose not to create or use a centralized open source program office, says Andrew Spyker, the manager of the company’s container cloud. Instead, the streaming movie and entertainment company organizes its open source use through a small, cross-functional working group that runs an internal mailing list for discussions and meets informally once a month to help each other resolve open source issues. The volunteer working group members assist other decentralized teams, leaving everyone with less need to focus on administrative tasks such as legal issues, tools, monitoring and community promotion. For Netflix this is a workable approach because it’s an entertainment company and not a software company.

At Microsoft, the structure of its open source program office, which is inside its engineering department, is unique because it has some 60,000 software engineers to support. That large number of developers required a move away from the idea that the details of all open source projects would have to go through one centralized office, which would have been overwhelmed and unworkable. Instead, for things that can’t be automated, the company’s open source program office team enables engineers to make local decisions about their projects, rather than having to attempt to navigate a centralized bottleneck that could gum up the operations.

Under its process, Microsoft engineers can go into the company’s open source workflows, share that they want to use a piece of code or release something to an open source community, and then receive responses from local reviewers who provide feedback. The highly specialized process includes about 300 different groups of business and legal reviewers who can weigh in on the localized requests with their expertise, helping to provide a workable approach for the company.

In creating an open source program office, decisions also must be made to establish the roles and responsibilities of the open source program manager, the company’s legal team, and any review board made up of engineers and executives.

Program manager

For maximum effectiveness, the program manager should be empowered as an executive-level position with direct oversight and hands-on management of the company’s interests in its open source activities. That would give them the tools they need to lead the way inside an enterprise toward its open source goals and vision.

Microsoft uses an Open Source Executive Council, which is similar to a review board. The group, which is made up of vice presidents from all the major business units inside the company, provides board of directors-style guidance on policy changes and introductions, sets priorities for the open source program, and assists in driving changes in behavior.

Legal

Like every other function inside a company, legal teams must have a say in the operations of the open source program office to ensure compliance with laws, open source licensing agreements, and other legal details. Specific to open source, the legal team needs to be responsible for ensuring that a company can consume code internally and contribute back to projects with acceptable terms. Larger organizations should consider hiring or training a dedicated attorney to advise their open source program. But you could also use a part-time, knowledgable staff member or outside counsel. It is often helpful to work with an attorney who is knowledgeable and experienced with open source licensing and IP as it can be a specialized, and at times baffling, legal domain relative to commercial contracts or standards.

Compliance Team

The open source compliance team is a cross-disciplinary group consisting of various individuals tasked with the mission of ensuring open source compliance. The core team, often called the Open Source Review Board (OSRB), consists of representatives from engineering and product teams, one or more legal counsel, and the compliance officer (who is often the open source program manager).

The extended team consists of various individuals across multiple departments that contribute on an ongoing basis to the compliance efforts. These may include documentation, supply chain, corporate development, IT, localization and an Open Source Executive Committee (OSEC). However, unlike the core team, members of the extended team are only working on compliance on a part-time basis, based on tasks they receive from the OSRB. Samsung program manager Ibrahim Haddad’s book, Open Source Compliance in the Enterprise, provides a detailed discussion on the roles and responsibilities of individuals involved in achieving open source compliance.

Developer Relations, Advocacy, and Evangelists

Open source developer relations and evangelists can be important to a fledgling open source program office because they can work to build interest and enthusiasm within a company’s developer community for specific projects, which can help grow the efforts and increase teamwork among engineers. Evangelists oftencan also go to conferences and tech events and explain what open source is to help audiences understand how it can be used and what challenges and opportunities it offers, while sharing their corporate experiences with the open source community.

Others

In addition, the creation of other job roles is important for the success of the open source program office, including tool administrators, training managers, integration developers for tools and systems, deployment support staffers, implementation project leads, and open source evangelists. Tool administrators, for example, are needed to help select, provide and integrate needed tools for engineers working on their open source projects, while also ensuring the tools meet the licensing and other requirements of an enterprise.

With many of the other important components now planned or assembled for your company’s open source program office, from its creation to its structure to personnel, the next step is to develop well-defined policies and processes which will enable consistent implementation of your company’s open source strategy.

The policies should lay out the requirements and rules for working with open source across the company, as well as documented and executable processes which will ensure the rules are followed on a day-to-day basis.

Crucially, they should require minimal overhead. Microsoft looks at its open source program office policies and processes with the goal of making them as unobtrusive as possible for developers and other team members. The approach is to repeatedly eliminate, automate and delegate when reviewing existing open source policies and processes so the rules are constantly questioned and updated to streamline procedures. That means asking why policies are even in place and how they can be improved for users.

“Having a well-defined policy in place, that’s great, but it’s got to be a well-defined minimal policy. Otherwise you get lawyers, security folks, business folks, all piling in their concerns and constraints. Soon you end up with a strait jacket full of policy that basically means that nobody can do anything.”

Jeff McAffer – Director of the Open Source Programs Office at Microsoft

Even as those rules are carefully created for open source program offices, companies must be prepared to evolve and modify the rules and procedures as needed over time as their businesses change and as their open source engagements mature and grow.

This may sound like yet another daunting step in the process, but like open source code itself, sample rules and processes are available from open source silos and can be implemented and customized by enterprises, making your tasks easier.

Among the best examples of such rules are from Google, which early in 2017 published its open source policies for review and free use so others can learn how the company uses, releases and supports open source and how it’s involved in projects and communities. Some of the content is scrubbed for security and privacy reasons, but it provides many lessons learned in how the company does its work.

When drafting open source policies, among the many topics that need to be discussed are:

• How your company accepts external contributions to their open source projects
• How to prepare for open source releases
• How approvals are received
• How developers can use open source code they find on GitHub and other code repositories
• Procedures and rules explaining how open source code can be brought into your company
• How the incoming code is catalogued so others know it is being used
• How a company can grow a community of like-minded external developers around it to keep it thriving
• Rules that help determine when code should be released as open source or kept as intellectual property

Policies for releasing code

You want to help people be successful in making contributions to open source projects and in releasing their own projects. Guidelines and checklists ensure that developers have everything they need to release their code as open source without running into licensing or confidentiality issues. Especially for new contributors, it can also help to have an internal review process available as a safe place to get feedback before making a contribution. (See our guide on Participating in Open Source Communities.)

Your organization should also strive to adopt an “upstream first” development policy. By submitting patches to the upstream open source project first, and incorporating them into your own products downstream, you will avoid spending a massive amount of time and money on re-engineering after each release.

Policies for accepting contributions

Unless your open source projects are housed at a neutral foundation, you’ll want to set out procedures for your company to receive contributions to your own open source projects from external developers.

“You actually don’t want to be the only people contributing to your open source project. You want to have people outside your company contribute to your open source project, because at the end of the day, there’s no way to hire all the smartest people in the world. It’s impossible. Even if you’re Google, it’s impossible.”

Chris Aniszczyk – COO of the Cloud Native Computing Foundation and former head of open source programs at Twitter

That is, of course, one of the benefits of putting your company’s open source code out into other communities and to inviting other developers to establish an interest in your own projects. Because in the grand scheme of things, even though they are not officially your employees, you can have brilliant people working on your company’s code from around the world, making it better and expanding its capabilities. This kind of collaboration is important for companies and is a common focus for many open source program offices.

Policies to promote adoption

You also want to encourage others to use your code in their products and services. This is key to building ecosystems that in turn help grow and sustain your open source projects. Policies for open source use can come in a variety of innovative forms.

Red Hat has a unique policy by defaulting to open source with its newly-created code in most cases from the start. That means that when developing each piece of software inside the company, it is assumed that in the future it may be destined to be released as open source. This is intriguing because typically there is a different attitude among engineers for releasing their code as open source because other people will then be looking at it.  Due to that scrutiny, they tend to structure things in better ways when writing open source, creating cleaner code with fewer or improved code dependencies in their work.

Policies for internal consumption

Other needed policies include rules about how and where your team finds trusted sources for open source software use and creation, policies about establishing code management and maintenance procedures, and formalizing community interaction for your projects. (See our guide on Using Open Source Code.)

An open source usage policy ensures that any software (proprietary, third-party, or open source) that makes its way into the product base has been audited, reviewed, and approved. It also ensures that your company has a plan to fulfill the license obligations resulting from using the various software components, before your products make it to customers.

For example, your policy could require engineers to receive approval from your organization’s auditing staff, such as an open source review board (OSRB), before integrating any open source code in a product. It may also state that software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships.

Policies for compliance

Also needed are policies to formalize and establish legal compliance procedures and to assure executive oversight for the program. 

You’ll also want to map out how you’ll handle the software tools that will make much of the compliance and code testing work possible by automating it and streamlining procedures for developers and contributors. For example, the SPDX and OpenChain tools from The Linux Foundation, along with help from your internal supply chain teams, will ensure that code brought in by third parties is also compliant.

There’s a broad array of open source (e.g. FOSSology) and fee-based proprietary tools in the marketplace today that can help with these important tasks, and for most open source program offices, a quality and comprehensive collection of tools can be brought together without the need to build your own custom tools. Again, much of this is due to the collaboration aspects of the open source process, where contributing developers have created and refined the tools which can handle these tasks for enterprises. And if the tools don’t do exactly what your project needs, then users can contribute back to modify and improve them to gain the capabilities they are seeking. Getting involved in the open source community around enterprise tooling is something that your open source program office will likely support.

Existing open source resources are also potential gold mines for finding other materials needed by your open source projects, including documentation for contributor license agreements (CLAs). CLAs define the terms under which intellectual property has been contributed to open source software. Projects that use CLAs require contributors and often their company to sign the CLA agreements before contributions will be accepted by the project.

Many companies have written their own CLAs but there are generic versions that have been created and are available as open source agreements which can be used without starting from scratch. Most of what you will need can be found in a template and then you can customize the CLAs to cover any issues that remain. Attorneys from other potential contributing companies will often appreciate reuse of standard terms.

Inside Google a variety of tools are used regularly to perform automated code checks using features such as custom filters which can scan code bases to check for licenses, license compatibility, and other factors. Each time Google releases a new Android or other application, it undergoes an automated process for checking license compliance, simplifying procedures for the company. And because it is automated, it makes it easier to make the argument to engineers that the process is simple and seamless and won’t burden them to use for their applications.

All new Google engineers are also required to go through a one-hour open source class where licensing and compliance are stressed as part of how the company does business. A key lesson shared by the company is that not only is Google obligated by licensing legalese to comply with licenses, but that it also complies because it’s the right thing to do for the community. Google’s lawyers are available to represent the company if an obvious mistake is made in licensing or code use, but the company is very sensitive about potentially submitting code that could harm its standing in the community.

“Angering our friends in the open source community would be devastating. It’s not something we would ever want to do because we care about this community, we’re part of it. For companies that are new to open source, I think they often fail to recognize the importance of that.”

Will Norris – Open Source Office Manager at Google

There’s a lot of work to do and much to consider when your company decides to create an open source program office, but its value will likely outweigh the efforts taken to accomplish it. Finding just the right leader to drive the program office initiative is a critical step in the process to make it a success.

“This is a culture change endeavor. The code is obviously a big part of it, but the community and the engagement is a people-to-people thing. If you’re going to start an open source program office and you’re going to try to make it a real thing, you’re going to need to understand the culture and get somebody in place who can help drive that culture to a new level. Your head of open source is really a change agent.”

Jeff McAffer – Director of the Open Source Programs Office at Microsoft

**Open Source Lead (Box)**
In April last year, we formally announced our intention to be leaders and active contributors in the Open Source community. Since then, we have launched several exciting projects (check out Spout, Brainy, Leche, ClusterRunner, Flaky – links below). We plan to continue adding to the list with more high quality projects over the coming year. Our open source effort is currently driven by a cross functional group of engineers and we are looking for a motivated, ambitious individual to own this effort and take Box Open Source to the next level. In this role, you’ll work with all of dev & ops, legal, and PR to help define what Open Source at Box means and build our open source community. Your day to day responsibilities will alternate between programming and program management. This is an exciting opportunity to work with all levels of the organization and leave a lasting impact here and on the engineering community at large.
QUALIFICATIONS:

• 10 years experience coding in or leading software engineering environments
• Experience working on at least one successful and widely recognized open source project
• Excellent communication and organizational skillsFamiliarity with GitHub, Travis Cl, Coveralls, and other open source tools
• Good understanding of open source licenses
• Experience and familiarity with multiple programming languages
• Passion for quality and continuous improvement

RESPONSIBILITIES INCLUDE:

• Managing and streamlining all aspects of the outgoing open source process at Box
(from people processes to tooling automation)
• Owning and managing Box’s open source presence and reputation on GitHub and beyond
• Driving involvement and recognition of the open source program internally
• Aligning goals of the program with larger product and business goals
• Building awareness of Box open source externally and increasing overall Box involvement
in the open source community
• Establishing Box as a high-contributing member of industry-leading Open-Source initiatives (e.g. TODO Group)
• Managing our process for evaluating incoming open source code for use at Box

We’re very excited to meet people interested in this rolel Please get in touch with us to learn more. About Box: Founded in 2005, Box (NYSE:BOX) is transforming the way people and organizations work so they can achieve their greatest ambitions. As the world’s leading enterprise software platform for secure content collaboration, Box helps business of all sizes in every industry securely access and manage their critical information in the cloud. Box is headquartered in Los Altos, CA, with offices across the United States, Europe and Asia.
To learn more about Box, visit www.box.com.

These resources were created in partnership with the TODO (Talk Openly, Develop Openly) Group – the professional open source networking group at The Linux Foundation. A special thanks goes out to the open source program managers who contributed their time and knowledge to making these comprehensive guides. Participating companies include Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Oath (Yahoo + AOL), Red Hat, Salesforce, Samsung and VMware. To learn more, visit: todogroup.org

This work is licensed under a Creative Commons Attribution ShareAlike 4.0 International License.