 Hello and welcome to this Ospor Track Session at the Open Source Summit Europe 2020. My name is Peter Giese. I'm leading the SAP Open Source Program Office. And in this session, I would like to share with you how we have redesigned our outbound Open Source process in order to make it easy for our developers to contribute to Open Source. Open Source is of strategic importance for SAP. Accordingly, the overall responsibility for it resides with our Chief Technology Officer, Jürgen Müller, who is a member of the SAP Executive Board. Within his CTO unit, we have established the Open Source Program Office as a virtual team, consisting of 10 sub-teams, spread across four different board areas. This way we are able to tap in into the expertise of the different Open Source-related functions like legal, compliance, security or developer relations. Our Ospor has chosen SCRUM as its working mode in the same way our development teams are working. That means we have a joint backlog of tasks and we are working in four-week SCRUM sprints. At the beginning of each sprint, we do a sprint planning meeting where we jointly select which of the tasks from our overall backlog we want to tackle in the next sprint. Then for the next four weeks, we work together in six cross-functional teams comprised of the members of the virtual Ospo team to tackle these tasks. At the end of each sprint, we are doing a joint review meeting to review the results and check if they are meeting our done criteria. Our Ospo is responsible for five major areas. The first one is to define, evolve and drive our SAP Open Source strategy and policy. The second one is to manage Open Source compliance and risks. The third one is to enable and support our developers to consume Open Source and to contribute to Open Source. This point is extremely important to us because we see ourselves in Ospo as a service team which tries to remove all the friction from our processes so that the development teams can fully concentrate on their development tasks. That is also the motivation for the fourth area which is to continuously improve our Open Source processes and tools. And last but not least, our Ospo is also promoting and facilitating Inner Source at SAP for those development projects which we are not developing as Open Source. For us, managing Open Source is mainly about continuous improvement. That is why in 2018 when we established our Ospo, one of our first activities was to analyze the status of our Open Source management processes and tools. SAP's Open Source journey started mainly with Open Source consumption as is probably the case for most companies and accordingly in 2001 we already defined our inbound process in a formal way and in 2016 we did a complete redesign of it in order to significantly simplify it. That's why when we established the Ospo, our inbound process was already in great shape but on the contribution side the situation was different because our outbound process which we had formally defined in 2008 was not able to scale with the growth of contributions that we have been seeing since then from our SAP developers. That is why one of our major goals of the newly established Ospo was to completely redesign our outbound contribution process. Contributions to Open Source from SAP are coming in three major forms either as bug fixes or features to Open Source projects that had been initiated by third parties and here on the slide we have to pick just some of the projects that SAP is contributing to in this form like for instance Kubernetes, Cloud Foundry or clearly defined. On the other hand we have those Open Source projects which are initiated by our SAP development teams and also mainly different by them together of course with contributions from our partners and the Open Source community. Examples for this are for instance our Gardner project for managing large scale Kubernetes clusters or our Kuma project which is a site by site extension platform for cloud native applications. When SAP developers fix bugs in Open Source components that they are using we always encourage them to contribute those bug fixes upstream. This is a win-win situation for the according Open Source project which gets it fixed but also for SAP because when we consume future versions of the according project then we are not running into merge conflicts and merge efforts for those bug fixes again. Contributions in the form of bug fixes never required special approvals at SAP. Instead we are providing according guidelines to our developers and hold them accountable for adhering to these guidelines. Our development teams had to follow our outbound Open Source process only in cases when they wanted to contribute features or to initiate new Open Source projects themselves. Our old outbound Open Source process as defined in 2008 was comprised of six mandatory steps. The first step required our development teams to fill out a Word document with around about 30 questions about the projects that I wanted to Open Source and to submit this document by entering an according request ticket in our finance system. After that several teams reviewed the according questionnaire and only if all of them gave their approval the code scan was performed on the source code to create a bit of material and check all involved Open Source licenses. In the next step our legal IP teams reviewed it and only in case they approved everything an extra executive summary document was created for the according A2 manager to take his approval decision. Given his approval the development team could then continue to publish their project as Open Source on public GitHub. The process in this form had several pain points and deficiencies. A process execution was strictly sequential leading to unnecessary delays in the end-to-end process execution. B there was a lack of central transparency about the process date so that in case the process got stuck somewhere oftentimes nobody noticed for several days. C there were a lot of different tools involved in the process like our finance direct system word email excel with a lot of tool breaks in between creating unnecessary barriers for our teams. D there was a lot of extra effort involved to create the separate executive summary document for the A2 to take his approval decision. As a consequence the average duration from the initial outbound request submission to finally publishing the project on publicgithub.com was several months. In some exceptional cases it could even take up to a year. That is why we organized an Ospo workshop with all relevant stakeholders to completely redesign the process especially the invited representatives from all teams involved in the process as well as from our Open Source development projects. We carefully revisited every step and every document of the process to understand the original reasoning and to evaluate if there might be more lightweight alternatives. For this analysis we had defined a set of criteria the most important of which was empowerment meaning that we wanted to prefer guidelines over processes whenever possible in order not to micromanage and police our developers but to empower them by providing them with according guidelines and holding them accountable for adhering to these guidelines. The second evaluation criteria was differentiation instead of using a one-size-fits-all outbound process we wanted to differentiate between outbound Open Source feature contributions and outbound Open Source projects initiated by SAP development teams because of the fact that feature contributions are normally much smaller in size and less complex and in addition will be peer reviewed when submitting the pull request to the According Open Source project. We decided that in the future outbound Open Source feature contributions will not require to follow the SAP outbound process any longer. Instead we will provide our developers with according guidelines for feature contributions and hold them accountable for adhering to these guidelines with respect to the overall process workflow we got rid of the strict sequential execution and instead enabled parallel and optional process steps. In addition we redesigned the request submission form and drastically reduced the number of questions especially for determining if an optional step later in the process has to be executed or not. The optional step of export control classification for instance is only required if the according outbound Open Source project implements or uses encryption. Last but not least we completely removed process step number 5 which was a management approval and instead required our development teams to get approval from their responsible business owner and manager upfront to submitting the outbound open source request. As a result we could reduce the number of mandatory process steps in our new outbound process from 6 to 4. But we still had to solve the problem of the different tools involved in the process and the tool breaks between them. That is why we did a second workshop to find a better solution for the tooling. For the new tooling to support our process we defined the following list of requirements. First, there should be no tool breaks at all between the tools. Second, the tool must support collaboration for several colleagues to work on the same request at the same time. Third, for everybody involved in the process it must be possible at any point in time to review and see the current status of any request. Fourth, it must be possible to do reporting and analytics on our process so that we are able to measure maximum and average end-to-end process execution time as well as the duration of single process steps in order to find out if some of them are taking still too long and might require further fine-tuning and improvement. Fifth, the tool should be designed with our customers. That means with our developers in mind and ideally they should already be familiar with it so that they don't have to learn a new tool. Six, the tool should cover the whole process end-to-end. And seventh, ideally the tool should also be already in use at SAP. Given this list of requirements we came to the conclusion that our existing GitHub Enterprise system would be the best solution. It already fulfilled all of the requirements and would only require us to build some lightweight analytic dashboards on top of it. Of course, GitHub Enterprise is not a workflow engine per se. That's why we needed to come up with some definition and conventions of how to map our end-to-end process and workflow steps to GitHub concepts and entities. In our Enterprise GitHub we have a special outbound process organization where we model each and every outbound request as a separate GitHub repository which gets the name of your outbound project. Each repository then can contain all the documents on communication relevant for the respective request and for the final approval decision. As each outbound request requires multiple process steps and workflow steps where multiple people have to be able to work on it at the same time, we are using GitHub issues within the different request repositories to model the workflow steps. The colleagues from the development team and from the Virtual Ospo team who are required to work on the individual workflow steps are modeled as assignees to the recording issues inside of the GitHub request repository. So how does this work now in action? Whenever a team wants to submit a new outbound open source request they open our Ospo request repository and create an issue there for their new outbound request. They have to text this issue as an outbound open source request so that a GitHub action can automatically pick up the issue and then create an according outbound request repository with a project's name. The GitHub action creates a new outbound request repository by copying our outbound request template repository which contains on the one hand the assignees from the Virtual Ospo team that will work on the request and on the other hand a set of issue templates which represent all the possible outbound process workflow steps. Over the lifetime of the new request repository then all the documents that are relevant for the request and all the issues that are created to represent the different workflow steps will be also stored inside this repository. Now let's see this in action by having a look at our actual GitHub Enterprise system. Let's say I'm a developer in a team that wants to publish their project as open source. In that case I would go to the Ospo organization in our internal Enterprise GitHub into the Ospo request repository where we in general collect all the requests coming to Ospo, be it outbound open source requests or anything else. In this case I would have to create a new issue of type outbound open source request. So by pressing get started here I'm presented according issue template and all I have to do now is to enter the name of my designated open source project and then to submit my request by pressing the submit new issue button. As you can see our GitHub action automatically detected this issue and created the according outbound open source request repository for me which I can now open using this link. As you can see there is exactly one issue inside of this repository so far and this issue is exactly representing the first step of the new outbound open source process. So as a member of the development team I now would have to fill out the request form for our new outbound open source request by just clicking on it. I would then go into edit mode for this issue in order to fill out the 15 questions of the outbound open source request questionnaire. It starts with entering my name, the name of my product owner, the title of my contribution and project, a brief description of the functional scope of the project providing business reasons of why we want to contribute this project as open source to the open source community in case you're a specific deadline to be met or is it a deadline? Then it's asking me if I just want to publish my source code or also binaries for instance on Maven or NPM public repositories in my case it's just GitHub and then it would also ask me certain questions about intellectual property rights or for instance about export control. In this case for the sake of the example I'm entering that I'm using cryptography in my project but that I'm not processing any personal data. Now that I have finished the questionnaire I just have to save my changes with the update comment button and then I would leave an additional comment there as a trigger for the OSPO team to look into it. How would an OSPO team member now be informed about this new outbound open source request? For that we have created a Grafana dashboard on top of our Enterprise GitHub. The dashboard marks the new open source request as read because of the fact that it is not yet assigned to any member of the OSPO team. As an OSPO team member I can now just click on the recording line in the Grafana dashboard to open the respective request repository and assign it to myself for further processing. The next step for me as an OSPO member would be to schedule a meeting with the requesting development team to review their answers to the questionnaire and then based on their answers to initiate the next workflow steps. For instance, the code scanning step or an export control classification step. So in summary, with the new outbound process and tooling what did we achieve so far? We are getting very positive feedback from our engineers because they like the fact that the tooling is completely based on GitHub and that we are providing complete transparency to them at any point in time of the end-to-end process. In addition, the collaboration between the different OSPO team members and the development team members significantly improved due to the fact that we now have a single tool for the whole end-to-end process and no tooling breaks in between. Most important of all, we have been able to reduce the overall end-to-end processing time significantly. On average, the duration between the initial request and the publishing of the code on public GitHub decreased by 70%. In the past, normally the process itself has been the bottleneck, but now the preparation work for publishing your code and documentation and sample code on public GitHub by the dev teams is a new bottleneck. So does it mean that we are done now? Of course not. As I said in the beginning, our OSPO work is all about continuous improvement. Accordingly, we are planning further automation of our new outbound open-source process. For instance, we want to develop a self-service for repository creation on github.com and we also want to develop a new linter tool to check our repository for adherence to our SAP-specific rules and guidelines. In case you would like to learn more about SAP Open Source, I encourage you to subscribe to our new podcast series called The Open Source Way, which is available on open SAP podcasts, Google podcasts, Spotify and of course also on iTunes. If you want to stay up to date with all things open source at SAP, then please follow our Twitter channel. With that, I would like to thank you for your attention and I hope to see you soon again in person once this COVID crisis is finally over. Thank you and goodbye.