The beginning of the end of the Magento Open Source version?

The developer community for the Magento Open Source version is likely to be split in two. A significant number of Open Source developers plan to leave the current Adobe-driven community and continue as a separate organisation. At the same time, this means the division of the Magento product. A large proportion of developers are tired of the delay in approving and releasing new features and even bug fixes. The developer community has shrunk. No road map has been published for the software. The blaming fingers of the community point in the direction of Adobe. Differences of opinion about the architecture development have added to the contradictions. This article focuses on what is the impact of all this on the Magento Open Source version.

North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.

1 October 2021

Heikki Toivo

The scale of the potential effects is considerable. Most of the Magento-based online stores in use in Finland are based on the Open Source product. In our major e-commerce survey this year, Magento is represented by 42 Open Source and 11 Commerce installations. Only companies with a turnover of more than one million have been included in the survey. It is worth noting that a large part of the Commerce database is also installed on own servers, not necessarily Commerce Cloud.

Some background for the split

Toronto-based Magento consultant Talesh Seeparsan sheds light on the problems the community has been experiencing in his video. According to him, the division has been planned for months. The plan accelerated after the Adobe webinar hosted by Igor Miniailo and Nishant Kapoor on April 27, 2021, where they explained the role of microservice architecture in future Adobe Commerce Cloud development. Miniailo and Kapoor spoke about how the logics provided by Magento can be exchanged through interfaces and how Adobe I/O functions can be used to enrich e-commerce. This is the so-called Strangler Pattern, which can be used to gradually modify monolithic software to be more modular. There is a clear difference of opinion between the developer community and Adobe. The serverless features used by Adobe are very well suited to cloud services, but may be a bottleneck for server-minded software. The developer community, on the other hand, sees the monolithic solution as a highly functional e-commerce platform. At the time of writing, more than 1,500 people had signed an open letter to the Magento community to discuss the division in more detail.

Significance of the split for on-premise Magento customers

What changes for Magento customers running the software on their own servers? There probably won't be a difference at first, but in the longer term, the market weight of Magento Open Source will decrease. A fragmented developer community will not be able to make the same marketing efforts as a commercial operator. Take Linux, for example. Its popularity exploded with various commercial distributions. Red Hat, which is now owned by IBM, was helping the rise. Acquia invests and contributes significantly to Drupal's development. The development of WordPress is also actively funded and supported by Automattic. In addition to investing and lobbying, it is worth remembering the importance of companies in marketing and building credibility. The aforementioned companies are companies running massive businesses that don’t really have anything to do with ideological Open Source operations. And can Magento Open Source users help with this situation by taking responsibility for development? The answer is very likely a resounding no. There are a significant number of e-commerce merchants in the Magento Open Source user base who have neither the desire nor the ability to develop software that requires in-depth skills and commitment. They just want to have an affordable and versatile e-commerce system.

The strangest situation is with merchants running Magento Commerce on their own servers. What happens to their platform when development inputs are put into the cloud-based system? Even today, the customer experience is that support comes slowly, even in urgent situations. It is expected that users will be offered an upgrade path to the Commerce Cloud and then the product will be run down.

Significance of the split for Adobe Commerce Cloud customers

For Adobe Commerce Cloud customers, this may be good news. Adobe can focus resources on meeting the needs of its large customer base. According to Adobe, the revenue of Adobe Commerce Cloud's online business typically exceeds 5 million Euros per year. They are guaranteed to have different requirements than companies with a turnover of tens of thousands or hundreds of thousands of Euros a year. Maintaining conflicting requirements in the same product family is impossible for a long time. The situation is more problematic for versions of Magento Open Source or Commerce installed on your own servers. If either of these are in your company’s future plans, you might want to reconsider it.

Significance of the split for Adobe

Moving Adobe Magento Open Source out of its control may be a relief for Adobe at this point. Adobe has gained a lot from it, perhaps enough. Why would Adobe have a different strategy for one of its products? That might look a little strange. Let's think about Adobe Commerce Cloud customers. What does it mean to them if Magento Open Source’s responsibility for development ends with Adobe? Nothing. Adobe customers rely more on Adobe than on a fragmented developer community. That’s why they are Adobe customers in the first place.

Significance of the split for the developer community

The developer community feels they have been scammed. We can only hope for the best for their glorious project, but at the same time, they should fear the worst. The future will tell whether they even can use the name Magento.

(This article has been translated from the Finnish original. Read the original article.)


Starting an ecommerce renewal project? North Patrol's team helps you understand customer needs, clarify business requirements and find the best digital solutions to meet your goals.

Read about our services

Request a quote

About North Patrol

We are a team of ten consultants, all of whom are experienced designers and technology experts. Every year we design and prepare over 50 different online services and information systems. Our customer satisfaction is very high (9.5 out of 10), and we have helped many customers transform their digital services.

Read more about us

How we differ from our competitors?

  • We specialize in digital service design

    We specialize in high-quality design and requirements specification of digital services. Our mission is to help customers succeed in their software project by creating the best possible foundation for implementation – whether it is an agile implementation done inhouse, a project done with a partner, or a publicly tendered project.

  • We don't sell coding or licenses

    Many software companies recommend software solutions that they also implement themselves. We don’t do that. We don’t do software implementation projects or have partnerships with technology providers. Our perspective on the software market is broad, as it should be for our customers. Our goal is always to find the best possible software solution for our customer, whether it’s a custom-built solution, a SaaS service, an open-source platform, or a combination of these.

  • We are realistic and forward-thinking

    We design digital service concepts, implementation methods and architectures that are sustainable and can be further developed. We place great importance on the feasibility of software solutions, the availability of good partners and the predictability of costs.

Back to top