Cultivating InnerSource at SAP

[MichaelPicht]

In “Establishing InnerSource at SAP”, I explained how InnerSource works, its benefits and what we do at SAP to establish InnerSource as working model. In the meantime, our activities and approaches evolved. In this blog post I describe the different types of documentation and training material we created to facilitate the application of InnerSource in our company.

At SAP, InnerSource is driven by an InnerSource Program Office (ISPO). It is a virtual team which is led by members of the Open Source Program Office (OSPO). Since I am part of the ISPO, I simply might write “we” in the course of this post, when the ISPO is meant.

InnerSource strategy

InnerSource is not a means to an end. It must deliver clear benefits to SAP and support the company goals. Therefore, we created an InnerSource strategy for SAP. The purpose of such a strategy is precisely to describe how the application of InnerSource relates to our corporate goals and business strategy. It explains why InnerSource is important for SAP, why we should leverage it, what our goals are with respect to InnerSource, and what actions to perform to achieve those. Such a strategy is effective in persuading colleagues who may not see the value of InnerSource. It also helps in discussions with management. In addition, it defines guardrails for the work of the SAP ISPO.

“Getting started” guides

Development teams regularly ask how they can get started with InnerSource. We created two guides to support them. One, the "Beginner's guide", gives an overview about InnerSource, how it works, when it makes sense and when it might not, etc.

The other guide, "Getting started with a project", describes a step-by-step approach to start an InnerSource project. It begins with getting clarity about goals and priorities (i.e., why an InnerSource approach is chosen), a stakeholder analysis (which other parties are affected, who the potential contributors are, etc.), and ends with an action plan to start the InnerSource journey. However, this guide is generic - i.e., it is not specific to a certain project. To answer project-specific questions, the SAP ISPO offers dedicated support and consulting.

Case studies and success stories

Talking about InnerSource and its benefits in a general way is one thing, giving tangible examples is another. That is why we started documenting specific InnerSource approaches in case studies and success stories.

Case studies are rather comprehensive descriptions of the approach that an InnerSource project has selected, why they did it, what they learned, etc. Their main purpose is to share learnings and best practices in a comprehensive way. They address develop teams that use InnerSource already or plan to apply it.

Success stories on the other hand contain more condensed information about InnerSource projects, focusing on the challenges they solved, the success drivers and the business impact. Their main purpose is to briefly describe the project and the benefits it gained from the chosen InnerSource approach.

With this, we give development teams tangible examples of InnerSource approaches that they can use as input and inspiration for their own InnerSource journeys. Success stories are also a good means to communicate InnerSource benefits to management.

InnerSource patterns

Sometimes we come across solution approaches from teams that have a more general character and would thus be helpful for other InnerSource projects as well. InnerSource Commons uses the pattern concept to share such best practices.

At SAP, we adopt the patterns from InnerSource Commons and extend them with internal InnerSource patterns where needed. We even re-used the template from InnerSource Commons. This way, we describe solution approaches that SAP teams came up with to overcome challenges, and that are specific to SAP. For example, there is one pattern that explains how InnerSource can be applied to ABAP projects. ABAP is a proprietary programming language that SAP uses to implement business applications. Often, ABAP projects do not use Git-based tools such as GitHub, making it more difficult to set up a contribution workflow. Solution approaches are described in a dedicated SAP-internal pattern.

A pattern could first be created SAP-internally. In case it later turns out that it is not SAP-specific, we contribute it to InnerSource Commons.

Myths and concerns

During discussions with colleagues about InnerSource (when we advise teams who introduce InnerSource or during Q&A sessions) we frequently hear concerns and misconceptions - statements like "InnerSource means that everybody can dump low quality code in my repository" or "with InnerSource we lose control over our project". To correct such misunderstandings, we created a dedicated page in our InnerSource documentation where we list such myths and concerns and where we explain how InnerSource really works. This is particularly helpful, because we can point colleagues who have questions and concerns to this page. Sometimes colleagues ask us how they can convince their management about InnerSource, and this page is among the content we provide them with.

Some months ago, we did a podcast about InnerSource myths and concerns with Georg Gruetter from Bosch and myself.

InnerSource Dojo

As described above, we created quite a lot of documentation and training material about InnerSource. Thus, our target group might sometimes be a little bit overwhelmed. To provide a simple entry point and an easy to digest learning structure for our content, we created the InnerSource Dojo.

A dojo is a grassroots concept and platform that provides a learning experience through dialog and action cycles using aspects of gamification. In the InnerSource Dojo - similar to Asian martial arts - three belt levels are defined (green, red, black). These levels represent different levels of domain expertise. Each of them has tasks assigned, such as going through some content that is available in the InnerSource documentation or in other training material available SAP-internally, or doing some practical work – contributing to an InnerSource project or giving a presentation about InnerSource, for example. The idea is that SAP developers work through these tasks to achieve the next belt level. Finally, they can opt to be listed with their corresponding belt level and – by doing so – document their InnerSource knowledge.

Please have a look at [3] and/or [4] for more detailed information about the dojo concept.

Regional InnerSource communities

SAP is a global company. It has development labs distributed around the globe, and sometimes it is challenging to reach people in such locations and to figure out what their specific needs and challenges are. To facilitate the application of InnerSource we plan to establish regional InnerSource communities. Such a community would be active in one or more development locations and bring together people who want to learn and exchange about InnerSource and address needs as well as questions that are specific to that region. The SAP ISPO would be in close contact with these communities and support them. We are currently piloting this approach in China. If it is successful, we plan to roll out this concept to other regions as well.

InnerSource surveys

For the SAP ISPO, it is important to know where our company stands with respect to InnerSource and if our team is still working on those InnerSource topics that are most relevant to our development teams. Therefore, we execute InnerSource surveys from time to time.

So far, we did two of them. Our surveys contain around 10 questions. These are designed to find out what people know about InnerSource, if they apply it, and why or why not. Our survey targets colleagues with development roles since this is the most relevant group for InnerSource. To get a representative result, we sent the survey to a randomly generated sample group of colleagues across different locations and units.

We avoid changing the survey questions over time, to be able to compare the results and identify trends. We use the survey results to adjust our future activities - which additional content we should provide, for instance.

Our first InnerSource survey revealed, for example, that one of the main reasons why people do not contribute to InnerSource projects was that they simply do not know where and how to find such projects. Because of this survey result we decided to create the InnerSource Project Portal - see [1].

Conclusion

Over time, the SAP ISPO created different types of content to support development teams and facilitate the application of InnerSource and sharing of best practices, as well as to support the communication with management about InnerSource. This content is continuously adjusted based on feedback we receive. The InnerSource Dojo provides a structured entry point and learning map to all of this content.

Defining an InnerSource strategy is crucial for illustrating the broader vision and emphasizing the significance of InnerSource to the company's success.

To find out the status with respect to establishing InnerSource at SAP, we regularly execute surveys. The survey results show us if we are still on the right track. They are the basis to plan our future activities.

Further information

[1] "InnerSource & Discoverability" (InnerSource Commons Community Call, July 2021)

[2] "Establishing InnerSource at SAP" (SAP blog post, October 2021)

[3] "How SAP built a Dojo Community of Practice to support a cultural shift to DevOps" (Sumo Logic blog post, April 2022)

[4] "How to manage DevOps culture? From traditional IT practices, to DevOps and beyond" (Sumo Logic Illuminate, October 2022)

[5] "Debunking InnerSource Myths" (SAP Podcast “The Open Source Way”, April 2023)

[6] "How SAP Runs and Documents its InnerSource Program" (InnerSource Commons Summit, November 2023)

---

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: X/Twitter

If you have any question, feel free to ask it here.