August 2020, I began a new adventure: Propeller. With Propeller, we unite the power of digital commerce and data with the sales team. And we can enable B2B businesses to offer a truly optimal digital customer journey, with fewer errors, better customer experience, and higher turnover.
But people often ask me: oh, but isn’t Propeller open source? As the founder of Hippo CMS (now Bloomreach) and a fervent proponent of open source since 1999, this means of course that I owe people an explanation 🙂
In recent years a lot has changed in the way we use software. I believe that the most important change in this is the emergence of the cloud. But with the arrival of the cloud, the way that software works has changed structurally. Software has changed from large, complex applications to a collection of smaller software applications that collaborate on a semi-linked basis.
The revolutionary concept behind this: the REST API, was presented by Roy Fielding in his thesis in 2000 and it is no coincidence that this was commercially introduced for the first time by Salesforce, one of the first Cloud/Software as a Service companies. Amazon took the next step when Jeff Bezos demanded in his famous API services manifesto that all the elements of the company’s internal software should communicate together independently as services.
This was the start of the services and later microservices revolution. And the start of Amazon Web Services ( AWS.)
This may seem like a purely technical matter, but it has an enormous impact on how the value chain works.
An example is Adyen, a company that only offers a very small service: making payments on websites, but which is worth more on the stock exchange now than ABN Amro and ING put together. This company owes its entire existence to this API revolution. Andreessen Horowitz, one of the leading VCs in the world, is not wrong when he calls this the API Economy. In this film, we explain this clearly.
And for a more comprehensive explanation, see this podcast: a16z Podcast | The API Economy — The Why, What, and How – YouTube
The ability to revise and expand the software was previously one of the arguments for choosing open-source. However, revising software brings with it a great responsibility; namely that of maintaining the software. The developed code and/or plug-in must also continue to work with a new version of the product, and that is often much more work than people had imagined.
Whether you are able to expand something depends on the architecture of your application; is it suitable for expansion?
Many monolithic applications, like Shopware and Magento, with architectures dating to around 2000, are not actually suitable for expansion. Because, the bigger the team and the application, the harder it is to do this successfully and in a way that is stable. That was the reason for the API manifesto from Bezos. The coordination required to make the Amazon site and applications work properly was too complex for it to be achieved within one company. And, of course, far too complex if you have to do this as an independent party.
The only way to successfully expand flexibly is via API’s because in this case, the supplier assumes the responsibility that the API will carry on working in accordance with the established and documented specifications, whilst, behind the scenes, he can make all sorts of revisions and adaptations to the software. So, the software doesn’t need to be open source for this. What is important is how extensive the APIs are. Which parts of the software can be manipulated via an API? As a general rule: the more, the better.
Modern software, such as the Propeller Cloud, is developed on the basis of microservices and a headless architecture; this means that every part of it can be adapted and replaced with a better or more suitable software service.
Is this the end of open-source?
No. In fact, there is more open source than ever. Many technology companies, including Propeller, use an enormous amount of open-source software in building their services.
The software world is divided into layers, broadly speaking:
The functional applications are actually all software with a UI, and they all have business users as their target group: for instance, Office or your ERP system or Commerce application.
The success of open source was always within the first two layers. If you look for successful open source products with a UI, then there are very few. OK – WordPress, of course. But what else?
And this is understandable. Technology companies like to collaborate in the first 2 layers because the purpose of the applications at that level is often shared, but this is not what the customer pays for (they don’t compete with it).
Nobody uses Facebook because they invented React or GraphQL. A database has to be pretty fast and robust for both Amazon and Facebook, Google, and for Salesforce, with clearly described functional requirements. For this reason, all these companies collaborate on technology within the first two layers within open source communities like the Apache Software Foundation.
With my last company Hippo, we collaborated intensively with Adobe on Apache Jackrabbit (a database layer) and our people had a beer together and swapped ideas whilst at the same time Hippo CMS and Adobe Experience Manager were both in direct competition for leadership in the Gartner Magic Quadrant for Web Content Management.
The explosion of the Cloud has led to the creation of more excellent open source technology, such as Kubernetes and Docker. This open-source software is much more secure and robust than technology that is developed in-house by companies.
This is different at the functional level. Because it is very difficult, if not impossible, to develop a good UI for end-users in open source. Ultimately, there is always a company behind this, which coordinates it: WordPress is a company, Drupal is Acquia and Magento is also a company (Adobe).
I still believe in the power of open-source, but open source is not the right resource for expandable functional applications. APIs are the best approach. Propeller is the first in the industry to have a full GraphQL API (the successor to REST), with which the customer or an implementation party can adjust and replace every part without placing stability at risk. For technology companies whose core business is building complex functionalities, open-source is an essential part of the tool kit, in order to be able to develop secure, scalable software.