Tim Bucciarelli:
Welcome back to Shaping eCommerce with IronPlane. I’m Tim Bucciarelli, the Director of Engagement at IronPlane. We are today continuing our series on the future of eCommerce.
We’ve done several interviews on this topic, and Damien is here to give his point of view for all of our merchants out there about the future of eCommerce. I’ll let him give a quick intro and then we’ll dive right in.
Damien Retzinger:
Hi, I’m Damien Retzinger. I’m the owner of a small Magento Adobe Commerce called Graycore. I am myself a software engineer, so I’ve been doing software for about 12 to 15 years now. I’m one of the maintainers of Mage-OS, which is a fork of Magento, I’m a maintainer of faker.js, which is a really large Javascript library for generating fake data, and I’m a BDFL or pseudo-maintainer kind of like “maintainer god” of an angular PWA framework for eCommerce called Daffodil.
Tim Bucciarelli:
Okay, so if I didn’t understand some of those points, I’m sure a lot of our listeners haven’t understood them. I know what a maintainer and that role is. We will touch on Mage-OS a little bit later in this conversation because I think it’s a critical component of one of our questions.
What is BDFL, just out of curiosity?
Damien Retzinger:
So, it stands for Benevolent Dictator for Life.
Typically, if it’s something that you’re really committed to, it’s something you like doing a lot. So, for example, Linus Torvalds, the creator of Linux, has often been called the BDFL of Linux.
Tim Bucciarelli:
Got it.Damien Retzinger:
Same thing like the creator of Python. The many, many, many, many people who build cool things.
Tim Bucciarelli:
And there were probably several BDFLs in the past on Magento, when it was truly open source, is that correct?
Damien Retzinger:
I think there have been a lot of chief architects, but I would say not nearly as many. If we want to go all the way back down to like the Varien days, I don’t think so. I think there were architects, there were groups of people, but I don’t think it was ever like one clear driving vision.
Tim Bucciarelli:
Okay. Well, we’ll get into that a little bit later. So, your background is as a developer in various areas. Would it be safe to say that Magento is one of the core areas that you’ve been working in over the years?
Damien Retzinger:
Yeah, I’ve been doing Magento since about 1.6, so it’s been around 12 years. I graduated from university and my first job was building a Magento store.
Tim Bucciarelli:
Okay. And currently, your agency continues to build websites for clients who come to you specifically for the Magento platform, or do you work in other platforms as well?
Damien Retzinger:
We work in a number of different platforms, but primarily Magento is our focus area. We’ve done some Shopify builds, we’ve done one not-so-fantastic Shop-Ware builds, but primarily Magento and Adobe Commerce, so both the CE and the EE licenses.
Tim Bucciarelli:
Okay, great. So, when we’re talking about the future of eCommerce, we always start with one very broad question, and you can go with it wherever you’d like. Where do you see the future of eCommerce in the next five to ten years?
Damien Retzinger:
That’s a really good question. I think generally speaking we’re going to see . . . . Historically, there have been a lot of different players, right? So, you have a lot of different players, but these days the system has stratified. So you have your companies that serve the small market, the companies that serve the mid market, and the companies that serve the upper echelon.
I would assume we’re going to see consolidation of a lot of companies. I don’t know exactly how that’s going to happen, but I would assume there’s going to be some sort of consolidation. Just as we have Apple, and Microsoft, and Linux as the various competitions for operating systems, I would assume we’re going to see the same exact kind of thing for eCommerce platforms.
There’s too much complexity to have so many different ones and, as a result, over time we’ll end up with somewhat of an oligopoly.
Tim Bucciarelli:
I’m not sure if that strikes me as a good thing, to be honest with you. When you think about Linux, I kind of think about Linux because it’s very unique. When you think about Windows, everyone knows what Windows is. When you talk about Apple, when you talk about Google, those massive organizations that control so much of the internet today, Linux is a little bit unique because it’s really on its own and it’s more open than the others.
Yeah, I’m not sure how I feel about that, if we end up with these massive companies managing the major eCommerce pillars. Will there be a Linux and will it kind of keep everyone on their toes? I guess that’s kind of what I feel.
Damien Retzinger:
I would assume so. I have oft of late been saying that Magento is the Linux colonel of eCommerce. It’s one of the only platforms that I know in eCommerce that has probably a hundred thousand developers contributing to it over its lifetime. The fact that it’s open source is one of its huge selling points because of the variety of use cases that have been built into it over the years by all the developers who have used it.
Things like Shopify or things like BigCommerce, while they come from a great place and they serve their markets really well, and they have the opportunity to solve a lot of different problems, the contributing engineers don’t exist in the different domains. So, as a result, I would argue that they’re going to be somewhat limited in their perspective, they’ll focus on a certain scope, whereas Magento can serve a much broader audience.
Tim Bucciarelli:
That’s been our experience, as well, and that’s why IronPlane has been focused on Magento since 2008 or 2009, I think.
We also work with BigCommerce because we want to serve a larger portion of merchants. And some merchants, actually, who were on Magento 1 and migrated to Magento 2 are struggling to maintain their code base with all the updates and the patches, and so BigCommerce, and I’m sure you feel the same way with Shopify, BigCommerce was a nice way to offer a transition if we are approached by a company that says “Look, we’ve been on Magento for eight years and just can’t continue to spend $5,000 a month trying to maintain it and optimize it. We just want to go with SaaS.”
And so we introduce them to BigCommerce. Definitely, they’re going to be missing out on some functionality, some customization that they might have had, but it’s more approachable for them on a fixed cost month by month and less headache, I guess I’d say.
So, we’ve already touched on Shopify, BigCommerce, you mentioned Shop-Ware in the intro. Maybe if you can give us a quick rundown of your view on several different platforms, maybe touch on any particular use cases you think they fulfill or satisfy, and any particular information you’d like to talk about for any of those platforms would be helpful.
Damien Retzinger:
Yeah. So, generally speaking, I kind of have a philosophy about open-source software, which I think applies here. Open source software tends to work for small businesses, and I’m talking something in the zero to $30 million dollar a year range of revenue, approximately. And then open source also works for the really big companies, things that are in the billions of dollars of revenue per year.
The things in between are where the question marks lie. That’s where I would argue there’s some consideration for various platforms. So, I would say in the super-micro products, the super-micro businesses, Magento may work for you. But Magento, generally speaking, has a cost of ownership. You have to upgrade it, developers are hard to find, and there are a lot of little problems. But if you are a more technical person, if you’re willing to hack around just like you would with Linux, you could get something built, and it would work for you if you’re willing and able to maintain it. So, it works for those really small companies.
For those who are not interested in that, who don’t have the wherewithal to do that, my personal recommendation would be Shopify because it’s really painless to just spin up a store and sell whatever you’d like. You can get up and running on a store in like six hours. But it comes at a cost, and the cost is really customization.
For a super small niche business who’s trying to be an upstart, they’re trying to break into a new market, something like Shopify might not necessarily work for you because you might not be able to do something that’s different than the broad strokes that Shopify can give you the ability to do. And that’s where something like Magento, where you have an open source product where you have full customizability, might come into play. That’s, I think, where that comes into play.
Once you get past the like million dollar a year mark, that’s when the other products start to compete with one another. So, BigCommerce is an opportunity here, Shopify can be an opportunity here. In fact, it is for many businesses, it’s just kind of like natural growth, you’re already on Shopify, you stay on Shopify.
Tim Bucciarelli:
Shopify Plus, I guess?
Damien Retzinger:
Yeah, so maybe Shopify starts to get into some problems, you can’t do everything that you want to do, it doesn’t integrate with this platform, you need to write some custom code, or it becomes harder to maintain for whatever reason.
So you decide to look around, and you’ll run into Shop-Ware because that’s much like Magento, it’s open source, it’s customizable. You’ll run into Magento, of course. You probably will look at BigCommerce because maybe you want to stick with SaaS and you want to see, “Does this other platform have some integrations that I want to run with?” That’s the progression. And then you’re going to do that for a while.
But then you’re going to hit the really, really big companies, the companies that are in the billions of dollars, and they’re going to have ridiculously complicated problems. They could be operational problems, they could be security constraints, they could be development constraints on many different things, you have globalization problems, I want to run stores that are basically the same all around the globe, I need this team in this country to maintain this thing, so on and so forth. So you want to get global operations.
And that’s where things like Magento really start to shine, right? Because then, you have full control of the platform, you can create replication, you can do all sorts of fun stuff, and that’s where those things really, really show themselves. That’s where I think Magento also serves a role.
Up with that upper end of the market, you also have Adobe Commerce, you have Salesforce, so Adobe Commerce Cloud, you have Salesforce Commerce Cloud, you have --
Tim Bucciarelli:
SAP. Oracle, kind of, still.
Damien Retzinger:
Ehhhh, I think they decided to close, or Oracle Commerce. I don’t actually know.
Tim Bucciarelli:
The writing’s on the wall. I don’t think it’s actually been said or done, but that seems to be the trajectory.
Damien Retzinger:
Yeah. Some companies are still running like HCL, so there are some companies doing that, as well.
I’ve heard of other ones, like Spryker, I’ve heard of Kilo Commerce, I’ve heard of Commercetools, of course, we’ll touch on that probably a little bit.
Yeah, so that’s really when you start to hit the upper end of the market where you have more complicated problems. You can also hit those problems sooner, we can talk about composability and headless things, but eventually, you’ll start to hit some of those problems.
That’s my broad scope spectrum of the market.
Tim Bucciarelli:
So, in that context, when you think about SaaS platforms, why would SaaS be preferred by some businesses? What is it about SaaS that makes it more attractive to some businesses and less attractive to others?
Damien Retzinger:
It’s really in the customizability. Non-SaaS platforms allow you to change the logical rules about how your product works. In a SaaS platform, someone has dictated the rules to you, and you must operate within those constraints. You get some benefits. The benefits of SaaS are it’s cheaper, right? So you and all the other companies that are operating on that SaaS platform get to work within the constraints, and therefore you get an efficiency bonus, and you get some cost reduction.
So maybe that’s if you require less developers, or maybe you don’t even need a developer, but you still have to pay some monthly fee because you have to maintain the platform. It’s not your platform, you don’t have to worry about outages, etc., etc., not your business, not your problem. And that works for all the merchants, but there are many merchants where there is some custom requirement.
A great example that I have is a merchant that I work with who sells alcohol. They have complex alcohol requirements, you can’t just ship alcohol wherever you want, there are some requirements with that, so a SaaS platform didn’t solve that need for them, so they had to go a different route, they had to go with Magento because that fits a need of theirs.
Tim Bucciarelli:
Yeah, and I think I remember something also, it’s not just the front-end that’s customizable to your needs in the Magento platform. I’ve found that a lot of the kind of untapped potential of a platform like Magento is in the admin area, where you can really look at your internal operations for product management, for catalog management, for pick-pack-and-ship operations, and there are ways that you can customize your admin area to really help your teams be much more efficient in what they’re doing, whether it’s printing out your pick lists differently or barcodes.
Anyway, I just feel like that’s another area that you can customize to your needs, which again, in a SaaS platform you would be more limited.
Damien Retzinger:
You definitely are more limited. So, Shopify’s a great example of this. Just like you can build out a front-end for your customers to use, Shopify also has a GraphQL API for the backend. So if you wanted to build a custom UI for your operations staff, with Shopify you could very well do that, as well. You are limited to whatever APIs already exist in Shopify.
If you need to build some kind of third-party integration you’re going to start writing your own custom code anyway. Maybe Shopify’s not a great need for that, but for those companies where you want something that’s fluid, maybe you have like a small terminal that is very, very simple sitting somewhere in your ops department and you just to be able to tap a button and it does whatever it’s supposed to do. That could be a use case for Shopify.
But that’s not limited to SaaS versus something like an open-source customizable platform. If we want to think about it like that, I think there are three main areas, you have the admin UI, you have the backend, which is like all of the crazy complex project which makes up your system and all of the different services and things that you want to integrate with, and then you have the frontend UI, which is what serves your customers.
I think the main difference for a SaaS platform is the logical stuff sitting behind the UI, it’s the capabilities of that particular platform which are distinct to that platform. The problem is, for something like a SaaS platform, if you need a new capability you might not be able to build it. You might have to do some crazy, complicated thing in order to get it to work.
Whereas, with something like an open source platform like Magento or something like Shop-Ware, you have the ability to write that customization, bring it into the platform, and in the case of Magento you can write it in a way that if another engineer comes on their team it’s predictable. There’s a format, there’s a standard, there’s a plug-and-play API for building Magento plugins, everybody kind of understands how that works.
Tim Bucciarelli:
And so, Shop-Ware I’m not super familiar with. I know at least one person who works there who I met at Meet Magento, which is kind of funny, I met Ben Marks at Meet Magento wearing his Shop-Ware t-shirt. But I honestly don’t know that much about Shop-Ware other than the fact that it is open source and relatively new to the market. Is there anything worth knowing for merchants today about Shop-Ware?
Damien Retzinger:
It’s much like Magento. It has many of the hallmarks that Magento has. I would say it’s less feature-complete than Magento because it’s newer, right? So you always have to consider Magento is older and therefore it probably has other considerations, that is both a cost and a benefit, right? Magento has more plugins because Magento is also older. That’s really a consideration.
Generally speaking, Shop-Ware kind of started in the German market, that’s really where it comes from and they’re expanding more globally, so you’ll see less Shop-Ware stores over in the US, you’ll see some in Europe, but that’s primarily the focus of Shop-Ware at the moment, that they are trying to expand their global presence.
Tim Bucciarelli:
Okay. We’ll keep tabs on that and see how they’re going. So, the way that you described the backend UI, the frontend UI, and kind of the logic in the background, that strikes me as kind of starting the conversation about composable commerce. I’d like to touch on this a little bit, and if you could just give your own view of composable, headless, are they the same, are they different, and where that fits in the industry today and is it the wave of the future that everyone’s been talking about?
Damien Retzinger:
As the author of a “headful” front-end, I feel like I’m particularly qualified to answer this.
But to answer your question, headless and composable are different things. Headless implies that the thing, whatever it is, doesn’t have a front-end to it, that’s really what that means. So when I say a headful frontend, that means I’m talking about the thing that the user interacts with.
Now importantly, like we kind of just mentioned, that user could both very well be the customer, it could be the person who wants to buy the thing, or similarly, it could be the admin person, who’s trying to interact, add products to the site, all those kinds of things. So you could have a headless frontend for your admin panel, you could also have a headless frontend for your customers, so different use cases. Sorry, headful frontend and then, just for terminology purposes.
Tim Bucciarelli:
Do you like the term headless?
Damien Retzinger:
Ah, no. I think it’s unclear. I think there’s some vagueness. The composable doesn’t help, either.
Tim Bucciarelli:
Yeah, I thought composable was a solution to that problem. I never liked headless, but I thought composable wasn’t much better.
Damien Retzinger:
“Decoupled” is probably the best way to say it. So, if we talk about a decoupled frontend, “couple” is an important word in there because it implies a pair. So, you have the front-end and the back-end, and that’s a couple.
Now, you can have multiple frontends and one backend, and each one of them individually, frontend-to-backend, is a couple. So, decoupled front-end from backend, headless, headful.
But composable is slightly different. The front-end, the thing your business users or your consumers are operating with, talks to this headless thing, just talks to something. In many cases, it’s Magento, or it’s Shopify, or it’s Shop-Ware, or BigCommerce. But composable is not about one singular platform, but rather this thing doesn’t have to just be Magento, that thing could be Magento and, in a ridiculous situation, Shop-Ware. It could be Magento and BigCommerce, it could be Magento and Contentful, it could be Magento and HubSpot, or Magento and really whatever thing.
So, the basic idea is just the composition of all of these kind of best-in-class features from many different companies into a unified product. And that’s really where composable commerce comes from. So you take a lot of composable things, a lot of different services, that have best-in-class features, and then you stick a frontend, a headful frontend, on top of that headless thing, and poof, you have headful front-end, headless commerce, and the backend behind that is composable commerce.
Tim Bucciarelli:
The word “poof”. I think there might be some depth to that word, there might be something more in that word.
Damien Retzinger:
Quite a bit. Yeah, quite a bit. Because it could be REST, it could be GraphQL, it could be a million different things.
Tim Bucciarelli:
It’s very interesting to me that this concept, this architecture, has taken on such a trendiness, so that when I’m talking to a prospect who knows their stuff well enough, and they say, “We’re really planning to go headless or composable in the next five years and we need someone to help up get there. I look at what they’re doing and they are exclusively US, they are exclusively B2C, they don’t have very complex selling processes. And I look at it and I wonder is this really the right fit for them?
It is very trendy, it’s something that a lot of people want to talk about. It seems logically like “Ah, you’re distributing all of your function, you can develop it without impacting everything else, you can do an update here, an update over here. You can adjust the API to get more data in where you need it. It’s much faster.
But it also strikes me like this is a pretty complex architecture that we’re talking about, so why is it that everyone’s talking about it? Because to me, what I frequently bump up against with clients and prospects is “Oh my gosh, this is going to cost so much money.” And we’re dealing with a monolith with Magento. And they’re still struggling with “Oh my gosh, we have to pay the developer to do this and this and this?”
And then I think about this composable architecture and I think to myself “Gosh, who is this for? The billion-dollar companies that you were referring to earlier, or is there any composable architecture that maybe in five years will be suitable for a mid-market enterprise business?
Damien Retzinger:
So it’s a really interesting question. It’s a question that I’ve been working on for four or five years now, since I started Daffodil. But the question of composable commerce is, it’s great to have all this composition, right? It’s great to be able to pick and choose services that fit together nicely.
But if we want to draw a parallel problem, imagine the services, all these composable things, imagine they’re just different printers. So imagine each one, whether or not it’s HubSpot, or whatever, imagine they’re just different printers at your house. And you have a thousand of them.
But if the wire to each of those printers was different and the jack on the back of your computer was different, you would be annoyed if someone went and unplugged all of the jacks from both devices. You’d have to figure out where a wire’s going, what’s connecting, you can imagine that situation would be a mess, right?
With composable commerce, really what the eCommerce community is trying to do is come up with a standard, just like the jack for printers is a USB, or if you’re Apple maybe it’s some weird thing, but you have a USB or USB-C, we’re trying to come up with whatever that standard model is, and this is something that I’ve been trying to solve with Daffofil and the Vue Storefront guys are trying to solve it with Vue Storefront, the Commercetools guys are trying to solve it with Commercetools. Whatever that standard is, get everyone in the community to agree upon it, and then we move forward from there.
So, you have this standard, and behind the standard is all of the composition. So if we want to talk about computers and then talk about printers and things, it’s just that basic driver, right? So Windows has a plug and play driver for printers; you just plug the printer in and poof, you can print. That poof again, same complex topic.
That driver code is where the really interesting things lie. Composable commerce is great so long as you have a standardized interface on which to operate. That’s what the whole composable commerce discussion is.
I would argue if you’re going to go with like Commercetools because you think you’re doing composable commerce, you kind of are, but until Commercetools changes their API, or until HubSpot, which is one of the backend services of Commercetools, changes their API. The process will repeat again and again and again until we all agree upon a standard.
Similarly, if Magento does this kind of in a silo, Vue Storefront silo, composable commerce is an attempt by each of these individual companies to try and build a standard, and then in turn, when you start with a thousand standards and then each company tries to build an additional standard, now you have a thousand and ten standards.
So, it’s just an attempt. There’s something called the MACH Alliance, which you may or may not be familiar with, which is trying to do this over in Europe. We don’t have really a US counterpart to this yet, but there have been some discussions about how do we build an eCommerce standard so that we don’t have to deal with all of this ridiculous complexity.
Tim Bucciarelli:
Right. So, when I think about the standard, I think API. That’s not the standard itself, though. That’s just the method, right? And then an API can be achieved using either, and tell me if I’m wrong, React, GraphQL, Vue, is that correct?
Damien Retzinger:
No, a little bit off. So, a simple example of an API could very well be, let’s imagine you have a person, the person has a first name and a last name. Well, maybe I don’t like first names and last names, I just like name. If I have a person thing, it’s just name. But the guys over in Europe are like “Yeah, we like first name and last name. Let’s keep it like that.” Now the two standards need to talk to one another, “Well, I need to take the first name and last name from Europe and put a space between them and poof it’s name over here”, and now we can have a way to communicate between the things.
Take that same core idea, expand it to all of the different kinds of data which exist in eCommerce, so it’s first names, last names on the customers, the name of an item in the cart, the name of a product, the brand, people who want their brand field on a product, the UPC code, take all these complex ideas and if we don’t have a unified interface, none of these systems can talk to each other and it’s really complicated and everything has to like an individual wire plugged into it for that particular need.
Tim Bucciarelli:
So it’s like a mapping.
Damien Retzinger:
Yeah, exactly. That’s exactly what it is. Composable commerce is an attempt to build a mapping.
Tim Bucciarelli:
Okay. And the standardization, I mean, you’re never going to get everyone to agree Field 1 matches Field A and Field 2 matches Field B, you’re never going to get that to be standardized across every eCommerce provider. So the standardization that you’re talking about is related to what, then?
Damien Retzinger:
It’s an external thing. So, Commercetools, for example, is an external layer on top of all of these different providers to try and build that standard, whatever it is. And then, if they get enough marketshare, they are the standard, that is the standard; you must meet this standard. It’s just an attempt at standardization, same thing with Vue Storefront, right? Same thing I’m doing with Daffodil. You attempt to build a standard, house all of the complexity behind it, and then as a result everyone can use your platform.
There are a lot of crazy things you could do. You could have one frontend for a bunch of different stores, you could have a bunch of different things.
Tim Bucciarelli:
Okay. I don’t want this to turn into like “me learning” because this is a very interesting topic to me and I don’t have as much knowledge in this area, so I’m always very interested in learning more. But we can table that and discuss that later. We want to stay focused on the future of eCommerce.
So, this is going to remain an important part, I assume, given that you’re working so hard on Daffodil. For now and the future, is it eventually going to find the standardization and come down in price and be more approachable to merchants who may want an alternative to SaaS or a monolith?
Damien Retzinger:
Yeah, absolutely. There will definitely come a point in time. First of all, because there has been no standard, all of the standardization companies have to build their own standard, which means they have to repeat all of the features that everyone else did. So there’s like a time of R&D. And then once we accomplish that, there is some standard, and then once that happens everyone has to come to terms and say okay, this is the standard.
So there will come a time in the future, I think probably within the next five years, I think ten is a bit far, where that standard is agreed upon and we don’t really have this problem so much anymore.
Tim Bucciarelli:
I’ll look forward to it. Okay, good. I think we’ve touched on all of the components I wanted to touch on. I guess, as we promised early on in the conversation, you mentioned Mage-OS and we’ve already talked a little bit about Adobe and Magento Open Source, but can you talk a little bit more about what I’ll call the politics and the kind of wrangling that’s going on there? Where does Mage-OS fit, Magento Association, Adobe Commerce, I don’t want to get too political about it, but this is a topic that’s been very active on LinkedIn, I’d say, within the echo chamber of the industry. I don’t know that merchants really care; they just want something that works.
But we are all buzzing about this and I’d love to get your take on this, specifically about Mage-OS, because I don’t think many people know exactly what that is.
Damien Retzinger:
Mage-OS is a fork of Magento; currently, it is a perfect fork of Magento, which means that it’s exactly the same, we publish a mirror of Magento and, in fact, we actually do a little bit more than that. We actually publish a nightly of Magento, so if you wanted to check whether or not your store is compatible with the new version of Magento as of today, and not wait for the beta or not wait for the next release, which is currently in March, you can actually do that. So, if you can imagine, you’re an extension developer and you’re trying to publish extensions, you want to check is my extension compatible with what’s coming? You can do that.
We have built all of the tooling to rebuild Magento from its source code to something that merchants can use. And that’s the current state. So right now we’re a mirror, but over the next couple of months what we’re going to start to do is accept pull requests from the Community, allowing the Community to build a separate Magento. It will still be Magento at its core, we actually merge the code base that Adobe publishes every single day, whenever they do a merge, so we constantly keep up to date with what they’re doing. And we’re going to be figuring out the process of what happens if our changes conflict with Adobe’s changes, what do we do?
We have a strong preference for backward compatibility, so the goal is to basically take Magento Open Source and let the Community control it, as opposed to letting Adobe control it.
Tim Bucciarelli:
So, why? You’ve got Adobe Commerce. You’ve got Magento Open Source. And, as you said, those two seem to be kind of moving in slightly different directions. So, why not just go all in on Magento Open Source and say this is the thing and we’re going to take our Community energy and put it behind Magento Open Source rather than creating this mirror, which will eventually become its own fork, to have a third path, which for merchants, honestly they’re already confused. They’ve been confused with Magento since 2017, to be perfectly honest. So this is not doing them any favors.
But I’m just wondering why, why do you feel we need to move in this direction?
Damien Retzinger:
That’s a really hard question. But the answer lies in kind of one key area - how long does it take for me to fix a bug in Magento, give it to Adobe, and have that show up in the merchant’s code base? If you kind of had to guess a number, a time, give an approximate.
Tim Bucciarelli:
Three months.
Damien Retzinger:
No, far off. One and a half years, on average. So that makes a developer annoyed. There are a couple of problems. The first is I submit the fix, right? I go through the pain and the effort to not only find the bug, fix the bug, and then I have to write tests to make sure the bug can’t come up ever again. I submit it to Adobe for review.
The first thing that happens is that it never gets looked at. They have a robot which will go through unreviewed pull requests and close them. So I submit the fix and the first thing that happens is my fix gets closed. I submitted a fix, no one reviewed it, it got closed.
So then I upsetly go reopen it once again to repeat this process until a bot closes it again or I interrupt the bot and say please don’t close this. Maybe a year goes by and then someone reviews it, and then the process of trying to get a merge starts. But that requires a couple of things.
The first thing is that Adobe needs to agree first of all that the bug exists. Funny thing is, well most of the time the bug exists, the merchant ran into it, you fixed it. So, Adobe has to agree that it exists, and then secondarily to that Adobe has to agree that it impacts them, because it’s their code base. They control it. I don’t.
And this is the problem for the Community. We want to be able to merge pull requests, which improve our lives, our day-to-day lives, improve the merchants’ code base, no one wants bugs. Additionally, Adobe never merges new features that the Community submits, so good luck with that. The merchant wants new features, too, and the merchant would love to have new features provided by the platform, that they didn’t have to have their dev team write. And this is the core tenet of Mage-OS.
I was not one of the original signers of what was called the Open Source Community Alliance. It’s a letter that a group of devs submitted last year. But we all kind of grew frustrated and in that frustration we found energy. We want to build cool things, and I don’t want to wait a year and a half to build cool things. I will say in the past two months I have done more interesting things with Mage-OS than I have done with Magento in four years.
Tim Bucciarelli:
Wow.
Damien Retzinger:
And that’s really the power of the Community versus the power of waiting for a pull request.
Tim Bucciarelli:
The reasons are clear, and I hope that the Community continues to grow around Mage-OS. We are very much aligned philosophically with the open-source ideas and the origins of Magento, and we like the idea of that fork moving forward. So I hope that it gains more traction. I think it’s primarily, is it primarily in Europe or maybe more well-known in Europe than it is in the US?
Damien Retzinger:
I would say at the moment, yeah. Generally speaking, Magento tends to have somewhat more of a European focus even though it’s a US-based company. It definitely has more of a European focus. But one of the board members works for a company called Paradox Labs up in Pennsylvania, so it’s definitely got a US footprint. I have my cell phone in Richmond, Virginia; there are people from all around the globe who are a part of it. It may have more of a European focus, but there’s definitely a US footprint, as well.
Tim Bucciarelli:
Well, this is a little bit off track from the future of eCommerce, but Magento is a core component of that industry and I think it’s relevant to talk about the future of Magento and Adobe Commerce, and Mage-OS seems to be one of the likely candidates of what that future holds. Separate, of course, but definitely related.
So, just to wrap up our conversation about the future of eCommerce, I’m curious to hear if you have any ideas of particular innovations or maybe things that you expect to be happening over the next few years that people should be paying attention to related to eCommerce?
Damien Retzinger:
There are some interesting things that are somewhat related to the standardization thing that I think are interesting. If we want to speak about some of the things that Adobe is doing that are interesting, if you haven’t seen App Builder, which is their new thing they’re working towards, basically like drag and drop eCommerce. I don’t want to say it’s like Squarespace, it’s like Wix, it’s a little bit more complicated than that. They’re trying to build something which is more complex and solves more complicated use cases. But it’s super performing. So that is in the future.
You’re going to see a lot more standardization, not standardization, but rather like “services-ization,” “microservices-ization” of various features of eCommerce into either separate companies. So you might find someone who does search really well, Algolia is an example of this. Or you might find someone who does product recommendations really well, so you give them your product recommendation feed and they’ll spit back product recommendations.
So I would say the “services-ization” or carving apart of various feature areas of eCommerce is something to look for, and that’s composable commerce.
Tim Bucciarelli:
Yep. Okay, great. So, when we publish this, we’ll be sure to include in the show notes your information, how people can reach you, find you on LinkedIn, I assume. Are you active on any of the other social channels, or is that a good place for folks to find you?
Damien Retzinger:
Yeah. You can always find me on Github, github.com/damienwebdev. Same thing for Twitter, I’m on the same handle as well. If you want to look me up on LinkedIn, it’s just Damien Retzinger.
Tim Bucciarelli:
Well, thank you very much for taking the time to talk to us today. This is great because it’s a different perspective than what we’ve had in our other conversations, much more kind of technical-centric, which I appreciate and I think our merchants who have the internal technical chops will also appreciate.
I think we might have a conversation about Daffodil and Mage-OS to dig into those a little bit more, partially because I’d like to support those ideas and help expose them to more people, but also just because I love to learn about those technologies as well. So thank you for sharing your insights with us today, I appreciate it.
Damien Retzinger:
Thank you for having me.
For more insights on the future of eCommerce, check out our series on YouTube. For a free consultation, contact our sales team.