Licence to kill

In case you are following SAP and CAP related topics, you noticed that the CAP enthusiasts are still trying to convince SAP to make CAP available under an open source license. SAP, at the same time, is declining the request. While I’d welcome having CAP as open source very much, I do not think that providing CAP under as open source today will add much benefit. I believe that currently CAP under open source would be great, but CAP itself is not ready enough to greatly benefit from that move. Just to make it clear: today.

Project success

I think that an open source license is not an enabler for success but more of an accelerator. Looking at some successful open source projects, there are many aspects that have to play together. The success is built on many pillars that together form the foundation that allow a project to be successful. These pillars have each a different importance and weight and are unique to each project; explaining why the same formula works for one project, yet not for another one.

Some of these pillars can be use cases, usage scenarios, implementation, community, uniformity, security, availability, enterprise readiness, license, and the list can go on and on. Some projects depend more on a few pillars, some on others. Yet, some stand out more than others:

• Use cases
• Community
• Implementation

A project needs a good or unique use case; like a problem or business process solved by only that project. The community comprises the overall users of the project, be it direct or indirect, active contributing or only consuming. The implementation is where and how the project is run. Is it cloud, on premises, does it have to scale to millions, do you get support, is there a roadmap, short: everything you need to run it or its enterprise readiness.

Open source projects

Looking at one open source project we all know – Linux kernel – we can see how many pillars form a solid foundation. The use case is simple: a kernel to run an operating system. Almost every interest group is represented, and you can run Linux everywhere. The license acted as an accelerator, as everyone can participate and millions of line of code are contributed. Without an open source license, it would have been just like any other commercial Unix. Java was different: it was a success even before the license was adjusted. The use cases, implementations and community were great. But to ensure that this continues, an adjustment was necessary, and it switched to GPL.

Why do companies or teams offer software under an open source license? Sometimes they do so hoping that their software survives. Community engagement is going down, lack of use cases, and open sourcing it is seen as a way to recover and regain importance. Sometimes this works, sometimes not. More important for success are use cases and implementation. Both make it possible to have a community. While a close source / commercial software can grow up to a specific level, it is hard growing further. That’s were an open source license acts as an accelerator: it allows more people to join, to adopt it for other use cases not covered currently. Reaching a tipping point in adoption will lead to an open source license, sooner or later.

SAP

Regarding SAP, one apect is important: the non-SAP aspect. For instance, their ABAP programming language is unique to SAP. It has a great community, use cases are easy to find, implementation and adoption are so good you can find it everywhere. Now, open sourcing ABAP, the license won’t be an accelerator. It cannot grow much outside SAP world.

That’s where I think that open sourcing CAP is a great idea, yet won’t help much, as the use cases and implementation scenarios needed to grow are not broad enough. The use cases and implementation are still very much SAP focused. They focus on running CAP in BTP and connect to an SAP service. Almost all scenarios contain some SAP system somewhere. With these scenarios, the community will be what? The same as for ABAP: a very SAP centric community. This sets a natural boundary for adoption.

This is what needs to change.

• We need to focus on non-SAP centric scenarios.
• Get the normal developer to code apps with CAP.
• Run it where the developers are: AWS, Azure, K8s, OpenShift.

Personally, I’d like to see the following coming to CAP soon:

• Treating non-SAP and SAP centric scenarios as equal.
• CAP has an open architecture, let’s use this and make run CAP natively on other cloud providers (this will already mandate a move away from the SAP developer license). At least have quickstart scenarios available and integrated in the hyper scaler service offering documentation.
• Establish a CAP board to which SAP and community members are elected and define together the strategy. This kind of board would be great to have to the ABAP programming language as well.

We need use cases and implementation scenarios that cover the non-SAP world. With this, the community automatically will grow. If we do this, CAP will grow up to a certain point when a change to open source cannot be longer denied by SAP. With a strong enough community, a license change will come.

Let’s do this!