From time to time, we (the Open Source Program Office of SAP) are asked by customers how we organized the management of open source software at SAP. Often the reason is that the requesting company is not a traditional IT company, but increasingly needs software for its own products or services. To a large extent, this is about open source software and therefore the question arises how to manage that in an enterprise.
At SAP we founded an Open Source Program Office (OSPO) some years ago as a central unit to take over responsibility for open source-related tasks. Since this worked out quite well, I decided to blog about that. In this post I describe what an OSPO is in general and which tasks it typically has. In a second post, I will cover the setup of SAP's OSPO.
What is an OSPO
Let's start with the general part: What is an Open Source Program Office - or short “OSPO”? - It's a central team that takes care of the various tasks related to open source software within a company using a holistic approach. Originally, this approach was mainly used by IT companies. Due to the increased importance and spread of open source software, however, it can also be useful and attractive for non-IT companies that are faced with the challenge of managing open source software in their organization and introducing appropriate processes and tools.
OSPO is the most used term internationally, but a similar form of organization can also be implemented under other names. So, you're company could already have an OSPO though it's called something else.
Tasks of an OSPO
The area of responsibility of an OSPO can be quite large. Typically, it takes care of the following topics:
Open Source Strategy This is about the question of how open source software (i.e., its use, contribution to, but also the initiation of new open source projects) can support company and product strategies and help to achieve company goals. In addition to the creation, the internal (and possibly external) communication of the open source strategy in cooperation with the relevant stakeholders is also one of the tasks of an OSPO.
Open Source Policy When dealing with open source software, it is important to define rules and implement them within the company. This applies particularly to the use of open source software within your own organization or in your own products, contribution to open source projects, but also starting your own projects. It is the task of the OSPO to create the open source policy for the company, to communicate it and to provide appropriate training for the employees.
Open Source Processes The definition, implementation, execution, and continuous further development of processes for the management of open source software in the company are also among the tasks of an OSPO. For example, processes that help ensure license compliance.
Tools Due to the sheer mass of open source software in companies, the associated processes can no longer be carried out efficiently without automation and tool support, especially in larger companies. The task of an OSPO is to introduce, administer and, if necessary, develop appropriate tools for the most extensive automation of the open source management processes.
Training Dealing with open source software makes it necessary for the relevant employees (engineers, etc.) to build up appropriate knowledge. This concerns the use of open source in compliance with legal and security rules, but also participation in open source working groups and the initiation of open source projects and the associated development of communities. The OSPO is typically responsible for developing, providing, and continuously maintaining a corresponding training program for employees.
Communication Another task of an OSPO is to create transparency about the open source commitment of a company, both internally for its own employees, and externally for the interested public, developer communities, partners, and customers.
Particularly, if you start your own open source projects, it is important to make them known (for example via blog posts, lectures at conferences or publications in the relevant media). It is also usually desirable to build and manage communities around these projects. An OSPO can advise and support development teams in these tasks.
Memberships in Open Source Associations and Committees In the open source area, influence is typically exercised through collaboration in communities. These can be project-specific communities, but also larger organizations such as open source foundations. An OSPO typically has the task of aligning memberships and engagements in these organizations with the strategic goals pursued by a company with open source, i.e., initiating and supporting such engagements in accordance with the company's strategic goals.
An OSPO therefore has a wide range of tasks to perform. So that it does not become a central bottleneck, it is important to find a balance between processes that are run centrally by the OSPO and decisions that can be delegated to development departments. Tools for automating and supporting processes, as well as self-services for employees, play an important role here as well.
Organizational Aspects of an Open Source Program Office
There is no general blueprint for the structure of an OSPO and where to anchor it from an organizational perspective. Rather, that depends on the company structure, the use, and the strategic importance of open source software for the company.
Often, OSPOs start small, with only a few positions, sometimes even just one employee. On the one hand, there are OSPOs that consist entirely of full-time employees, on the other hand, there are those that are completely virtual, i.e., they consist exclusively of part-time employees who carry out the OSPO work in addition to their work in their actual department. Due to the variety of its tasks, an OSPO must work together with many different corporate divisions, for example with ...
Legal, IP, compliance, and security departments
Corporate communication and (technical) marketing
Internal IT department
Software procurement (purchasing)
Therefore, a completely virtual organization consisting exclusively of part-time employees from several of the above-mentioned departments can make perfect sense. Mixed forms are also conceivable. There could be a core team of full-time employees who are supported in a virtual approach by part-time employees from other departments.
The possibilities for anchoring an OSPO in the company are just as diverse. On the one hand, there can be a central OSPO that is responsible for the entire company, but if the company consists of units that tend to act independently of one another, it may be advisable to set up decentralized OSPOs in the individual units of the company instead.
Often an OSPO is placed in the reporting line of the Chief Technology Officer (CTO) or Chief Operations Officer (COO).
Setting up an OSPO as a dedicated place to take care of the diverse tasks relating to the management of open source in a holistic manner is definitely a recommendable approach. However, the specific structure and scope, but also where the OSPO is anchored in the company organization, depends on the specific situation of the company, such as its structure and the focus areas of its open source activities.
In one of the following posts I will write about the SAP's OSPO - why it was started and how it is set up.
Further Information and Resources
There are quite some helpful information and resources about OSPO's available. The Linux Foundation has a dedicated working group (the TODO Group) where companies can collaborate wrt. open source management and how to set up an OSPO. They also have a dedicated guide about setting up an OSPO. OSPO++ and OSPO.Zone are other initiatives that help companies collaborating on OSPO's.