Skip to Content

I would like to continue the discussion of how open source makes commercial sense and how it could play in the SAP ecosystem. In this post, I’ll talk a bit of the strategies behind “commercial open source”.

By (my) definition, commercial open source is open source where a single legal (for-profit) entity owns the copyright to the software (and probably trademarks and patents, if any, as well). For more on commercial open source and how to distinguish it from professional and community open source, see here and here.

A well-known example is MySQL, the database and (former) company of the same name. MySQL owned the copyright to the database source code and would only accept outside contributions if those contributors assigned the copyright of their code to MySQL (which didn’t happen often, as far as I know). The copyright ownership allowed MySQL to apply the dual-license strategy. In this strategy, the community gets a version of the database for free under the GPL license. Commercial customers who want to pay for support get the same software under a commercial license.

Also, MySQL uses a “freemium” approach, where some commercial versions of their product are more powerful than what’s given to the community for free, i.e. clustering features etc.

Why do open source at all if you don’t take community contributions? Proponents of open source argue that you get faster adoption and a better product while keeping sales and marketing costs down.

Soo… within the SAP ecosystem, lets assume you or your company had its libraries, and lets ignore our current licenses for a bit… do you think there might be business for your company by providing those libraries, and taking a commercial open source approach? I.e. give it away for free but get paid for support by those who critically rely on your extensions?

I’d love to hear your thoughts!

To report this post you need to login first.


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

  1. Former Member
    From my experience, albeit limited, is that many companies shy away from open source solutions in favor of non-free solutions.

    They may pick a Microsoft partner, not because their offering is better, but because they do not understand that open source often results in very high quality,competitive products.

    As SAP continues to gain momentum in the medium size business arena, I think open source can play a greater role. I think the medium size businesses are more willing to take a perceived risk or pick a product based on merit rather than marketing.

    In my personal life I am a proponent of open source and use it wherever possible. I would be eager to see how such a model fits in the SAP space.

    1. Its really the need of time to get the hands dirty with open source technologies. for a very simple example in my application that i am working on, we can not use any open source framework and then we have to write the whole logic on our own or we have to hire a third party to write the code for us. All the hot open source frameworks of today like spring (core) can actually reduce the developers time of writing the quality code, in SAP we still use eCatt or some third party to test our code , but there are so many things have happened now in Test driven development (TDD). I think there must be some clear distinction between the opensource tools that we can use in development phase and the tools that we can ship with the final product.


  2. Former Member
    Hi, I think there is a place for Commercial Open Source in the SAP ecosystem in Banking. I have just worked with an investment bank in London (one of the top 5 in the world) which has an Open Source policy in the analytics space.

    SAP’s banking product set in core banking / bank analytics and in the general ledger is second to none, without question in the globe.

    But now post the credit crunch predictive analytics is to become the basis of valuation of complex products and risk quantification in portfolios. See my dialogue with Paul Centen on the BPX community about Basel II of this week.

    Valuation of Structured Products and Derivative positions for risk and economic capital purposes can only be done by deployment of analytic techniques, statistical regressions if you will and the best of these are developed in the academic community in the open source tool called R.

    Right now we have the emerging issue in accounting as to what the appropriate value of such instruments is and there again the opportunity to integrate R or its commercialised variants Insightful or REvolution has to be obvious in a sub ecosystem around the SAP GL, it’s a no-brainer since the techniques developed via the academic communities are those approved and tested by the standards makers and influencers.

    For risk capital quantification integration of commercial open source R with the Bank Analyzer product ecosystem has to be a strategic consideration, in my view.

    I do hope this makes an intial contribution to your valuable debate from a financial engineering and valuation perspective.

    John A Morrison

    1. Hi John, and thanks for your thoughful comment.

      Just to make sure: You are suggesting that we integrate R or a commercial version of with our system so that folks can keep using R and the existing algorithms etc.?

      I have some financial industries background and even know R but wasn’t aware of its importance in banking.


      1. Former Member

        I referenced one Investment Bank which has an “Open Source if Possible” approach for analytics (Customer or Product), there is of course another investment bank and a re-insurance company who standardise on R / S for all quantitative analytics.

        Given that quantitative analytics are going to be more core to oerations post credit crunch, is it not the case that a General Ledger product or a Banking or Insurance Analytics product which does NOT support R or S integration is going to lack key positioning going forward?

        To that end, REvolution Software, wich does not so much produce a “variant” of R as render R practical for commercial, mainstream use, seems to me to be the key technology in this space right now, since its new approach gets over some technology constraints of recent times & provides operational comfort to the Bank customer.

        Also you get the tested and prooved analytic routines from the academic community which provide the documentation and validation for regulators.

        To me, Dirk its a no brainer ..

        John A Morrison

        1. Thanks John, your point is well taken. I guess our Banking folks need to look at how important R (or commercial versions thereof) are compared to our existing analytics as well as existing integrations.  (I’m sure they are already doing this 🙂

          But thanks for the scenario! Maybe we can extend it further.

  3. Former Member
    This is a very interesting topic, it will become increasingly relevant as ESOA becomes more ubiquitous.  I have done a small amount  of work with Open Source products, in particular using Glassfish, the subscription-based MyEclipse java development environment and the Java-based Liferay Portal which operates under the MIT open source Licence model.  In contrast to NWDS and the SAP Portal, these products are easy(ish) to download and install and budding entrepreneurs don’t have to sweat through licensing issues either.

    I think then, one opportunity for SAP is to facilitate the open source community and encourage them to learn how to consume core SAP Services – thereby extending the reach of SAP services into new markets. A new eco-system could develop which would be populated by smaller organisations who, by adopting free open source products and toolsets can offer “commercial open source” products and services to organisations that do not use SAP, or even to SAP customers who do not yet have the Portal or other necessary SAP products. The challenge would be to select a set of open source products “recommended” by SAP so that the new ecosystem could at least start from a common platform.  Clearly, the existing relationships suggest a starting point (Sun/MySQL, Java, Glassfish, Eclipse…) and I would add Liferay to that.  In this scenario the start-up costs for new companies would be very low, the skillsets more widely available than specialist SAP ABAP or Java programmers and so the rate of innovation should be high.

    1. Hi Richard, thanks for the comment. Great thoughts!

      I wouldn’t call it a new ecosystem though but growing our current ecosystem through open source to create more value for all of us is a great idea.

      Today, we can share code snippets. Imagine we take the next step and provide a software forge on the SDN, where everyone can have their open source project as long as it is somehow related to SAP. How do you think it should look like to make sense to you? What would you expect to get out of it? What features would come first to your mind?

      1. Former Member
        Hi Dirk,

        I think the key objective is to facilitate and encourage the consumption of standard SAP Services, whether they are provided by ERP, CRM, SRM or whatever.  If we take the cross-application timesheet (CATS) as one example, it is a great way of managing resources and understanding the costs of providing services when the data has been entered correctly but it can be very complicated for the users, especially if they book time to a wide variety of codes and the search helps are not well optimised.  If I want to allow some groups of people people in my company to complete a much simpler web-based timesheet that automatically feeds into CATS then it would be great to search “SDN OpenForge” to find a free open source solution that I could download and install on an old server to demonstrate to my business users.  If we liked the solution we could learn how it works and deploy it ourselves or buy-in some commercial services from the vendor.

        Here’s where “SDN OpenForge” might help make that happen: a criterion for getting onto the OpenForge listings must be for the vendors to specify their products in terms of the standard SAP services they consume.  E.g for a timesheet application it is likely to use ‘BAPI_CATIMESHEETMGR_INSERT’. If these product specifications contained that very basic information then:

        a) SAP technical consultants and Business Process Experts could see which *standard* BAPIs/Web Services underpin the products, they could then immediately gain an appreciation of the business objects used by the products and evaluate the level of fit between the application and the business requirement.  SDN could provide links to documentation concerning the the BAPIs and, where appropriate, provide some visibility of relevant OSS Notes.

        b) SAP technical consultants and Business Process Experts could search for open source solutions that use particular BAPIs and more quickly find relevant products.

        c) Communities should spring up around popular solutions, facilitated by new areas created on SDN, and this would speed up the adoption of the best products.

        This would provide entrepreneurs and “committers” with a simple route to market where their products can be evaluated alongside competitors in the context of the SAP consultancy community as a whole.

        Overall, this approach is likely to facilitate the wider adoption of opensource solutions and thereby create a greater demand for the standard SAP products and (web) services.


        1. Richard, thanks for your thoughts on the “SDN Open Forge.”

          Would you think your scenario would be one use case or the only use case? I can see the benefit of closely tying things to BAPIs etc. but why require this be the only way?

          Can you imagine ABAP projects using SAP without having to show how they technically integrate. What would have to happen, e.g. to convince a consultancy/integrator to open source their library?

          Also, the Java folks probably shouldn’t be tied to BAPIs… 🙂



Leave a Reply