Effective Decision-Making Strategies for Open Source Risk Management and Sustainability
Interview with Sebastian Wolf
In this edition of our newsletter, we are excited to introduce a new interview format for the first time. In this engaging conversation, I will be posing a series of questions to Sebastian Wolf, delving into the intriguing topic of Open Source sustainability. Sebastian is a member of the Open Source Program Office of SAP.
.
Sebastian what are the responsibilities of an Open Source Office?
The main aspiration of the SAP Open Source Program Office, or short “OSPO”, is to support and advance SAP's open source strategy. As the Linux Foundation puts it, a central open source program office is "a designated place where open source is supported, nurtured, shared, explained, and grown inside a company". The SAP OSPO is organized as a virtual team that works on all open source related topics such as policy, processes, tools, scanning, and security. Our mission is to build an open source environment at SAP that enables our developers to live our open source strategy. Last, but not least, we want to position SAP as a strong player and contributor to open source, build a communication strategy and create a positive perception in the market to attract the best talents.
Why is Open Source sustainability important for software development and SAP?
Well, let’s maybe first have a look at the definition of “Open Source sustainability”. From my perspective, sustainability perfectly represents the approach to software development that especially we at SAP have been following in the past decades. Our customers are relying on the commitment of SAP that all software artifacts they are licensing or subscribing from us are maintained not only for 1-2 years, but for a very long time. They are doing a huge investment when they decide for an enterprise software vendor, because they run their company with our software, implement extensions and potentially also adapt their business processes. That’s nothing you do if you expect substantial changes or disruptions to this software infrastructure soon, so their investments need to be protected. We need to ensure that SAP software runs, is updated, maintained, and supported in the long run. As most of our solutions either directly contain or somehow depend on open source software, open source sustainability is of vital importance to our business.
Can you explain your role and the role of the OSPO in promoting Open Source sustainability?
As member of the OSPO a vital component of my work is it to ensure that at SAP both the use of open source components as well as contributions to open source projects are done in a compliant way that doesn’t sacrifice long-term considerations for short-term benefits. Ideally, both short-term and long-term goals are equally considered when it comes to the question of which open source components are we using and to which of them our teams here at SAP should ideally contribute to and how. If those principles are neglected, we face potential risks in several areas in software development because virtually all our products and services use open source in one way or another. To lower these risks, for instance in software security, licensing or community health is key for sustainability in open source. That’s why we’ve even introduced a company-wide policy that provides mandatory guidelines for all SAP employees for open source contributions or consumption.
Can you discuss the OSPO’s decision-making guidelines for assessing potential risks of Open Source projects?
We clearly distinguish between the two use cases of consuming open source projects and of creating or contributing to open source software with specific guidelines and criteria for these cases. What both processes have in common is the goal to minimize the risks for SAP’s business. For the contribution part we need to ensure that we are for instance not cannibalizing our commercial products and services with the open source release of a certain project, that we don’t accidentally release secret information, and that the project is maintained properly. For the consumption part, we pay special attention to the license of the respective open source project by assigning special risk profiles to each one. Permissive license such as Apache 2.0 are classified as low risk to our business while copyleft licenses such as AGPL are categorized as high risk because they may require the release of our commercial components under the same license. In addition, we also pay special attention to the security risk profile of the project that is supposed to be integrated in an SAP product or service. Open Source projects that show delayed or even missing fixes to critical vulnerabilities are of course assigned a higher security risk than those that fix their issues within a reasonable time frame. Other important risk assessment aspects are community health, i.e. does the project receive frequent contributions from various sources or not. Especially the aspect of “various sources” has become more and more important in the recent time as some open source projects changed their licenses due to the single owner and contributor wanted to commercialize the project.
What is the relation between sustainability and the commercialization strategy of Open Source? What are the challenges and opportunities you see in the commercialization of Open Source projects? What are different commercialization strategies? And what are the implication for maintainers and community?
For consumers of open source projects, the just mentioned commercialization strategy, i.e. to start a project as open source, become big and then change the license from a permissive open source license to a restrictive one, is certainly one of the most challenging ones. Software vendors leverage the new license to drive consumers to obtain a commercial license as the new open source (or source available) license is not compatible with the business model of many consumers. Of course, such a decision also poses a threat to the project itself, especially if being open source was one key aspect of the project’s success. Community members might start a fork that could jeopardize the business of the original maintainer of the project, or consumers might look out for alternatives and start migrating to other projects. In the end, such a commercialization strategy could lead to the opposite result if not executed carefully. On the other side, commercialization is key to the success of many open source projects as they need a solid revenue stream to build new features, to fix bugs or to simply keep the lights on. Some build their business model around consulting or training for open source projects, others choose an open-core model and make money by selling for instance enterprise-focused features, or components to customers while the core (often referenced as “community”) edition remains completely free. No matter which way the maintainers go, they all need to balance the interests of their business with the interests of their consumers and the community/third-party contributors to the open source project.
When a software engineer or software architect needs to decide between different Open Source projects, what are the most important criteria to consider?
Of course, the most important aspect is that the chosen component solves the problem that you have, the reason why you are looking for a third-party component. But of course, that’s independent of the component being open source or not. So maybe let’s focus on the question which one to choose if you have a set of only open source components on your shortlist for the task that you want to address. I already mentioned some of the most important criteria in an earlier answer. From our perspective, the used license, the handling of security vulnerabilities, pull requests, and reported issues, as well as the overall community health are probably the top criteria to consider. However, recently the aspect if open source projects are dominated by single companies has become much more important. Several of them changed the license to a very restrictive one with the main goal to motivate consumers to purchase commercial licenses. Of course, such moves can only be done by vendors that do most of the critical contributions themselves and have a dominating position in a certain market, i.e. you don’t have many alternatives that you could easily switch to. Therefore, avoiding such lock-in effects is becoming more important. Mitigation strategies are not always easy, but you can try to pick components that are owned by open source foundations and that see contributions from diverse sources.
How important is it for users of Open Source projects that these projects are hosted by a foundation?
There are several aspects why people choose components that are owned by open source foundations – if they have the choice. The most important one is probably that you avoid the lock-in effect that you might run into if you choose an open source project that is dominated by a single company. In addition, a foundation also gives you a higher probability that the respective component is maintained in the long run, or in other words that your investment in choosing this component is more sustainable than it is for other alternatives. The fact that such projects are run by a broader community with corresponding influence on the decisions for the project also contributes to that. Moreover, if a project was accepted by a foundation, it usually already underwent a certain vetting process to prove that the code quality is good, that the functionality is working properly and that the release processes are aligned with industry standards. Especially, in the enterprise context these non-functional factors are often as important as the functional ones. That’s also why companies like SAP are also members of several open source foundations.
In case an Open Source project changed its commercialization strategy and licensing. When is forking it a viable option? And what are different strategies for doing so?
Yes, it’s certainly a viable option, but the decision to go that way needs to be well thought through. Forking is not a one-time effort, because you need to ensure the resources for development, maintenance, and all other aspects of software development, ideally for a long time. Of course, you need to secure the budget for such a move which might be difficult if you are just on your own. A different strategy could be to team up with other companies, ideally in an open source foundation. If that’s not possible you need to evaluate all viable alternatives – others might be more cost-efficient such as the migration to another component, or to purchase a commercial license from the vendor.
What future trends do you foresee in the Open Source ecosystem, particularly in relation to commercialization, lock-in effect, and venture capital influence?
There will certainly be a higher pressure on companies to monetize their open source projects, especially if these projects are de-facto standards in their domain or simply have a high market share. That makes it hard for users of these components to migrate to alternatives – this is the lock-in effect that we discussed. Investors in these companies probably want to leverage this lock-in effect to make money on licensing or subscriptions. But also, project maintainers that are more independent from venture capital influence are increasingly facing a lack of contributions. Without contributions, a central part of the “contract” in open source, the idea of give and take, is out of balance. This could also force maintainers to make money with commercial licenses – to fund the development.
How does the OSPO adapt to these trends to ensure the sustainability of Open Source projects?
We adjust our selection criteria and risk assessments based on these developments and provide concrete recommendations to our development teams. Moreover, we plan to scan for the usage of open source components that are dominated by a single company, only see contributions from a single party or may otherwise come with a higher risk for such license changes.
What are emerging external factors on decision making for Open Source components?
Besides the already mentioned trends in the commercialization of open source projects, another important factor is the trend to regulate the software industry by several governments. The so-called “Executive Order on Improving the Nation’s Cyber Security” in the United States or the planned “Cyber Resilience Act” in the EU mean a significant shift in the software industry, especially in improving the security within the software supply chain. Such regulations force software vendors to guarantee support, ongoing security updates, etc. There are plans to introduce exceptions for certain open source projects, but many details are still unclear – including the implications for consumers of open source projects. Therefore, this will constitute a significant influence factor on the question which open source projects can be used and how.
Where can the community find more about SAP’s engagement in Open Source and the work of your OSPO?
Simply check out
Subscription: If you want to get updates, you can subscribe to the free newsletter:
Mark as not spam: : When you subscribe to the newsletter please do not forget to check your spam / junk folder. Make sure to "mark as not spam" in your email client and move it to your Inbox. Add the publication's Substack email address to your contact list. All posts will be sent from this address: ecosystem4engineering@substack.com.
❤️ Share it — The engineering ecosystem newsletter lives thanks to word of mouth. Share the article with someone to whom it might be useful! By forwarding the email or sharing it on social media.