Open Source Vendor Lock-in

Yesterday, SAP’s CTO Vishal Sikka called for a more open approach to the Java standardization process (JCP), asking SUN to stop ruling it with a heavy hand. Not surprisingly, he got some pushback using the argument that SAP isn’t one to talk about being more open, given its slow involvement with open source.

I don’t think that this is a fair critique. SAP has always provided the source code of its main business applications suite to user-customers as part of a commercial license, and users have always customized SAP’s business suite to their heart’s content. In fact, it is the only way to make it work for their needs.

Contrast this with commercial open source firms using the open core model, the emerging dominant business model in this space. Here, the core of the software is open source and free, but if you want to use it professionally, you will almost certainly need to pay for a commercial license, which will give you the missing bits and pieces that make the software usable in an enterprise context in the first place. These missing pieces are not open source and are not provided to the community for free. This works, because hobbyists or low-end users typically don’t need these features.

So what’s the difference between SAP and software firms utilizing an open core business model? It is not the lock-in. Once you start modifying closed source software, whether it comes from SAP or an open source firm as part of their commercial offering, you get, well, locked-in. Migration pains will depend on the extent of your modifications, but not on whether it is SAP or some other company.

The only fair critique is to compare SAP with commercial offerings that don’t hold anything back. But firms with those offerings (like most other) have still to demonstrate viability on the level of an SAP. I don’t expect to see this anytime soon.

Disclosure: I used to work for SAP in the Silicon Valley where I led the open source and Web 2.0 research efforts. I am now a Professor of Computer Science specializing in open source at the University of Erlangen-Nuremberg.

9 Replies to “Open Source Vendor Lock-in”

  1. It’s a fair critique, Dirk, though I don’t think it does anything to change my underlying criticism. It also does nothing to address Dennis’ stronger claim that the only reason SAP cares about open process in this context is because it’s scared to death of Oracle. (See here.)
    Thoughts?

  2. Hi Matt—your general critique that SAP was slow to open source is certainly correct. And the temporal co-occurrence of Vishal’s post to the Oracle/Sun deal may certainly appear as curious.
    However, my general point is that SAP offered many (not all) of the open source benefits to its customers long before anyone thought of doing it as we do it today. Customers always had the source code, adapted it, and submitted back the patches. SAP integrated these patches much like an open source company might do. It bugs me that b-schools consider user innovation a finished topic—I think SAP could be the greatest case study of all. This is one reason why SAP didn’t (have to) jump when open source as we know it today entered the scene.

  3. Dirk, I don’t think your defense of SAP’s openness cuts wood. It is basically the same argument Sun used before finally open sourcing Java under the GPL: From 1998 the Java source code was available under the SCSL allowing user-customers, like SAP, to modify and submit patches back to Sun.
    This is just not the same as open source. If nothing else a key difference between SAP’s and Sun’s initial approach vs open source is the requirement to give modifications back to the original contributor creating a hub and spoke model. Open source licenses put the original contributor on a level playing field with other contributors that closed-source models don’t.
    Disclaimer: I used to work for Sun and ran the JCP for (too) many years.

  4. SAP is of course afraid that Oracle will somehow try to benefit from it’s future control over Java or hinder competitors. Other vendors sit in the same boat.
    With control over Java you have a much greater lever to control anyone using Java. Thus a more open approach to the Java standards process is more important than an open-source ERP system.
    If you take Vishal arguing on behalf of the industry he does have a point.

  5. It is about credibility. If SAP asks Sun to give Java to a foundation, but is seen as self-serving and hesitant in its own open source efforts, the message gets lost, and SAP just calls attention to their own bad karma.
    That is why when the ASF led the charge for non-discriminatory, open source compatible licensing of the Java SE TCK and Java trademark for their Harmony project, the JCP and Sun had to pay attention. Nobody disputes ASF’s bona-fides. Sun’s refusal to budge on this point even in the face of determined opposition from the rest of the JCP is telling. The licensing and IP interactions between the code, the TCKs, the trademark, the JCP’s spec license etc. etc. are byzantine in the extreme. But this structure was crafted in the crucible of competitive negotiations within the JCP, by smart people from big companies with lots of lawyers. These companies all want to kill each other in the market, but work together within the JCP because it suits their interests. The ASF, with their open letter, threw a wrench into that machine, and the gears are still popping out. If and when Oracle/Sun closes, it will be fascinating to watch Oracle’s position on all this stuff. Will they still be singing the “open, independent, vendor-neutral” chorus? I honestly can’t predict what might happen – but it will sure be a heck of a case study, with mega-$ at stake.
    Disclosure – I used to be at Sun, and led the marketing effort behind OpenJDK.

  6. @Onno – where did I say SAP is open source? Of course they are not. However, its users get some of the benefits that users of open source software get. My main point, however, was that what appears to become the main open source business model, the open core model, creates the same or at least a similar lock-in as traditional vendors like SAP create it.
    @Martin – the timing is curious but I cannot speculate about Vishal’s intent. Innocent until proven differently, I’d say.
    @Rich – thanks for the comment.

  7. There is a key difference between shared source and open core, that I have not seen noted here: with open core, customers have the option of slowly replacing the closed-source “cruft”, and so there is an inherent exit strategy (if a company, or a group of companies, or open-source developers, are willing to reimplement the closed-source parts of the stack).
    There is also the option to deploy a mixture of the complete, commercial stack as well as stripped-down, open-source only components. e.g. using RHEL/SLES on some servers but CentOS/openSUSE on others.
    The nice thing about having core components under a genuinely open-source license (thus licensees can choose to modify, deploy, and publish the code) is that it keeps the supplier honest: if it were to drag its feet on accepting outside changes, it would eventually be left behind. This happens even in the free software world — witness the GCC fork. As far as Sun vs SAP is concerned, though, I would admit to not knowing how well SAP integrates outside contributions (as opposed to Sun — which does not have a very good track record, from a functional-programming perspective at least). The process might well work for them, but I suppose @Rich has a point, either way, about the issue of credibility being quite important here.

  8. Hi Dirk,
    Thanks for this article. Cloud you please mention some of the commercial open source firms (and their products) using this open core model?
    Thanks.
    Jacob

  9. Hi Jacob: There are plenty, just search for them. Some that come to my mind are Alfresco, Jaspersoft, SugarCRM, Bitrock, Actuate, etc. Hope this helps, –Dirk

Leave a Reply