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.