Skip to Content

Welcome to the last episode about the SAP Open Source Summit 2012. In the first three episodes, I shared my overall impressions, key parts of my presentation on the corporate open source strategy, and insights from guest keynotes, respectively. Now I want to finish with a few areas that we are focusing on next.

Given that we now have an open source strategy in place at SAP, the focus is now much more on execution. Whenever you want to execute a strategy, you may however run into a number of challenges – be they of a technical, organizational or procedural nature. Specifically with regard to the much stronger use of open source and contribution to open souce projects, we have found four major types of challenges. These are reuse and versioning, alignment of release schedules, product security and long-term support as shown in the slide below. I used this slide also in my keynote last week at ApacheCon Europe 2012 to illustrate key challenges for managing open source from an enterprise perspective.

ApacheConEurope_Keynote_CvonRiegen.png

  • Reuse and Versioning
    If you focus on a given open source foundation like the Apache Software Foundation or the Eclipse Foundation, it is very likely that due to the nature of the foundation’s development processes there is not much overlap between the various open source technologies. But open source projects today in many cases start somewhere else and don’t necessarily follow a defined governance model. This is good since it is more flexible and allows the emergence of many different ideas. For example, GitHub today has almost 4.3 million projects. But the lack of coordination is also a challenge in that it becomes more difficult to find the right technologies and to understand their level of maturity and adoption. And it increases the likelihood of overlapping and similar technologies. This is not necessarily bad, but it can become a management challenge of open source adoption in the enterprise.

    One particular challenge in this regard is that different product teams might choose different technologies for the same purpose. The integration of, for example, four different open source XML parsers into our product line can result in maintenance overhead – four different technologies need to be maintained over the course of the products’ support schedule. Another challenge is the selection of the right version of the open source technology. Even if all SAP product teams agree to select the same open source XML parser, they may have done so over the course of a few years and have chosen different versions of that XML parser. It is preferable to use only one version – and actually the most recent stable one – for all products because it also minimizes the risk to miss important security bug fixes in newer versions. But the upgrade might get complicated, for example, if the XML parser’s APIs that were used to integrate it into the SAP product, have changed incompatibly.

  • Release Schedules
    The adoption of the most recent stable version of an open source technology is a reasonable goal to pursue on its own. But since the release schedules of the open source technology and the SAP product are not the same, this is not necessarily an easy task and some updates of the embedded open source technology might become necessary after the SAP product has already been shipped. There are some exceptions like the Eclipse Foundation that has decided to deliver one stable release of the Eclipse Platform once per year – this simplifies the planning exercise and allows us to, for example, develop a stable Eclipse release train SAP-internally on a yearly basis. The whole exercise can get more complicated when SAP is an active contributor to the open source project. By no means is there a guarantee that the extensions we developed SAP-internally will be adopted without any changes by the open source project lead and in time before the SAP product is being released to the market. This means that we sometimes need to live with a fork of the open source technology. The operational recommendation is to avoid such forks and to always seek a close alignment between the open source standard version and the version embedded in the SAP product.
  • Security
    Product security and security response management for SAP products clearly needs to include a responsibility for fixing security vulnerabilitites in embedded open source technologies. On the one side – since the source code of the open source technology is openly available and used by many other firms – there are more sources for finding potential security vulnerabilities. On the other side, this results in an obligation to even more quickly respond to such findings or adopt known resolutions. Enterprise customers need to be able to patch their systems with respecitve bug fixes before it is being discussed in the public. This may sound like a paradox since further development of the open source technology happens “in the open.” But there are resolutions – the Apache Software Foundation, for example, has a process by which security vulnerabilities can be reported on a mailing list that is only accessible to the leads of the respective open source project. Until a resolution is available, the conversation continues in a private environment. The vulnerability is finally being reported publicly only at the time a bug fix has being made available. This significantly limits the risk that IT user organizations continue to run systems that are exploitable due to known vulnerabilities.
  • Long-Term Support
    SAP products are typically supported for at least seven years. Customers expect support for the complete solution, not just for the software components that were developed SAP-internally. From a support perspective, customers actually shouldn’t need to know which open source technologies have been embedded. Consequently, we need to provide a means to support respective open source technologies, including the application of bug fixes as necessary. Fortunately, the various quality checks that are being applied when selecting open source technologies at SAP radically reduce the number of necessary bug fixes. But it can never be completely avoided and sometimes it is necessary for version 3.2 when the open source project has already released version 6.0 …
    In principle, there are two main options: either to upgrade the embedded open source technology to version 6.0 or to apply a local bug fix to version 3.2. Both options can be rather complicated. An alternative is to join forces with other interested open source developers and users and to share the cost of maintaining older versions of the open source technology. SAP has long motivated such an approach for Eclipse projects. The recent establishment of the Long Term Support Industry Working Group (LTS IWG) is a good step in this direction and fortunately, a number of other Eclipse members do see the same need and have joined the LTS IWG to solve this important dilemma.

So I hope that this blog post series about the SAP Open Source Summit 2012 has been useful for you. From my perspective is was good to see a strong focus on operational excellence, knowledge sharing and applying open source development principles SAP-internally. Let me conclude with Mike Milinkovich’s words: “Open source software is really really mainstream.” And the journey will continue.

Here is the overview of the blog post series again:

  1. Overall Impressions
  2. What we think – SAP Open Source Strategy
  3. Insights from keynotes
  4. What we do next (this post)
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply