Open Source Program Guides cover case studies from the industries leading open source programs. We started with Comcast, Dropbox, Facebook, Microsoft, Red Hat and Salesforce, this month we’re happy to add the SAP open source program (OSPO):
SAP has been working with open source for decades and has now established an open source program office (OSPO) to further formalize the coordination of its open source activities and expand its engagement with the open source communities. “SAP was one of the first industry players to formally define processes for open source consumption and contribution,” says Peter Giese, director of the Open Source Program Office.
Even so, many people do not yet consider SAP to be a company that embraces open source engagement and contributions.
“In the past, we may not have been active enough in sharing our open source activities,” says Giese.
Now, SAP is shining a spotlight on its work in open source. Transparency is an essential part of the new open source mandate, beginning with an explanation of what the company has been up to and where it is headed with open source.
“In 1998, SAP started to port the R/3 system, our market-leading ERP system, to Linux,” says Giese. “That was an important milestone for establishing Linux in the enterprise software market.”
Porting a system to Linux was just a first step, and a successful one. The action spurred an internal discussion and exploration of how and where to adopt Linux going forward.
“We came to the conclusion that Linux would become a major force,” Giese says. “Today that’s obvious, but at the time it was not as obvious to everybody. That’s when we started our endeavors into open source.”
In 2001, SAP formally defined and internally documented its process for open source consumption, and the company committed to using inbound open source projects to build SAP products. There were lots of details to attend to, such as open source licensing, security, and export control restrictions.
By 2004, SAP already had information on the specifications exchange with other companies and was one of the founding members of the Eclipse Foundation. From then onwards, SAP developers actively contributed to several Eclipse projects, including JGit, EGit, Mat, Tycho and Che.
However, it wasn’t until 2008 that SAP started to actively promote open source contributions from SAP employees on a company-wide basis. That was also the year when the company rolled out its outbound open source process. “We had a set of guidelines and rules for what SAP teams had to do in order to share their work with the open source community,” explains Giese.
In 2010, SAP integrated open source tools further into its development processes. “We moved to a higher level of compliance by introducing systematic open source code scanning as part of our standard development processes,” says Giese. “That means we started to systematically scan open source code for license compliance and security issues.”
In 2014, SAP shared with the open source community a tool called CLA assistant which was developed for managing open source contributor license agreements.
Even though these activities and projects were very successful, there was a growing need for more central coordination of SAP’s open source activities.
“We had several teams that took care of specific aspects of open source, such as security scanning, license scanning, and building our own open source tooling. But there was no dedicated function or role with the overall responsibility for everything open source at SAP,” says Giese. “That has changed now, and SAP’s chief technology officer is responsible for open source at SAP.”
The new central Open Source Program Office was established in early 2018.
“We wanted to be more active and visible in our interactions with our outside customers and partners, and with open source foundations and other open source communities,” says Giese. “That’s why we also joined the TODO Group last year to share experiences, jointly develop best practices, and work on common tooling.”
Giese points out that the company’s investments and contributions to open source are substantial, yet they still come as a surprise to many people.
“For example, in February 2018, Fil Maj from Adobe published a worldwide ranking of companies, with their total number of their employees actively contributing to open source projects on GitHub, and SAP ranked at number seven”, says Giese. “There are, of course, different ways to create such statistics, but it gives you an idea of SAP’s role as a contributor. Maybe we’re one of open source’s best kept secrets.”
SAP prefers not to be a secret any longer and is stepping up its open source game in more visible ways. “We’re going to participate in more of the open source community conferences, such as Open Source Summit, OSCON, FOSDEM, EclipseCon, KubeCon, and so on” says Giese. SAP’s climb to higher visibility is a sign of its continued commitment to excellence in open source, and the company aims to form more partnerships and spur accelerated innovations.
One recent example of SAP’s innovative open source projects is Gardener, a solution for Kubernetes clusters as a service, as listed in the CNCF Cloud Native Landscape. It enables the management of a large number of Kubernetes clusters and the reuse of Kubernetes primitives in its core architecture.
Another newly open-sourced SAP project is Kyma, a flexible and easy way to connect and extend enterprise applications in a cloud native world.
SAP is actively encouraging companies and other developers to codevelop and cooperate on projects such as Gardener and Kyma.
“This type of co-innovation, for me, is the most compelling aspect about the whole open source movement,” says Giese.
SAP formed its Open Source Program Office as a virtual team consisting of several teams from different board areas.
“We are working in scrum mode, which is a software development methodology. It has advantages in driving an open source program office,” says Michael Picht, chief development architect in OSPO. “You work in sprints in scrum, and this means you’re forced to break down your tasks into smaller pieces.”
“The scrum methodology propagates cross-functional teams, and that’s what our OSPO is. We have colleagues from across the company in there. Scrum facilitates the work in such a setup. It sounds strange to some people when they hear we work in scrum mode, but in our case, it is working quite well.”
Picht says that “breaking large jobs down into smaller chunks and working in four-week sprints makes challenging and long-running tasks easier to master. It does require some training, however, to make sure all team members are comfortable with the method.”
The office’s mission is to nurture and support the open source approach to software development – inside and outside SAP. Consequently, for employees who want to contribute to open source projects in their spare time outside of the company context, SAP has simplified the clearance process dramatically. “We have provided a few simple rules and as long as you adhere to these you can directly start to work on open source projects in your spare time,” says Giese.
The company is also redesigning its corporate open source contribution process to make it even more efficient. The goal is to shift from policing developers to enabling them through simpler forms, automation of process steps, and support team services.
For the open source community, to advance open source best practices and tooling, SAP recently contributed it’s open source vulnerability assessment tool, which supports any software development organization in assessing security vulnerabilities of open-source components in their application development.
SAP’s open source program office will continue to look for ways to speed up and improve processes, and to support developers, partners, and open source communities.
“This will never end, this will always go on, so we always want to find new ways to improve open source processes and tools further,” says Picht.
We would like to thank Peter Giese, director of SAP’s Open Source Program Office and Michael Picht, chief development architect, for their time in contributions to this case study. We would also like to thank Pam Baker for taking the time to conduct interviews at the Open Source Program Office.