In the first episode, I shared my overall impressions from the SAP Open Source Summit 2012. Now I want to share key parts of my own presentation, which mostly focused on the corporate open source strategy, its reasoning and how we operationalize it.
First of all, there is no room for a stand-alone open source strategy. To make sense, it clearly needs to support the overall product strategy. Secondly, it needs to allow us to gain something, for example, to increase development productivity or create more value-added features. Otherwise, we could all live a not invented here syndrome and develop all our products in a completely proprietary manner. And thirdly, it needs to executable without compromising our product standards and quality goals.
Let’s now explore the strategy itself. It centers around three dimensions: usage of open source in SAP products, contribution to open source projects, and interoperability with open source technologies. The picture below says it all.
That’s it. Pretty straight-forward. Essentially, it describes what we are doing for quite some time in some areas already. No big surprise. But now it is written down, explains the business benefits and we can focus on its execution. Of course, there are a number of questions. What does “proven, broadly adopted” mean? When exactly should we contribute to open source projects and which parts of our products? And which interoperability scenarios are important from our customers’ perspective?
O.k., let’s focus on the execution and see how we can answer the operational questions. Here are four strategic recommendations providing more guidance on how to execute the strategy.
Looking a few years back – when open source at SAP was managed as an exception – I can say that this is pretty much a 180° turn of guidance. Of course, there can be many reasons why an open source product is not the right choice. It may not be a good functional fit or expensive to make it fit. There might be doubts about the future of the project. The open source license may not be compatible with the intended use case. But if such key questions can be answered positively, the use of open source is the better economic decision for the reasons mentioned above.
Here is recommendation #2.
In the majority of cases, the open source software embedded in SAP product doesn’t need any modifications. This is due to the fact that we always analyse the maturity of the software and determine the adoption rate in the industry. But sometimes, there is a need to fix a bug and modify or enhance the software. In those cases, it would be a mistake to keep these changes proprietary. This is where Mike Milinkovich would say “keeping it proprietary is not an asset – it is a liability.” It is econmically the better choince to contribute the changes back to the open source project so that they can be included in the next version of the original open source software. This significantly reduces the cost of reintegrating the newest version of the open source software. And it – through our active participation – protects the future of the open source project and helps avoiding the “tragedy of the FOSS commons” as identified by Schweik and English in that open source software can only be successful if there is continued contribution from diverse sources.
This covers contributions to existing open source projects. But what are the factors to determine when to start a new open source project? This is what recommendation #3 is all about.
Like in recommendation #1, this is a major turn in our approach to open source (compared to a few years back). When in the past, every single line of proprietary code was considered to be intellectual property that by all means needed to be kept proprietary, we now do a much more comprehensive cost-benefit analysis and include benefits such as protection of investments through standardization and utilization of external contributions. Software components that are not SAP-specific and non-differentiating can actually benefit a lot from being made available as open source – we can simply avoid to compete with our proprietary approach in cases where competition increases cost (instead of increasing revenues). The level playing field created by providing the software as open source invites others to join us in making the software more relevant in the future. The Eclipse Memory Analyzer was the first official open source project created by SAP under this new approach (of course, SAP DB / SAP MaxDB was open source for many years before) and allowed us – in this case – to join forces with IBM and others to make it work on other Java Virtual Machines, for example.
Taking contributions to existing projects and creation of new projects together, SAP developers contribute to more than 50 open source projects. A selection of contributions is listed at this SCN page.
Finally, recommendation #4 covers interoperability between SAP and open source technologies.
In many cases, SAP customers already use open source technologies in their system landscape and may even have built up skills on how to use, administrate or develop with the open source technology. Considering those cases, it makes a lot of sense to illustrate our customers on how to use such open source technologies in combination with SAP technologies to eventually reach a more complete solution portfolio and protect our customers’ investments in the open source technologies. Consequently, we work in various areas to reach a higher level of interoperability between SAP and open source technologies, partly combined with contributions to the respective open source projects. Even in the case of SAP HANA (see picture above), a number of open source technologies – like the statistical computing library R or the distributed and “big data” computing technology Hadoop complement our offering.
I believe this is enough food for thought for today and look forward to your feedback.
In terms of the SAP Open Source Summit 2012 blog series, here is the plan again: