Recently I've seen some (often absolute) statements going around, generally in the line of "open source commerce platforms are a terrible idea". Now of course different solutions always have different pros and cons.
But I see quite a bit of attributes being assigned to open source software that are either not at all representative of all open source solutions OR not at all exclusive to open source.
Terms like open source, monolithic, single-tenant and on-premise are put in a box on one side of the equation and microservices, multi-tenant and hosted/SaaS on the other hand, often implying that everything in the box is the same.
Sure, these terms are related and some might often co-exist. But they are far from the same thing and understanding the difference is crucial when you're doing research for your next commerce platform.
Just like green, apple and fruit are related, it's silly to state that all fruits are apples, all apples are green or all green things are fruits. That just doesn't make sense.
Before going through some specific statements I've seen around, let’s start with a boring terminology list (with additional commerce context) so we're all on the same page. Please note that I'm by no means the gatekeeper of commerce terms, but I thought it would be useful for others that are also confused by these terms to provide some clarity on things.
I don’t want to write a whole PaaS vs SaaS explainer here, but PaaS, Saas or Both is nice blog post explaining the differences if you want to dive deeper into that. Spryker also created a nice PaaS or SaaS or on-premise decision tree for you to get a feel for the differences:
So now that we have some basics covered, lets circle back to some of the specific statements I've encountered and how I personally see these. I've copied these 1-on-1 from some posts.
All software has to be deployed/run/managed, open source or otherwise. As a merchant you can pull these tasks/responsibilities towards you or move it away from you:
There are several open source commerce platforms that offer their software in a SaaS/PaaS variant, sometimes in addition to an on-premise variant: Spryker, Woocommerce, Shopware and also PIM solutions like Akeneo all do this.
So it's perfectly possible to run open source as a SaaS service and not having to worry about deploying/running/managing it as a merchant.
The "on your own”' part is also not valid. Lot's of agencies thrive by implementing the open source software platforms mentioned above and maintaining it for merchants (whether that's hosted on-premise or through specialized hosting services or even on SaaS platforms).
Of course it is very true that when you compare software that you host on your own servers versus a SaaS or a PaaS solution that the latter will "release" you as the merchants from a lot of work in deploying/running/managing the software. You basically outsource that responsibility to the vendor and that's why you pay them a monthly fee.
No, that’s not in the definition of “Open Source”. But yes: unless the piece of software was released once and never been updated or maintained it probably is versioned. As is all software: this has nothing to do with the software being open source.
From a customer point of view, most SaaS offerings are indeed "versionless": you still get new versions and there is no work from your side and new features of bugfixes just seem to appear. And most of the time, all customers will be on the same version, which means much less maintenance for the vendor.
This is not a flawless system as APIs might be updated/created/deprecated along the way, but obviously requires much less from the merchant compared to any self-hosted software (including but not limited to open source).
That’s your choice: you can probably use services provided by either the software vendor itself, use an agency in their ecosystem or indeed deploy/manage these yourself. Not every piece of open software will have a software vendor or agencies to do this for you, but the popular open source commerce platforms do.
Many (open source and other) platforms have semi-automated or even fully automated update features, like Spryker and Woocommerce do. And yes: clicking a couple buttons is more work then the automagic updates that SaaS products provide, but ass long as you follow the coding standards, updating your system has just a minor impact on your overall workload in maintaining those systems.
And in case you add (a lot of) custom code or external services to your SaaS service, like for example a VueJS or React frontend, you will still have this update “problem”, maybe not for your core commerce product, but you do for any customizations.
So whichever way you go: at the end of the day someone needs to deal with updates to parts of the system. At least when the code is open, things are visible and as a merchant you can have control if you want to.
When using PaaS/SaaS you replace that control with trusting and external party to do so which some merchants don’t like to do. Your SaaS provider might just as well have many unpatched systems running, you’re just not made aware of it (until things go horribly wrong). Is that inherently better…?
I don’t know about the statistics of this. But since open source has been around for a long time and non-monolithic commerce platforms are relatively new this is probably true. But again this applies when you consider all software and all commerce platforms and this is not an inherent feature of open source.
If a good functioning community can maintain a big monolithic system, I don’t see why they couldn’t maintain a system based on microservices. Since everything is decoupled I would actually argue it’s easier, because all functions are isolated and you don't have to always keep thinking about the impact you might have on the system as a whole.
And that's again not a hypothetical: lot of people do maintain microservices. But exactly because these are microservices, you don’t register these as “a large community that runs dozens of individual microservices”.
But that doesn't mean it doesn't happen: there’s Docker, Terraform, K8 helm charts and more tools that facilitate this.
So this actually already happens. A lot.
This seems to be more of a monolithic versus decoupled/microservices argument. There’s some truth in this statement in that case, but again has nothing to do with the code being open source.
We have Wordpress/WooCommerce, Shopware, Akeneo and Spryker to prove this wrong. Open source projects don't have to be run by a community of volunteer developers that have no incentive to do so: These open source projects are all backed or simply run by companies that apparently have enough incentive to do so.
So I hope this gives some clarity. If you need more clarification on some of the explanations above or have your own thoughts about this? Put them in the comments!
...I'll post an article on the "Commerce is a Commodity" versus "Commerce is Custom" movements.
PS: if you want to read more about this, Sander Mangel also published an article about this topic today titled "Why SaaS vs. Open Source doesn’t have a clear cut answer" and I highly recommend you give that a read.
Most of my content is published on LinkedIn, so make sure to follow me there!
A hierarchy of evidence (or levels of evidence) is a heuristic used to rank the relative strength of results obtained from scientific research. I've created a version of this chart/pyramid applied to CRO which you can see below. It contains the options we have as optimizers and tools and methods we often use to gather data.
This is a bonus episode with Emily Robinson (Senior Data Scientist at Warby Parker) en Lukas Vermeer (Director of Experimentation at Booking.com). In her earlier session that day, Emily said that real progress starts when you put your work online for others to see and comment on which in this case was about Github. Someone from the audience wondered how that works out in larger companies where a manager or even a legal department might not be overly joyous about that to say the least so I asked Emily about her thoughts on that. Recorded live with audience pre-covid-19 at the Conversion Hotel conference in november 2019 on the island of Texel in The Netherlands. (oorspronkelijk gepubliceerd op https://www.cro.cafe/)