Magento Open Source vs. Commerce: Suitability, Feature Gaps & More

James: Hello and welcome to the fourth episode of the Re:platform podcast. I’m joined as always by Paul – good morning Paul.

Paul: Morning. How are you doing?

James: Yeah, all good. How about yourself?

Paul: Yeah. Good. Thank you.

James: Excellent. Let’s crack on. We’re going to be talking about Magento 2 and Paul is one of the leading solutions specialists in this area. He has a massive amount of experience with Magento as a platform, way more than I’ve got, which is great. I’m going to learn loads today as well, which is cool. So the reason for talking about Magento 2, it has been a big story in the marketplace for a few years, moving from Magento 1 to 2 is not just a quick migration, it’s a proper re-platforming. Magento 1 will been sunset in June, 2020. So a lot of people have moved over already but there’s still quite a few people on Magento 1 and trying to decide what they should do next.

James: So we’re going to talk about what the different versions of the platform are. There is Open Source, the community version, and there is also the enterprise versions, Commerce and Commerce Cloud. Commerce Cloud being Adobe’s play to compete in the SaaS market where they’re providing the application support and hosting. A lot of people who are enterprise-level assume that they need to go to the Commerce versions because Commerce versions have additional features, and since Adobe bought out Magento they have put a lot of investment into the releases, really ramping it up. However, the Open Source version is highly flexible. And with the right development skills you can actually plug feature gaps quite well using third party specialist tools – or enhancing the core application – to build out a best in class suite. That level of flexibility can offer different advantages.

James: So there are pros and cons to both options. There are also agencies out there like Tom&Co and GPMD who choose to build a lot on the Open Source version and have really good case studies of building retail ecommerce sites that turnover a large amount of revenue on an Open Source version. What I want to do today is to get into Paul’s mind and extract as much insight as we possibly can on Commerce vs. Open Source: what they are, how they’re changing, you know, pros and cons, etc. Paul let’s open up with a simple warm-up question and then we’ll get into the details. Can you give everyone an overview of Magento 2, Commerce and Open Source, how they’ve changed over time?

Paul: Yeah, absolutely. So with Commerce and Open Source as you said, Commerce is the paid version, premium version. The main differentiator is features, and then you’ve got Open Source, which is a free version of the platform. Historically, the Open Source version, which was previously called Community, was much more widely used by smaller retailers than it is today. And then Commerce has improved as well over time, particularly since M2. So there’s been a number of feature improvements to differentiate Commerce, as historically there used to be a lot of question marks around whether the difference in feature set was actually worth the investment in the Commerce license. They were quite similar and then there were additional features that were available in Commerce, but they could be replicated by different third parties and different modules relatively easily.

Paul: Whereas now you’ve got things like the B2B suite, which is a big improvement in M2 Commerce. The B2B suite has quite a lot of enterprise level B2B functionality, which can be extended in its own right. You have page builder, which is a big improvement for content management and allows retailers to operate a lot more self sufficiently, without needing developers to get involved in building out landing pages or content blocks across the site. And then there’s been various improvements in things like visual merchandiser, content staging, even little features like gift register have improved a lot. So I think the feature gap has got a lot wider. With Open Source though I still think it can be really valuable for, either retailers wanting to operate in a certain way, where they want a light set of modules and build on top of that themselves. Or people that just can’t justify the licensing cost. And with the licensing now being based primarily on revenue, if you’ve got a retailer that doesn’t necessarily have high budgets but they’re turning over a lot of revenue online, it’s quite difficult to justify Commerce. So that’s why Open Source still definitely has a place.

James: Interesting. Thank you. A really good overview. One question that I’ve been asked a few times, and it would be useful to touch on it now, is Open Source supported by Adobe, or is it not supporting it? Is it purely reliant on the developer community to keep maintaining and extending it? So for example, do they release on it? Do they do patches, fixes, how secure and stable is it versus Commerce, which we know is the area they are investing most because that is going to be where they drive the most monetary value.

Paul: It’s not supported to the same levels, but you can still apply patches on the Open Source version. But in terms of new feature developments and where they’re building out the product in terms of the cloud and things like deployments and the overall architecture, and new features for generally, it’s not supported to the same level.

James: Right. Okay. That’s a good distinction to have: support vs. extension. So let’s talk a bit more about the Open Source option and then do a comparison with Commerce. Can big retailers genuinely operate on Open Source? Does it give them enough capability to do enterprise level ecommerce, Omni channel, more advanced catalogue management, merchandising, etc. Can it do it? Do you have any examples where a big retailer is using it? And on top of that, just because I like to throw loads of questions at you, what are the key drawbacks? Because nothing’s ever perfect. We talk about this a lot. No platform’s one hundred percent perfect. So are there drawbacks that a retailer needs to understand when thinking about this? So if we could go through it. Big retailers, can they use it, some examples and then any drawbacks?

Paul: So I think big retailers can definitely use Open Source. And I’ve heard recently that more big retailers looking at Open Source due to the shift towards headless and people taking not just headless, but also more retailers are using PIM (Product Information Management systems) and different specialist third parties, then relying on a platform less. So that’s kind of a trend that I’ve seen a little bit. Not too much, but I’ve definitely seen a couple of examples where bigger retailers have looked at Open Source and then they’re looking to take more stuff out of the platform. In terms of big retailers using Open Source, Pretty Little Thing and Brand Alley are two of the big ones. Both are pretty sizeable retailers, both reasonably complex, and they’re both using Open Source.

Paul: In terms of how they would operate, they could quite easily take certain parts of what would be offered in Commerce and then replicate it. So for example, with visual merchandiser, you could use other modules or you could completely take that area out of the platform and look at something like Bloom Reach, which is a different level of cost due its capabilities but it’s still potentially viable to achieve an enterprise level of visual merchandising that Magento Commerce can’t offer natively. And then in terms of the drawbacks, you talked about support before and with Commerce Magento does actually fully support the product. So you have things like issue resolution, you can raise bugs, etc. With the different features in Commerce, so things like page builder, visual merchandiser, content staging, customer segmentation, a lot of these can be replicated, but when you use third parties, they’re not as joined up or seamlessly integrated, which can take more effort to configure and maintain.

Paul:  One of the things that I do really like about Commerce now is that you could feasibly build a new version of the homepage. You could then visually merchandise a series of categories and schedule that for release on a certain date. You can actually see that workflow as well and when things are going live. It definitely feels a lot more joined up now. That is something that I’ve not seen someone really replicate with Open Source. You end up with a series of isolated areas. So for example, if for page building you’re using something like ZMags or Styla or something like that, it’s quite isolated and it’s not really an active part of the platform. You can’t really combine that with other areas of the platform if that makes sense.

James: It certainly does. And I think that’s an important point and the aim of these podcasts is to tease out the pros and cons of different approaches because then people can understand whether it fits operationally, with how they want to manage a website. The other thing that I’d quite like to ask you as well, one of the common criticisms of taking a fully Open Source and customisable platform and then extending it to your heart’s content, is that you’re off of upgrade paths. If you decide that you need to move to a different partner in the future because your current SI is not fit for purpose or you’ve outgrown them, it becomes much harder because it’s so customised that you can’t do that. Is that a genuine criticism of Open Source or is that actually true regardless of whether you’re on Commerce and Open Source because the platform is extensible and therefore you could have extended it and made it not possible to just directly migrate everything into a new provider?

Paul: Yeah, that’s definitely possible on both versions. I’ve had loads of clients that have been on Commerce and they’ve heavily customised the platform and then they’ve had issues with upgrades and another agency then supporting the platform. I think if you are going down the route, if you’re a relatively complex business and you choose Open Source over Commerce, you know that you’re then going to need to either use a number of different third parties or build different custom modules yourself. And inherently by doing that, that is going to impact the kind of support of the platform. But equally if you use the right third parties and you take the right approach in developing modules and extending the platform, I think it can be controlled. And it’s just about having that level of best practice, which applies to both versions.

James: So I guess the key advice to people considering Magento and then the different versions is, to really probe any development agency. How do they set up their project builds, you know, how have they extended Magento? Is it in such a customisable version that it can’t be reused, or have they actually extended it sensibly? So they’ve got the core application and they built around it?

Paul: Yes. One thing that is quite interesting now is if I compare project approaches to a few years back, when I’ve been involved in recent Discovery phases, pretty much every agency wants to keep things vanilla, unless they genuinely can’t keep things vanilla. And everyone wants to standardise and avoid deviating away from standard Magento, because they’ve had so much pain in the past. When you hear people saying bad things about Magento, often it’s because people have deviated away from standard, or they’ve customised the core platform and then that’s them impacted stability or scalability. For some reason most agencies have adopted that approach of keeping things clean, simple, native. Which is definitely a good thing. And I think that applies to both versions, but probably more Commerce.

James: Definitely. Another question related to that. You’ve talked about some of the feature sets and advances that you get in Commerce versus the Open Source. Are there any scenarios where a business has a specific type of need where, in your experience, Commerce has won hands down versus Open Source? Can you take a particular business operational model that says for example, okay, it’s a global business with complex omni-channel / multi channel demands and it needs really good order management, endless aisle capabilities and therefore actually Commerce ticks that box way better than Open Source ever will? Can you ever narrow it down on a capability where Commerce wins outright?

Paul: So there’s one really obvious one, which is B2B. The B2B suite is actually really good. I’ve never had a client use it, but I played around with it quite a lot, it’s impressive and it gives you capabilities like shared catalogues, custom quote management, and much more that enables smart B2B commerce. And I think that would be a good use case, a really good argument for a retailer to just go with Commerce without even really looking at Open Source. Beyond that, I can understand why people would look at Open Source. But often when you total up the different features and the benefits they provide, it’s sometimes obvious to go with Commerce, assuming that the price isn’t too high.

Paul: The thing with Commerce these days is that you might be paying $30,000 a year when another retailer might be paying $300,000 a year. So I guess a lot of it comes down to cost. One of the only other clear benefits is if you’re using the order management product, which can add quite a lot of value for specific situations. I had a client that used it for managing Click and Collect via a network of suppliers. So they’re essentially ring fence stock within these different local stores in London. And then they allowed the user to do Click and Collect via that using the ring fence stock from a network of suppliers. That’s all handled by the auto-management product. And it worked really well. It is the only reason they chose Commerce in the end, because they got a deal combining the licenses.

James: I think that’s an important point about the capabilities you need to turn on because some things you can plug in from a large number of existing tools like merchandising, testing, whatever it might be. There’s a load of proven specialist tools in the marketplace. But in something like B2B, it’s so customised, a niche, that some platforms do it brilliantly native, others are specialist to B2B, but to build that capability suite from scratch would be very expensive and time consuming, Interesting. So we talked about cost; let’s give a bit more context for how the cost model works for Commerce?

James: Businesses need to stop and think about their budgets and financial models and which platforms are most cost affordable, because anything that’s based on a revenue percentage, or based on revenue bands, works really, really well if you have amazing margins, and therefore the percentage of your total GMV isn’t that high, but if you have a really slim margin business then license costs can eat up a big percentage of the profits. So can you clarify, how does that work and what are the bands, and at what point do the license fee start to really scale up and how does Commerce on-premise versus Commerce cloud compare. Is Commerce cloud massively more expensive?

Paul: Yeah, absolutely. Something I’ve had quite a lot when I’ve looked at Magento and when we’ve selected Magento, the client has been on-premise versus cloud. And historically cloud was more expensive, so I think it was about 40% more expensive than on-prem. Now it’s the same cost, which does make things tricky. So if a client wants to go down the on-prem route, they then have to justify the additional expense of a hosting provider. A lot of people still want to go on-premise and they either want to work with their existing hosting provider, or they want to manage a cloud service themselves, or they’ve just heard negative things around Commerce Cloud in the past. The Magento cloud offering has got a lot better, but it did have a bad reputation to start with. So that is quite a tricky discussion usually.

Paul: And then in terms of pricing, so this changes all the time, but it is based on GMV pretty much nowadays. There are different brackets, which I think are still under £10 million, £10m to £25m, £25m to £50m and £50m plus. I can’t remember what it is beyond that, but basically it just goes up within those tiers. But it isn’t like it used to be where it was $30,000 if you’re under 10 million turnover, or $50,000, if you’re under 25 million turnover, it’s changed quite a lot. And from what I’ve seen, it seems to be pretty much case by case now. And that’s not to say there’s not a tiered system behind the scenes, but that’s definitely what I’ve seen. I haven’t seen too much in terms of retailers with the same turnover necessarily being given the same pricing. And I know they do have other things they take into consideration like the size of the overall business, and I know there’s some other variables they look at as well.

James: And how close to quarter or year end it is for the salespeople! There’s always a discount to be teased out.

Paul: Ha ha. Absolutely, yeah.

James: That’s interesting thank you. I think this is one of the key things people take away, that you really need to evaluate the pros and cons of both options. With Open Source you can save on the license fees and therefore you’ve got more money to put into development, you know enhancements, but you’re missing key features that you get in Commerce. So depending on the revenue tier and how much you’ll have to pay, you might find that the additional feature set justifies the license fee investment. So it’s not always a clear cut thing, which I think is important people take away.

James: So moving onto some of the capabilities you talked about earlier, about some areas where the investment from Adobe has been quite good in pushing the capability set forward. You talked about page builder from a content management point of view, what do you think it of it? How does it compare to an enterprise CMS like Episerver or Kentico, or even the content capabilities of platforms like Shopify and Big Commerce, which have got really good native content management in there especially with the likes of the Shogun integrations.

Paul: So I think page builder is a good move in the right direction from Magento because before they had a very basic content management and now it’s a lot better. It’s drag and drop. You can build custom components. They have a pre-built set of widgets, it is really easy to use and it’s built into different areas of the platform as well. So you could use it to build out landing pages, you could use it to manage a content area on a PLP or a content area on a PDP for example. And that can be further extended. So for example, some sites use page builder within their own blog module. And then that way all of the blog content is managed in the same interface.

Paul: It’s good, but I think it’s still got a way to go. It’s in a similar place to a lot of the other page builders that platforms have. For example, Salesforce’s new page designer. But I would say Shopware’s page building solution is a lot stronger, it’s a lot more polished. But equally I think it’s slightly different in that, with Magento it feels like it’s a bit of a foundation agencies should then build on, and they can then build out custom components and integrate with different third parties. Whereas Shopware, it is a lot more feature rich, and kind of fully fledged I guess.

Paul: And then in terms of comparing page builder to enterprise content management systems. So I don’t think it’s quite at that level yet. It’s very much a simple effective page builder and then it can be integrated with things like the scheduling feature within Magento. But it doesn’t have things like workflows, and it’s not quite as built out in terms of staging specific types of content. One other thing that I was really disappointed with in regards to page builder is that when Magento bought Bluefoot from Gene, it had a really good blog module within it and then when page builder was released, they took out the blog module. So I’m hoping at some point they bring that back. That’s another thing that separates it from some of the other content management systems out there.

James: That’s good distinction between, do you have basic content management needs, and I don’t mean that disparagingly, but do you do simple content management, which is blocks on pages, simple editorial, or do you have complex, distributed, publishing workflows across multiple teams, countries, languages, where you need a much more flexible solution. Most ecommerce platforms don’t have that in house, so if you need it then go to an enterprise CMS, whether you’re using a WordPress and extending it, or you’re using something like BloomReach or Episerver.

The other area you talked to about earlier was visual merchandising and searchandising. How good is it, how much do you expect this to change over time within Magento Commerce? Is it an area they are really investing in?

Paul: So I think the interesting thing for me with all of these features is – so I was at Magento Live a few weeks ago and Imagine before that, and I Magento is starting to gradually talk about bringing the Adobe products in to fill gaps in some of these areas.

Paul: So there was a use case for Adobe Target where they were using it for merchandising specific experiences alongside Adobe Experience Manager, to create optimal experiences. And I wouldn’t be surprised if some of those products end up coming down the line, are fully integrated into the product and then they maybe drive things forward a little bit for the enterprise customer. But at the moment, I think search is a particularly weak area, which I don’t think too many people would disagree with me on. So they lack a lot of features that anyone would want out of a search capability e.g. you can’t merchandise any of the results. You can manage basics, synonyms and redirects, but you can’t really do anything beyond that. There’s no underlying machine learning there or anything like that.

Paul: That’s an area where every client, pretty much every client I’ve had, has needed to pull in a third party. However, I expect that will probably get better. So Adobe have got a search product. There’s been a lot of rumours about that coming into Magento Commerce. So it’ll be interesting to see what happens there. Visual merchandiser – the one thing I like about it, is that it works and it’s like really clean. In the past with Magento 1, when it was using the old visual merchandising module, that very rarely worked. And I had very few clients that had really good experiences using that module. Whereas now, as much as the visual merchandiser module is basic and only allows you to essentially drag and drop at a category level, it is clean and it’s easy to use and it doesn’t have a steep learning curve. I would like to see it improve and I’d like to see the ability to apply rules across different categories. I wouldn’t be surprised if some of those gaps are filled by the Adobe products particularly amongst the bigger merchants.

James: Okay. Interesting. You mentioned Magento Live, so what were the big announcements? Was it all just standard, we’re enhancing the product type stuff? Or were there any surprising things that Adobe announced in terms of how they are going to be taking Magento 2 forward?

Paul: So there weren’t too many announcements, fewer than I’ve seen in the past at Imagine and Live. But there was definitely a focus on quality, definitely a focus on integrating the Adobe products. The biggest announcement I guess, was a real timeline for Adobe Sensei being built into the Magento platform, and that will be used for personalised product recommendations. There wasn’t too much detail in terms of how manageable that would be from a back-end perspective, and how you can build business logic into it, but it is a first level of personalisation that would be built into Magento. So that was the main thing. And then beyond that, there are a few community led project updates. One of them was that Adobe stock is now integrated into Magento, and you can use that within a page builder for example, and when you’re building out landing pages, and adding imagery to different templates in Magento. But beyond that it wasn’t really too much. It was more about the Adobe products and bringing those down market a little bit, the main ones being AEM and Adobe Analytics.

James:  I imagine one of the main reasons why Adobe bought out Magento was to integrate all of that marketing cloud stuff into the Commerce. A bit like Salesforce has been doing with its suite of products.

Paul: Yeah, it definitely feels like those two market segments are coming a bit closer together. Because I think at the time when Adobe purchased Magento, Magento was still servicing more small retailers real enterprise retailers, whereas now it definitely feels like more and more of the enterprise retailers are coming on board with Magento. And I’ve definitely heard more of those retailers taking Adobe products as part of the deal as well.

James: Yes. And the license fee incentives for multi-product, which you also see with Salesforce, they want people to buy into a journey with them, not a product. And the journey is gradual, Salesforce can provide all of your enterprise tools, not just the Commerce. Which makes sense. If you’re on three products, it’s harder for you to exit than if you’re just a one.

James: Ok so time for a final closing question. It’s going to be quite a chunky one to pull apart for you. We talked a lot about the fact that you can use Commerce and pay license fee, or can use Open Source and avoid a license fee. There’s different pros and cons to it. How does a business make the right decision? This is the question I often get asked and you know, I’ve got my view on it, but you get really involved in the solution and discovery process here. Is the decision purely based on costs? Is it about operational suitability? Is about the complexity of needs? Is it a mixture of everything? How do you help a client through that process of deciding whether they should be on Commerce or not?

Paul: Yeah, I think that’s a really good question and I think it’s a combination definitely. So if it was me, I’d probably start with like the overall objectives going into a project and the short term and long term functional requirements. Because I think a lot of the time, what it would come down to – one if you’re going to use the Commerce functionality, so that’s an obvious one. And then beyond that, it might actually be that if you are an enterprise level retailer and you want to bring in a personalisation engine – you wanted to do, for example, a headless build with a headless CMS and you weren’t therefore going to use something like page builder. And then as part of that, maybe you have like a merchandising product, and your B2C only.

Paul: And then you have various other kind of third parties like a PIM, so you might actually find you’re not really using any of Commerce anyway. But I think overall it just requires a lot of due diligence, and planning, and analysis on these third parties as well. My average client would probably use something like Klevu for the search and Nosto for personalisation. More and more are using a PIM as well. And even then, I think almost all of the clients that I work with have managed to get a good deal and they can kind of justify Commerce for the remaining areas. But if you’ve got additional third parties that you’re using, that then take out some of the other remaining features then I guess you could justify Open Source. And I think that’s why, when you look at some of the bigger retailers that use an Open Source, that’s actually why they use an Open Source, just because they didn’t feel like they were actually using much of the Magento platform anymore.

James: And it tips both ways, doesn’t it? Because you could have existing systems you’ll pay license fees for, you like the idea of consolidating into a platform where you’ve got them within one and you can avoid multiple relationships, but there’s other times are actually, yeah, you buy into a platform with a license fee but you’re only going to use maybe 60% of the capability. Can you justify that, can you get an ROI on that investment, on that 60%, or do you turn around and say, well actually if we could save a couple of hundred thousand pounds over the next four years, we could use that money to invest in other areas and actually get a stronger ROI. So I think that’s sensible parting advice. Think about where you should best spend the money and are you going to get the use of all the tools you’re paying for. Okay. Excellent. Any other parting comments you’d like to add? Any words of wisdom for our audience?

Paul: I’d say main thing, if I think about my client base which is almost entirely five to 20 million pound retail brands. In the past, I would say Open Source was entirely viable and Commerce was not necessarily needed. Whereas now, I do think that the features that are available in Commerce, and the fact that they all work and they’re all kind of working together, does generally justify the license cost. And I do think it enables you to be more efficient and do things properly. So with my average use case, I do think Commerce is a good solution. And then beyond that I think B2B Commerce is a no brainer, just because of all the features like credit limits, customer specific roles, all of that kind of stuff. I think that’s probably the strongest part of Commerce and if you are on the B2B side, then it’s a bit of a no-brainer.

James: Makes sense. Thank you very much for the insights and the practical advice as always. So that brings us to a close on this episode on Magento 2. I hope you’ve enjoyed it and found it interesting. Any questions you can add questions and comments to the website, but also feel free to contact me and Paul directly through LinkedIn or Twitter.

We’re also now live on Spotify and Apple Podcasts, amongst others, If you want to sign up and subscribe. And if you do want to hear about the latest podcast and get news direct to your inbox, you can sign up on the website to get alerts and we promise we don’t spam. We literally just send you an alert when a new podcast is available. So thanks, enjoy the rest of the day, and Paul catch up with you soon.