Why You Should Consider Establishing an Open Source Program Office
SAP has a long-standing and significant history of contributing to open source software, whether it’s in the form of the OpenJDK project and our version of OpenJDK, our contributions to the Eclipse Foundation over the years (and most recently when our Vulnerability Assessment Tool became Eclipse Steady), our ongoing Kubernetes contributions and Knative contributions, or individual projects like CLA Assistant, which is widely used to manage license agreements signed by open source contributors.
However, even within SAP it was a bit of a secret how well-established and broad these contributions were, and that SAP is ranked #9 among commercial contributors to open source on GitHub. This was one factor in the decision taken in early 2018 to establish an open source program office within SAP.
“In the past, we may not have been active enough in sharing our open source engagement and activities,” says Peter Giese, director of the SAP OSPO.
The goal internally was to have one point of contact to better support our employees‘ contributions to open source software, while making those contributions more visible externally by increasing our involvement with open source foundations — through increased presence at open source events, for example.
Here, we’ll share some of the changes at SAP after we established our OSPO, benefits that have resulted from them, and what you should consider if you’re thinking of establishing an open source program office.
Bring the Experts Together
One very specific change — and tangible benefit — that resulted from the OSPO was the improvements made to the outbound process, something that project team members spoke about at the GitHub Enterprise Roadshow held in Munich early in 2020. As Fabienne Haag reported in her blog post on the event, the approval time for requests has reduced by 70% since the creation of OSPO. According to Fabienne, “bringing the right people together, at the right time, and asking the right questions,” were the secrets to making the process much quicker and leaner.
The pre-existing processes and policies expanded over time, but these changes were guided only by the evolving needs of individual teams. “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,” says Giese. “but there was no dedicated function or role with the overall responsibility for everything open source at SAP.”
“That has changed now,” he continued, “and SAP’s chief technology officer is responsible for open source at SAP.”
Since the advent of the SAP OSPO, these improvements can be routed through one central organization that provides the necessary support and expertise from these different internal stakeholders to make these changes in a collaborative way.
Use Familiar Approaches
The agile scrum working model Fabienne describes above, using flexible project teams from the different areas of responsibility, is the approach taken by OSPO when dealing with all the other aspects of open source tooling, process management, and governance. Of course, not everyone whose expertise was required had worked within a development organization (where an agile approach and a scrum working model are well-established) but using such a working model means you can (again) make use of existing knowledge to smooth the way.
The use of GitHub as a tool for managing the outbound process itself was inspired by the same idea: don’t make developers learn or adapt to a new tool when an existing, familiar one will do. The benefit of using familiar tools and working models is that you don’t need to get into a discussion around which tools you’ll use, or spend time learning new approaches, and you can work directly on the goals you set out to achieve.
Collaboration
Of course, learning new working models and tools may be necessary for some of the participants, but in large organizations like SAP we have found that this can be a refreshing change from the typical daily work in a given role; and it also helps build empathy and trust between people (and departments) who can’t identify with one another based on a shared role or experience.
Collaboration on a project for mutual benefit is a key tenet and advantage of the open source approach and learning to collaborate and work differently may be one of the challenges you face if you want to increase your open source contributions or establish your own OSPO. By having a larger pool of people who “know the ropes” and have an established working relationship, new ideas or potential process improvements can be handled more quickly and informally.
Changing Perceptions
As noted above, even within SAP there was perhaps a lack of awareness around our open source contributions, and the role of open source in our products. But 100% of SAP’s solutions touch open source in one way or another. Having an OSPO means a realization that open source is standard practice, and it also helps attract external talents who have worked with open source in the past.
Open source development lets SAP leverage collaborative co-innovation on many different technologies, that we could never develop or drive adoption of by ourselves. “Not invented here” becomes instead an opportunity to build collaboratively on the ideas of others and more efficiently develop your products — sometimes also through InnerSource development, where developers collaborate within your company following open source principles and approaches.
Continuous Improvement
The outbound process, for example, is still being improved and refined. By bringing the various open source experts together on a regular basis, new tooling has been developed to automate other aspects of the process and ensure the security of our open source projects (like SAP’s framework for open source project security ratings). Since the introduction of these improvements, we’ve seen a significant increase of new outbound open source projects.
In a way, there is a snowball effect, where the continuous improvements in the tools and processes only widen the circle further and allow more people to get involved and contribute; the communication channels mean ideas and successes can be shared and amplified. That in turn means there are more topics to share and promote externally, hence the increased presence at Open Source Summit, OSCON, FOSDEM, EclipseCon, and so on. “That’s why we also joined the TODO Group to share experiences, jointly develop best practices, and work on common tooling,” says Giese. This greater interaction in turn opens new avenues for learning and improvement.
COVID-19 and the Corona-Warn-App
One recent and very specific example of the benefits of having an OSPO already established within SAP was the co-development with Deutsche Telekom of the Corona-Warn-App for Germany’s Robert Koch Institute for public health. The federal government requested the creation of an app that would alert users to any prior exposure to persons who subsequently tested positive for COVID-19.
The intention was to develop the app using a decentralized approach, using open source principles and the utmost regard for the privacy of users, which is an absolutely fundamental requirement in Germany. Only by developing and releasing the app as an open source project could the necessary clarity around security and data privacy be ensured. The attendant early feedback and bug reporting also played important roles in improving the app itself and helped ensure successful adoption (article in German and English) after it was released.
The tools, processes, networks of expertise and collaboration channels already established by SAP’s OSPO meant this daunting challenge could be solved in a remarkable and successful way in a development timeframe of a mere 50 days.
Based on our experiences at SAP, the benefits and impact of establishing an OSPO has certainly given a new focus and impetus to our open source efforts. Embracing the spirit of openness and collaboration that defines and drives the open source approach might well bring benefits to your organization too.
Thanks to the OSPO team at SAP for their help in writing this article; in particular Peter Giese, Ulrike Fempel and Michael Picht.
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
