In the first part of my two-part series about Open Source Program Offices (OSPO), I explained the general concept of an OSPO as an organizational unit to manage open source software in the enterprise in a holistic manner. This second part focuses on the structure and working mode of SAP’s OSPO.
Let’s start with a little bit of history. Open source has quite a long tradition at SAP. As early as 1998, the company's R/3 software was ported to Linux (which was still very young at the time). As a result - also through the acquisition of various companies - the use of open source software in the company and in SAP products steadily increased. A little later, SAP’s development workforce started to contribute to open source projects, and finally SAP began to publish software as open source.
Since the 2000s, processes for inbound and outbound open source (i.e., the consumption of and the contribution to open source projects) have been implemented successively to meet the requirements for security, license, and intellectual property rights compliance, etc. To support and efficiently carry out these processes, it was necessary to use tools such as license scanners, security analysis and assessment tools, software repositories, and tools for the management of legal agreements such as Contributor License Agreements (CLA) or Developer Certificates of Origin (DCO). These tools were either externally procured or internally developed. Some of them have been published as open source by SAP (examples are Eclipse Steady, the CLA Assistant and Fosstars). Corresponding teams that introduce, maintain, and operate these tools have been set up in parallel.
So there were already several groups from different departments and board areas who were involved in one way or another in the management of open source when we decided to do the next step: Due to the increased importance of open source within SAP, the OSPO was founded in 2018 to bundle and coordinate the diverse tasks of open source management in the company. It was built up in the reporting line of our CTO.
Because of the history described above and the teams and organizations that have emerged over time, the SAP OSPO was set up as a combination of a core team and an extended, virtual team. The employees of the core team work full-time on open source topics and at the same time coordinate the work of the entire OSPO. They are supported by experts from various other departments, such as ...
Most of those colleagues do not work on open source topics full-time.
In the initial kick-off workshop, representatives from all involved teams aligned on a mission, common goals, and a working mode. The tasks of the entire OSPO are clustered in so-called workstreams, such as open source strategy and policy, inbound open source, outbound open source, InnerSource and communications. The relevant employees from the core team and the experts from supporting teams work together in these workstreams. The entire OSPO works - analogous to the SAP software development teams - in Scrum mode with monthly sprints based on a common backlog.
This cross-functional setup has clear benefits. I just want to give one example: When we started our OSPO, there were complaints about the inefficient open source outbound process that we had at that point in time (that’s the process engineers must go through when they want to publish software as open source). We set up a small project team with colleagues from the involved departments, such as OSPO core, Legal & IPR, Compliance & Licensing. This group redesigned and simplified the process significantly. Today, we have an efficient process with end-to-end tool support and automation wherever possible (please get more details in this blog post). That would not have been possible without the cross-functional setup of the OSPO and the trustful collaboration of the different involved units.
As a global company, SAP’s development labs are spread across the world. With an informal network called Open Source Champions, we can better address enablement and cooperation of development teams in remote locations. This group is managed by the OSPO core team and consists of volunteers, who are open source enthusiasts with different technical and cultural backgrounds. These open source champions act as multipliers for open source-relevant topics within their location, support the OSPO with feedback and share their own experience with open source. This virtual team meets monthly in virtual meetings.
By founding the OSPO, SAP has succeeded in managing and growing the topic of open source in a much more holistic way than previously possible without a dedicated organization. The collaboration between the individual teams involved in the open source processes was improved and efficiency was increased. This in turn made it possible to significantly optimize and automate internal processes.
Surveys among SAP developers on open source topics (the OSPO regularly conducts such surveys) show that satisfaction with open source processes and tooling has increased significantly since the OSPO was founded.
The transparency of SAP's open source commitment has also been significantly improved thanks to the external communication activities initiated by the OSPO; e.g., through an SAP open source Twitter channel, an open source podcast series, an open source webinar series a new open source landing page (see the links below the post) and many blog posts and conference contributions.
See also: SAP: One of Open Source’s Best Kept Secrets.
-----
If you wish to learn more about SAP Open Source:
Learn more: Webinars | Podcasts | SAP Community
Explore: Engagement in Projects & Foundations
Engage: GitHub
Follow us on: Twitter
If you have any question, feel free to ask it here.
A Brief History of Open Source @ SAP
Let’s start with a little bit of history. Open source has quite a long tradition at SAP. As early as 1998, the company's R/3 software was ported to Linux (which was still very young at the time). As a result - also through the acquisition of various companies - the use of open source software in the company and in SAP products steadily increased. A little later, SAP’s development workforce started to contribute to open source projects, and finally SAP began to publish software as open source.
Since the 2000s, processes for inbound and outbound open source (i.e., the consumption of and the contribution to open source projects) have been implemented successively to meet the requirements for security, license, and intellectual property rights compliance, etc. To support and efficiently carry out these processes, it was necessary to use tools such as license scanners, security analysis and assessment tools, software repositories, and tools for the management of legal agreements such as Contributor License Agreements (CLA) or Developer Certificates of Origin (DCO). These tools were either externally procured or internally developed. Some of them have been published as open source by SAP (examples are Eclipse Steady, the CLA Assistant and Fosstars). Corresponding teams that introduce, maintain, and operate these tools have been set up in parallel.
SAP's OSPO: Setup and Working Mode
So there were already several groups from different departments and board areas who were involved in one way or another in the management of open source when we decided to do the next step: Due to the increased importance of open source within SAP, the OSPO was founded in 2018 to bundle and coordinate the diverse tasks of open source management in the company. It was built up in the reporting line of our CTO.
Because of the history described above and the teams and organizations that have emerged over time, the SAP OSPO was set up as a combination of a core team and an extended, virtual team. The employees of the core team work full-time on open source topics and at the same time coordinate the work of the entire OSPO. They are supported by experts from various other departments, such as ...
- License management
- Legal / IP
- Tool’s development
- Security
- Communication / Developer Relations
Most of those colleagues do not work on open source topics full-time.
In the initial kick-off workshop, representatives from all involved teams aligned on a mission, common goals, and a working mode. The tasks of the entire OSPO are clustered in so-called workstreams, such as open source strategy and policy, inbound open source, outbound open source, InnerSource and communications. The relevant employees from the core team and the experts from supporting teams work together in these workstreams. The entire OSPO works - analogous to the SAP software development teams - in Scrum mode with monthly sprints based on a common backlog.
This cross-functional setup has clear benefits. I just want to give one example: When we started our OSPO, there were complaints about the inefficient open source outbound process that we had at that point in time (that’s the process engineers must go through when they want to publish software as open source). We set up a small project team with colleagues from the involved departments, such as OSPO core, Legal & IPR, Compliance & Licensing. This group redesigned and simplified the process significantly. Today, we have an efficient process with end-to-end tool support and automation wherever possible (please get more details in this blog post). That would not have been possible without the cross-functional setup of the OSPO and the trustful collaboration of the different involved units.
Extending the Reach: Open Source Champions
As a global company, SAP’s development labs are spread across the world. With an informal network called Open Source Champions, we can better address enablement and cooperation of development teams in remote locations. This group is managed by the OSPO core team and consists of volunteers, who are open source enthusiasts with different technical and cultural backgrounds. These open source champions act as multipliers for open source-relevant topics within their location, support the OSPO with feedback and share their own experience with open source. This virtual team meets monthly in virtual meetings.
Conclusion
By founding the OSPO, SAP has succeeded in managing and growing the topic of open source in a much more holistic way than previously possible without a dedicated organization. The collaboration between the individual teams involved in the open source processes was improved and efficiency was increased. This in turn made it possible to significantly optimize and automate internal processes.
Surveys among SAP developers on open source topics (the OSPO regularly conducts such surveys) show that satisfaction with open source processes and tooling has increased significantly since the OSPO was founded.
The transparency of SAP's open source commitment has also been significantly improved thanks to the external communication activities initiated by the OSPO; e.g., through an SAP open source Twitter channel, an open source podcast series, an open source webinar series a new open source landing page (see the links below the post) and many blog posts and conference contributions.
See also: SAP: One of Open Source’s Best Kept Secrets.
-----
If you wish to learn more about SAP Open Source:
Learn more: Webinars | Podcasts | SAP Community
Explore: Engagement in Projects & Foundations
Engage: GitHub
Follow us on: Twitter
If you have any question, feel free to ask it here.
- SAP Managed Tags: