Skip to Content

SAP’s Open Source Possibilities

For years, open source software (OSS) has been quite effective at creating back end technologies, not the least of these is the Linux OS itself.  In keeping with that tradition, developments like the Apache Web Server allowed the explosion of the Internet to occur.  A dedicated group of “unpaid” volunteers is still writing Apache.  These volunteers may actually be employees of other companies, like IBM, whose sole job at IBM is to work on the Apache code base.  Yes, IBM pays its own employees to work on a project they do not sell.  However they do sell WebSphere that runs on top of an Apache Web Server.  This development model has been so successful that other OSS projects, like Firefox, are starting to use it.

Well, what does this have to do with SAP?  The entire SAP code base could be considered “open source”; by purchasing SAP you get the source code to all the application modules.  The one yet untapped resource in this is us, the SDN Community.  You are free to modify this “open source” but when you do, you may create errors in SAP’s code.  You must register the object with SAP and when something is wrong, SAP first considers the registered object as the culprit.  Imagine the power if SAP turned to the SDN community to create an army of already trained open source developers.  Every SAP customer wishes that they could have more input into what features go into the next version.  Well, what if customers that wanted to have a feature created worked directly on that feature, with some SAP support, but then gave that code back to SAP to have it rolled into an official release.  These developers would become resources of SAP for the time they worked on this feature.  Most of your management types might roll their eyes at this point and mutter something about competitive advantage.  If that person honestly does not think this information exchange is already occurring, just using a different channel namely SAP Consulting, they should have their head examined.

As customers mature in their use of SAP, their own developers would become proficient enough to start to contribute to the SAP code base.  SAP would evaluate these contributions and either accept or reject them, thereby keeping the management of their software in house.  Although they would lose some development revenue, surely they would gain more customers by offering an avalanche of features.  In addition, opening their source will allow SAP to increase their install base by providing a wider array of better software.

The only real draw back here is that SAP would lose a substantial amount of their custom development revenue.  In 2004 “Service Revenue,” which I assume includes both consulting and custom development, accounts for 111 MM Euros of income whereas, software itself accounts for 854 MM Euros.  The services area costs much more to run and loosing monies from there and gaining in software is only going to make SAP even more profitable.  Additionally, SAP might be able to reduce their total headcount of programmers by relying on the open source community to handle some new features and some more mundane development tasks.

Certainly, this would be a totally new model of software development and I believe because of historical reasons SAP is one of the few companies poised to be able to leverage these resources.  No other company I am aware of is in a position to easily take their total product catalog to a large group of highly trained, motivated developers.  The employ of their own customers to write and maintain their software would be an unstoppable power.

You must be Logged on to comment or reply to a post.
  • SAP already have a long history of colaboration with customers on technology that they see as promising, or find useful to their current strategies - you don't need to look any further than the IS solutions  - eg. IS-OIL.  The code base for these didn't start in any SAP Lab, but with the customers - scratching their own itch.

    I also think that it is important to note that SAP has had a past practice of having license clauses that state they have immediate rights over any software developed within the cotext of an SAP software package (most noteably R/3), showing that they have not failed to recognise the gains that can be made from being able reuse innovations of their customer base (is this style of contract still current practice?).


    Piers Harding.

    • Having prior one off examples of this is a good start but look a little bit past what has already happened.  If SAP were to begin leveraging the SDN community more directly and in a more organized manner, don't you think they would have an incredible advantage on say Oracle/PeopleSoft?
      • I couldn't agree with you more, but, while SAP has had in some sense an arguably Open Source model with ABAP code (something highly contained) which was unique in its time (70s, 80s, and 90s), it does not have the typical business model that goes with Open Source today, which I think provides graeter incentive for wide scale community contribution.

        This OS model is Free (as in free beer) and Open Source software, coupled with a Consulting and Services revenue stream.

        It is that kind of atmosphere fostered by Open Source projects such as those hosted by the Apache Foundation, Jabber, MySQL (a really good example) etc that work today.  Admittedly, these times are changing, and what it means to be "Open Source" will be different in the future, but nevertheless,  in the above mentioned projects - customers who contribute back source code are not, from the word go, paying royalties, or license fees, to the Vendor/Project owner, and as such (I hazzard a guess) feel like they are "giving something back" to a group who has given them so much.


        Piers Harding.

  • In regards to the weblog posted by you about the SDN forum becoming a store house of open source code, I would like to second this thought. If we look all around us, the most important change in the elemental level that is being observed in the technology domain is the growing extinction of the monopoly market. Right from Microsoft to other software behemoths are facing this threat. Customers have become more and more demanding, asking for tailor made solutions without the burden of a licence lease, they demand an outright purchase. In wake of these developments, I feel that the right way forward is to unleash the power of "code innovation",if we may call that onto open fora like SDN. Another opinion that I would like to venture here is that SAP can actually offer discounts or cashbacks to the companies whose SDN teams have created a saleable code product that may be in form of some enhancements or a much-in-demand customisation, making it a win-win situation for both SAP and the innovation client-SAP can sell this version and the client who has designed it can get cash backs or discounts on future business transactions with SAP.This kind of a business model could be more sustainable in the long run for SAP than having a mammoth customisation team, working on individual customer requirements.