SAP: Open Source's Friend or Foe?
For an outfit that calls itself “the world's largest business software company”, the German software giant SAP is relatively little-known in the open source world. With 51,500 employees, a turnover of 11.5 billion euros ($16 billion) last year, and operating profits of 2.7 billion euros ($3.8 billion), SAP is clearly one of the heavyweights in the computer world. Given that huge clout, SAP's attitude to open source is important; and yet it is hard to tell whether it is really free software's friend or its foe.
On the positive side, SAP has invested in many of the top open source companies, through its SAP Ventures arm. Well-known names it has backed include Alfresco, GroundWork, Intalio, JasperSoft and Zend; earlier investments included MySQL and even Red Hat.
Just recently, it announced that it was increasing its participation in the Eclipse Foundation:
As part of its ongoing commitment to Java technology and the choice it provides to customers as well as industry-wide technology standards and open source, SAP AG is taking a more active leadership role in the Eclipse Foundation by increasing its membership level from Strategic Consumer to Strategic Developer. SAP will provide at least eight full-time development resources to various projects and lead open source projects, ensuring direct input into the development and architecture of Eclipse. As a Strategic Developer, SAP will be more active within the Eclipse community, including the new Eclipse Git Team Provider (EGit), the Eclipse Modeling Project (EMP) and the Eclipse Equinox Project. Eclipse technology has become the de-facto standard in many domains and for many companies ongoing collaboration on various projects with other industry leaders supports the standards and open source strategies of customers and partners.
These outward-facing activities present a very positive picture of the company, engaging with open source in all kinds of ways. But there's another side, one that's hidden unless you start digging through obscure documents, that's rather less flattering.
For example, the European Commission organised seven workgroups looking at various aspects of European software policy. One of these was on open source. Among the groups taking part in this was the Free Software Foundation Europe, and SAP. At the end of their joint report (PDF, HTML), there are a number of appendices that represent the particular views of participants. SAP's is by far the longest, running to some 17 pages.
Most of that space is used to bolster the following statements through supporting comments of various kinds (mostly links to news items):
A number of key open source projects depend on the contributions by mixed source / hybrid model companies
Hybrid / mixed source models seem to be a key element of the larger open source ecosystem
Open source development like closed source development has its pros and cons
It is very difficult to discriminate between open source and non-open source vendors any longer
Open source software is proprietary as well
Different business models and business interest lead to different positions regarding IPR, standardization and interoperability
The general thrust seems to be that there's no big difference between open and closed source, or between open source and non-open source vendors, and that everything is converging on “hybrid/mixed source models”.
So why is SAP so keen to blur the distinction between open and closed source solutions? An answer can perhaps be found in the main body of the report, where some members express their disagreement with sections of the main text otherwise approved by the others. Here's a case in point:
Mandates for OSS can harm OSS:
The following is a view specific to SAP and CompTIA
Open source has created an interesting opportunity for entrepreneurs as they can start a business on top of something that is already available. For example, many companies offer services and support around popular open source software packages.
Due to the mixed model growth, software vendors are combining open source with closed source, and as a consequence, the line between open source and closed source increasingly blurs. Therefore, any preferences or mandates favouring open source may be harmful for all software vendors including most open source vendors.
For example, if an open source vendor monetizes its open source contributions by selling closed source add-on components and closed source enterprise editions, such a vendor will be discriminated or excluded during such public tenders. This is particularly true when the closed source “enterprise editions” have been productized under a different brand name and thus are not recognized as an open source product anymore. Thus, even though it might sound paradoxal, preferences or mandates for open source may harm open source, because they reduce the opportunities for the contributing open source vendors to get a return on their open source contributions. Therefore, open source preferences or mandates could be counter productive in growing the European software industry.
We can see here how SAP and CompTIA are implicitly drawing on SAP's argument that there's now no fundamental difference between open and closed source, and that “mixed models” prevail. That being the case, they argue, it would “harm” open source to insist on open source only. That is why SAP spent so many pages “proving” this: it needs it to support its earlier objection.
However, just as the “mixed models” have grown in popularity just recently, so they may well fall out of favour; basing European policy on fashion rather than principle is hardly wise. Moreover, it's really irrelevant whether companies are adopting a “mixed model” or not; the European Commission needs to decide what is best for Europe, not for software companies that have built their businesses in a certain way.
There are many well-known benefits that accrue from mandating open source for European contracts – level playing-field, absence of lock-in, ease of moving between suppliers etc. More generally, it creates a bigger software commons that everyone can draw upon - not just companies, whether giants like SAP, or small startups, but educational establishments too (an important but often-overlooked sector).
Companies that have adopted a mixed model can simply re-jig their product line, offering wholly open source versions for European government consumption, and making money through their proprietary add-ons elsewhere; adoption by Europe would be a huge marketing boost, making it much easier to do this. And if they won't adapt to the situation, that creates an opportunity for new players who *are* willing to do so.
That's not the only place where SAP's attitude to open source is ambiguous, to put it mildly. For example, there's a section in the document that deals with software patents:
IPR sanity checks
Setting a clear agenda on IPR sanity checks and the ability to deliver legally binding IPR compliance statements on OSS components by a transparent body is a much needed action item.
But SAP is not happy with what follows:
SAP disagrees with the following part of this proposition
On top of providing Compliance statements this body could have the following goals from which Open Source will strongly benefit
- push for ex-ante disclosure on patents
- call for transparency of the judiciary in charge of software IPR rulings
- promote acknowledgement and full integration of alternative IPR modes aside the RAND types by Standards Development Organisation, research projects, public procurement, and public/private European entities delivering IPR-related assets.
- promote alignment of e-procurement processes to ensure the risk of vendor lock-in is evaluated and part of the decision criteria.
- push for Systematic “prior art” research on open source projects as a step of new patent analysis
The problem here is that SAP likes software patents. In another obscure filing, this time to the European Patent Office, it spends pages arguing that the current, already-porous regime for granting patents on software in Europe should be loosened even further.
Other ideas that SAP objects to in the European report include “Promote OSS initiatives targeted to commoditize software products of interest to European industries,” and the creation of the “European OSS forge” and “The European OSS test bed.”
A company that wished open source well would back these ideas. One that *really* supported free software would also fight against software patents. So, while SAP's involvment in Eclipse and investment in open source companies is welcome – and pretty self-interested, it has to be said, given that it presumably hopes to make a profit on them – it's not really enough cancel out its unhelpful attitude and statements elsewhere. If it wants to be a serious, respected player in the world of open source, as befits its size, it must do better.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide