Long ago, we stopped questioning if open source should be adapted into mission-critical systems, and rather talked about how best to use it. It is this experience that allowed us in more recent years to focus on defining enterprise-wide open source best practices in order to drive reuse rather than fragmentation, and to systematically drive software security, long-term support and engagement with the open source community.

Being a vendor of enterprise applications comes with a number of responsibilities, since customers expect – in addition to the right functional scope – a clear commitment to usability, quality, reliability, and, last but not least, security. So, essentially the same commitment needs to cover open source products we integrate into our product portfolio or choose to interoperate with.

This is one of my priorities at SAP, and I’d like to hear your input.  Please feel free to leave a comment, below, and join me on February 14 for my webinar, Success Factors for Open Source Adoption.

A version of this blog was originally posted on the SAP Community Network.

At SAP, we use open source software where it supports development goals and customer needs. We look to OSS to create new value. Our customers benefit, for example, from increased interoperability and choice, from protection of their investments in technologies and skills, or from reduced IT operational costs.

It’s really economics 101: as long as the benefits outweigh the cost, SAP will use open source technologies. We make a series of commitments in all our development; if we distribute code to our customers, we are responsible for addressing any issues that might arise. This means we need to know the code to ensure, for example, security requirements are met. We also commit to supporting and maintaining the software throughout the product lifecycle.

Where we add features or simplify supportability of open source code, we make a second commitment: we pledge to actively engage in the open source project. We do this to avoid creating forks, and also because we benefit from working with the open source community.

A third commitment comes from scenarios where open source technologies interoperate with SAP technologies; we need to ensure interoperability.

Perhaps the most significant commitment we make when using open source is knowing what’s in our code. SAP is a serial acquirer. When we research a candidate for acquisition, we analyze the code base using tools and services such as the Black Duck Software’s Code Center, which is part of the Black Duck Suite. In cases where an acquisition is in process and we don’t have access to the code base, we have a third party (Black Duck Software) run the scan. We’ve done ~16 acquisitions since 2007 – including Sybase – and have scanned thousands of components. From a business and ethical standpoint, it‘s a necessity to scan – the cost and effort is well worth it. We want to be a member in good standing of the open source community. Knowing what’s in our code is part of that commitment.

This commitment also protects our in-house development. Demand for increased development productivity was actually the key driver for SAP to adopt a systematic, value-driven approach towards open source that allows us to be a much more natural citizen in the open source community.

Any open source technology we embed in our product line needs to comply with our product quality requirements, security requirements, and license obligations. To ensure we meet these objectives, we manage the use of OSS closely, benefitting our developers as well as our customers.

While this fairy tale is a radical simplification of the political, philosophical, legal and economic debates that happened during and after the terms free and open source software were coined in the 80s and 90s,  it leads to one of the main pain points that software users encounter today. Obviously, not all software is or will be open source software. And the same holds true for closed source software, i.e., software that does not comply with the open source definition. Which is why, in almost any enterprise-level software project, users procure software of both types and want to build a complete solution out of the individual pieces. Good luck if the closed source developers don’t talk to the open source developers (and vice versa)!

In practice, this means two things.

First, software users need procurement policies that encompass both closed source software and open source software. Since software is not “good” software just because it is developed or licensed the one way or the other, these policies need to compare business requirements with software qualities when it comes to selecting software products. And users should request the developers of the software to make it run together.

And second, software developers (including ISVs) need to take more care when it comes to interoperability between open source software and closed source software. Ultimately, users decide what software they adopt. The better developers enable users to build complete solutions out of a diverse portfolio, the easier and faster users will be able to realize business value. Without such an approach, many users will suffer from non-existent interoperability and need to focus on getting IT work instead of focusing on how to better align business with IT.

For a few years now, SAP has taken a value-based approach towards interoperability with open source software. In many cases, open source software can complement SAP software, and the better we understand customer scenarios and requirements, the better we can support them by talking with the partners and developers that engage in the open source community. Strategies like this help ensure companies with similar policies live happily ever after with software development.

To see more on what has been done already, get regular updates and/or provide your own feedback, please visit the open source page on the SAP Developer Network.