A few days ago, Rui Nogueira The role of Open Source in SAP's Technology Strategy me on how open source supports the SAP technology strategy. A good reason to continue my blog. Which I am doing way too rarely. This time, I was almost on my way to title the blog post “Statistical errors or how Rui made me speak”. Yes, Rui made me speak. But why statistical errors? Because almost any time I used the terms statistic or statistical, I created a knot in my tongue … But watch yourself.
Radically simplified, our technology strategy can be stated as “Go mobile – go cloud – go in-memory”. At a first glance, this does not sound very compelling because all the industry is moving in these directions. That’s why we actually don’t look at technology for the technology’s sake, but for the sake to create new value from a business application perspective. How can our customers benefit from these technologies when applied to existing applications? Can they reach new users? Reduce their cost of IT operations? Decrease time-to-decision? And, perhaps more importantly, how can our customers benefit when applying the technologies to build new applications? Using Technology Strategy at SAP Part 1 and 2 words: “What types of applications can be built that could not have been built before?” How can consumer products companies connect to consumers using mobile devices? How can the airline industry optimize their flight schedules for the benefit of every airline using a joint on-demand solution? How can hospitals better react to demand changes initiated by external events using an in-memory application that crunches billions of patient records?
But what role does open source play here? An important one. And one that I also like to explain along a number of values. We have identified areas where open source software can systematically support our and our customers’ needs. Note that open source software is not better software just because it is open source. But in many cases, it does come with a number of benefits, depending on the use case. Here are four typical values:
First value: Reduce TCO
SAP supports SAP on Linux. This not only offers more choice for our customers, but also allows them to retain their Linux operation and administration skill sets in SAP environments such as SAP Business All-in-One. Many customers have migrated from a given UNIX distribution to Linux since Linux is a reliable and cost-effective operating system. Thus, the cost of migration paid off rather quickly. But Linux (and, thus, open source) also plays a key role in SAP’s on-demand offering as being the default operating system in the SAP cloud that runs SAP Business ByDesign. The same benefits apply – Linux’ reliability and cost-effectiveness allows SAP to offer Business ByDesign with an excellent service level agreement at a competitive price.
Second value: Reach More Users
If we want to reach more users, we can’t ignore open source technologies. And essentially, more and more the users (in the role of consumers or employees) decide which technologies to choose. Mozilla Firefox needed quite a number of years to reach a reasonable market share. Android was already much faster - note that the Open Handset Alliance was established by Google in November 2007, less than 3 ½ years ago. And, depending on the information source, Android is becoming or has already become the most adopted mobile operating system. As a consequence, if our customers and their users choose the client technologies they want to use, we need to make sure that these technologies can interoperate with SAP technologies so that a seamless interaction between mobile applications and SAP business applications becomes the norm.
Third value: Utilize Innovation Outside-In
The same holds true if we want to get an attractive content offering for these users. We simply can’t develop all mobile and Web applications, and, thus, need to work with and rely on partners as well as developer communities. Established and emerging scripting languages such as Python, PHP, Perl, and jQuery have large developer communities and we are much better off to allow them to innovate on top of the SAP platform. We do that, however, not by requiring them to learn SAP proprietary technologies but by allowing them to develop applications in the development environment they are familiar with. The trick is to establish connectivity to and interoperability with such environments through SAP Gateway, for example. The same will hold true for SAP HANA. While SAP and SAP partners are developing a number of HANA applications for various industries and application scenarios, we will at some point in time need to support the development of hundreds and thousands of such applications, including their adaptation to specific needs of individual customers. And the better we integrate HANA with existing third-party tooling like R, the statistical programming language and environment, the better we and our customers can utilize the many statistical algorithms the community of R developers has created and enhanced over time. Yet another approach on how to utilize innovation from the open source community in combination with SAP technologies.
Fourth value: Increase Development Productivity
The demand for increased development productivity was actually the key driver for SAP’s new approach towards open source software. While it is hard to estimate this in terms of saved person days, it simply does not make economic sense to develop SAP proprietary technologies if mature and well-adopted open source technologies exist. This is the main reason why the Next-Generation Java Platform consists of a vast number of open source technologies. In addition, the Java Platform team has evaluated a lot of open source development tools and methodologies that are needed for the distributed development approach often used for open source software. The Java development teams at SAP already make use of such tools and methodologies, which is another good example for how open source software helps streamline our own development process.
In both cases, there was often a need to fix bugs, add enhancements or integrate otherwise stand-alone technologies. Many or even most of such changes and enhancements are non-differentiating, that is, we don’t compete with the rest of the industry on these changes. And we don’t make money just with these changes. This is why it often makes economic sense to contribute them to the open source community and the projects that developed the original open source software. Not doing so would actually have a significant opportunity cost. Not only would we need to reapply the changes to every new version of the open source software. We would also risk that someone else would implement and contribute a similar feature that we eventually would need to comply with later by costly changing our proprietary implementation. Consequently, contributions to open source projects help standardize our investments and ensure continued innovation for the open source technology.
In some cases, it might even be reasonable to initiate new open source projects. The same logic of protecting our investments by standardizing our implementation applies, but it is certainly harder to ensure the success of the open source project since we first of all need to find committers and users from others, be them individual developers or other software companies. Fortunately, there are already a few cases where the product teams have been able to drive adoption through going open source. The often mentioned Eclipse Memory Analyzer was originally proprietary SAP technology. Going open source had the nice effect to create a level-playing field and convinced IBM to also support the technology on their own Java VM and hardware environments.
No value without commitment
One thing is clear: value does not emerge automatically. Or in other words, open source is not for free. Any open source technology we embed in our product line needs to comply with our product quality requirements. First commitment: if we distribute it to our customers, we are ultimately ressponsible to address any issue that might appear. Thus, we need to know the code simply to make sure that, for example, our security requirements are met and that we can ensure to support and maintain the software throughout our products' overall maintenance schedule.
We do often apply bug fixes or enhance the open source software to add certain features or ensure its interoperability with other technologies. In these cases, there is a second commitment: we need to actively engage in the open source project. Not because of the license obligations, but to avoid that we create a fork from the standard. The fork would become more and more expensive to maintain. But the engagement with the open source community also has its price. Fortunately, over the last 2-3 years, we have gained quite some experience from working with the open source community in various areas.
And the third commitment comes from scenarios where open source technologies interoperate with SAP technologies: we need to ensure interoperability. Typically on our end. Taking Gateway as an example, if the invocation of a REST-based service provisioned through Gateway fails, we need to fix any issues that might occur between Gateway and the underlying SAP application. But we might also need to work with the open source community to, for example, build, adapt, and drive adoption for an OData SDK for jQuery so that jQuery developers can also develop apps that consume SAP through Gateway.
Economics 101: as long as the benefits outweigh the cost, we can utilize open source technologies. And we do that in a way that they support our technology strategy.
