Recently, two colleagues and I presented SAP’s open source outbound process at the GitHub Enterprise Roadshow in Munich, Germany. As we received feedback that quite a few companies face similar challenges, I decided to write this blog post to share our lessons learned and some of the reasons for our success.
Since its foundation in spring 2018, the SAP Open Source Program Office (OSPO) put a lot of effort in simplifying SAP’s open source outbound process. With an OSPO in place, there is a central organization for open source related topics at SAP. Working together under the umbrella of the OSPO encouraged the various teams involved in the outbound process to collaborate and streamline the process steps and find the right tooling. I am excited to announce, that we were able to reduce the processing times for open source outbound requests by 70% within the last two years. So, what exactly led us to be successful?
We have up to seven teams, primarily from risk management and compliance, involved in our process; for example, from Global Licensing, Patents, Legal as well as Export Control and Data Protection. To clearly define, which team needs to be consulted at what point in time, we held a workshop with all relevant parties. We agreed that a good way to manage the involvement of different teams was our request form. This form needs to be filled by the requestor to start the process. All involved colleagues mutually defined the request form to make sure we ask the right questions and still keep the form as short as possible. These questions are set up in a way to indicate if there are any risks associated to the open source outbound request. If increased risks are indicated, the relevant team will be involved.
It is one thing to identify who needs to be involved, but how to work together is another key question. The aim was to collaborate and communicate efficiently and in a transparent way, without duplicating information. We quickly realized that to satisfy all these needs, we had to find a tool to support our process end-to-end. We tested different tools under these conditions and found GitHub Enterprise was the best fit. One reason for this decision was that this tool was already in use within SAP. Colleagues (developers) were familiar with it and we did not need to introduce yet another tool. We set up GitHub Enterprise to handle each contribution request via one repository. Within this repository, we create issues, while each issue represents one process step. This allows us to involve colleagues only in issues relevant to them, while the requestor can track the status and provide details if required. Another plus is the automation possible with GitHub Enterprise. By making use of issue templates, we do not need to repeatedly write the same issues for different outbound requests. We created the templates once and now reuse them for every request we process. Recently, we even introduced the automatic creation of the repository. The requestor only types in the name of his/her open source project: this triggers the creation of a new repository and in addition, the first issue is already visible and assigned to the requestor. This shows that with the support of GitHub Enterprise, the process is now very light weight for both sides, the requestor and the processor.
One reason for the long processing times was risk management, as the protection of IP is very important to SAP. At the beginning, this resulted in looking into every single detail of an open source outbound request no matter if it was about a new SAP open source project or just a small contribution to a third-party open source project. It is obvious that this was very time-consuming. Soon, we realized that this was not necessary since despite the extensive check, we did not reject a single request for a contribution to a third-party open source project. We decided to empower our developers and give them clear guidelines for contributions to a third-party project. They can start their contribution right away without having to wait for an approval, as long as they follow the guidelines, inform their direct manager and make sure there is a business reason for the contribution. With this approach, we are confident to have the right balance between managing risks and a lean and scalable process.
All these changes have helped us reduce our processing times. But there’s another positive effect: Since the process is now easy, fast and transparent, we receive many more open source outbound requests. During 2019, SAP has started around 80 new SAP open source projects and is more active in the open source community than ever! If you want to know more, check out our strategic open source projects on our landing page.
Since its foundation in spring 2018, the SAP Open Source Program Office (OSPO) put a lot of effort in simplifying SAP’s open source outbound process. With an OSPO in place, there is a central organization for open source related topics at SAP. Working together under the umbrella of the OSPO encouraged the various teams involved in the outbound process to collaborate and streamline the process steps and find the right tooling. I am excited to announce, that we were able to reduce the processing times for open source outbound requests by 70% within the last two years. So, what exactly led us to be successful?
- Get the relevant people together and ask the right questions
We have up to seven teams, primarily from risk management and compliance, involved in our process; for example, from Global Licensing, Patents, Legal as well as Export Control and Data Protection. To clearly define, which team needs to be consulted at what point in time, we held a workshop with all relevant parties. We agreed that a good way to manage the involvement of different teams was our request form. This form needs to be filled by the requestor to start the process. All involved colleagues mutually defined the request form to make sure we ask the right questions and still keep the form as short as possible. These questions are set up in a way to indicate if there are any risks associated to the open source outbound request. If increased risks are indicated, the relevant team will be involved.
- Communication and Automation – find the right tooling
It is one thing to identify who needs to be involved, but how to work together is another key question. The aim was to collaborate and communicate efficiently and in a transparent way, without duplicating information. We quickly realized that to satisfy all these needs, we had to find a tool to support our process end-to-end. We tested different tools under these conditions and found GitHub Enterprise was the best fit. One reason for this decision was that this tool was already in use within SAP. Colleagues (developers) were familiar with it and we did not need to introduce yet another tool. We set up GitHub Enterprise to handle each contribution request via one repository. Within this repository, we create issues, while each issue represents one process step. This allows us to involve colleagues only in issues relevant to them, while the requestor can track the status and provide details if required. Another plus is the automation possible with GitHub Enterprise. By making use of issue templates, we do not need to repeatedly write the same issues for different outbound requests. We created the templates once and now reuse them for every request we process. Recently, we even introduced the automatic creation of the repository. The requestor only types in the name of his/her open source project: this triggers the creation of a new repository and in addition, the first issue is already visible and assigned to the requestor. This shows that with the support of GitHub Enterprise, the process is now very light weight for both sides, the requestor and the processor.
- Trust your developers – Guidelines over process steps
One reason for the long processing times was risk management, as the protection of IP is very important to SAP. At the beginning, this resulted in looking into every single detail of an open source outbound request no matter if it was about a new SAP open source project or just a small contribution to a third-party open source project. It is obvious that this was very time-consuming. Soon, we realized that this was not necessary since despite the extensive check, we did not reject a single request for a contribution to a third-party open source project. We decided to empower our developers and give them clear guidelines for contributions to a third-party project. They can start their contribution right away without having to wait for an approval, as long as they follow the guidelines, inform their direct manager and make sure there is a business reason for the contribution. With this approach, we are confident to have the right balance between managing risks and a lean and scalable process.
All these changes have helped us reduce our processing times. But there’s another positive effect: Since the process is now easy, fast and transparent, we receive many more open source outbound requests. During 2019, SAP has started around 80 new SAP open source projects and is more active in the open source community than ever! If you want to know more, check out our strategic open source projects on our landing page.
- SAP Managed Tags:
3 Comments
