Having blatantly stolen the headline from https://blogs.sap.com/2013/11/20/reasons-why-sap-should-open-source-sapui5/, the intention stays the same, this time oriented towards SAP CAP (“Cloud Application Programming Model”).

Quotes on CAP should serve as a sufficient introduction:

  • “[CAP] guides application developers along a golden path of best practices allowing them to focus on their domain problems to solve instead of wasting time and efforts in technical disciplines and hard-to-maintain boilerplate code.” – CAP papa Daniel Hutzel
  • “[CAP] together with SAP Fiori Elements reduces the time from data model to API and UI drastically.” – Gregor Wolf
  • “I love CAP.” – Max Streifeneder
  • “[CAP] is the fresh, fertile and well-watered soil in which we can grow our flowers and food.” – DJ Adams

That being said, here’s a non-exhaustive, highly subjective list of reasons why CAP should become Open Source:

1. Open-Sourcing CAP is the best way to drive core license revenue

By lowering the entry barrier to try out essential SAP S/4HANA (Cloud) Extension tooling such as CAP, the focus inevitably shifts towards S/4HANA itself, as the core integration subject. Subsequently, this will drive sales of core Finance, HR etc. users, either on-premise or in the cloud.

2. Because it is in SAP’s interest for CAP to be successful also outside SAP

CAP is the go-to framework for both extending S/4HANA and integrating it with other web-enabled non-SAP systems. For this to be successful, it needs a wide adoption by developers outside the SAPverse. When SAP is restricting CAP to be available in the SAP software context only, it will lose traction with those developers, as they will continue to choose other integration technologies that they’re more comfortable with.

3. Because open-sourcing CAP doesn’t cost revenue opportunities

Open sourcing CAP wouldn’t cost SAP revenue as CAP’s Node.js runtime is available via the public NPM registry already. In fact, by growing the CAP ecosystem using the open source band wagon, revenue may even go through the roof by enabling building cloud-native software with the focus on integrating with SAP software – what, in turn, might most likely entail the sale of additional SAP software licenses.

4. Open-Sourcing CAP doesn’t mean loosing SAP HANA investments

CAP v4+ has a Database API that allows plugging in databases as just another “service” – including SAP HANA. Taking the SAP HANA persistence adapter out of the Open Source scope would be a valid logical consequence for keeping the investment into the closed-source DB also closed inside SAP → “openCAP” w/o HDI artefacts is just fine.

5. an Open Source CAP will become more rock solid and receive features at an increased pace

Once the sources are available, contributions by the community will contain not only bug fixes, but also new features that SAP alone can’t deliver at comparable speed. It is almost the simple equation of having additional development power at hand that battle-tests the foundation, stabilizes the concrete of the building and enhances the property. A joint venture!

6. Because SAP is making use of a wide variety of Open Source technologies in its’ cloud stack

Historically, SAP has been perceived as a rather closed company. Even though the ABAP code has been readable by nature, legal terms prevent you from using it in the same way as open source software is used.

Nowadays, SAP Cloud Platform Business Technology Platform uses a wide variety of Open Source technologies to obtain the capabilities to become the “Business Technology” Platform. Although legally sound, it may not lead to the right perception by the open source community if SAP is holding back on contributions toward the same.

Instead, SAP should appeal to developers in the open source community by continuing to earn respectability and legitimacy. OpenUI5, Gardner, Kyma and others have paved the way for that – so it is easy to walk the walk, follow OpenUI5’s initiative and prove to be an authentic and significant Open Source contributor by open-sourcing CAP.