Blog OpenMage

As you probably have already heard, the eol (End of life) for “Magento 1” is set to June 2020. (as announced here: https://magento.com/blog/magento-news/supporting-magento-1-through-june-2020 )

Already some time ago the OpenMage Project was started, to improve the bugfix situation for Magento 1, as even when a fix was already provided, they were often not integrated into official versions even years later. (this changed with Magento 2 a lot to the better)

This was only one of more than 5 forks I counted in the recent years(and there were probably even more). But it is the only one where a community formed around, and which got a wider range of users and contributors.

Lets talk some numbers, by now we are, and we have:

• 9 + 3 Maintainer (9 with Admin Privilege)
• 68 Code Contributors
• 146 direct Forks on Github
• Over 200 merged Pull Requests
• 273 Stars on Github
• ~80 daily visitors on the Github Repository
• 110 Follower on Twitter ( https://twitter.com/OpenMageProject )

We structured the Project into several phases, oriented on the official Support status of M1.
We are currently in Phase 2.

Phase 1

When there was no official EOL set.

Keep a maximum on Backwards Compatibility to the official Release, to make it possible to switch without losing any features. Also no new Features.

We Focused on Bug and Performance fixes.

Phase 2

An EOL was set, and is slowly approaching.

We start to accept minor Backwards Compatibility breaks. Cleaning up the code from Parts which are not recommended to use anymore as they are outdated or even harmful.

Examples are the removal of the View Logging (this thing, which writes on every pageview to the database, and is for nearly all cases better replaced by Google Analytics), and the removal of the Compiler Feature (which in Magento1 is not needed anymore, since PHP brings its own OpCache)

Phase 3

Archiving a proper Continuous Integration Environment to archive enough stability to beeing able for bigger internal changes (we have some performance improvements in the pipeline for eav related database queries and the Index Process in general)

Also in this phase we will set up a proper Release Schedule. The current Plan is to have a stable Major release each January, which includes new Features and possible Backwards Compatibility breaks. Maybe one bugfix release per month. We will probably establish an LTS release every 2 or 4 years depending on what the users have more interest in. First LTS release is the current Magento 1 release, which we will continue to provide with bug fixes for at least 2 LTS releases and then decide depending on where we have how many users.

That said, we will work together with existing extension vendors to make sure a later major release of OpenMage will not cause major breaks

Phase 4

When we reach this phase, all our processes are stable enough to approach actual Feature development.

Some of this may involve a lighter default theme, which is less javascript heavy, performs better in the google pagespeed insights and more mobile friendly.

Also an auto updater like established with WordPress may be possible, to improve the situation for the Shops which do prefer to self host and try to keep the maintenance cost low.

Another big Point to keep in Mind is Security.

While we have through the community contact to some of the security researchers, this only helps to fix Issues, which got already found. We will also keep contact to hosting companies, which are good in tracking security issues which are already used in the wild.

But the best way to find security issues has proven to be bug bounties. As this requires a certain amount of money flow, the OpenMage Project will not be able to provide this part.

Luckily there are some people who took this part over and build a company around this security Topic. You can find and follow them at https://mage-one.com/

Some may wonder, why does the OpenMage Project try to compete with Magento.

The missed point here is, that Magento 2 did up its game by several levels, and with doing this, also their target audience. Magento 1 is able to perform quite well, and also the development speed is better than with Magento 2. But it does not scale well. Magento 2 is designed for way bigger Merchants and Projects, and to scale even further to match future needs which will come.

Therefore the overlap in potential target audience got quite small.

Magento2 is now suitable for big projects, which could never run on Magento 1, or only with very big adjustments. Therefore Magento 2 is no longer suitable for many small merchants or for self hosting. With Magento 1 a merchant was able to install it on a webspace without needing a developer. Magento 2 is even for a single developer sometimes hard to install properly.

OpenMage does not compete with Magento 2.

OpenMage is competing with solutions like Shopware, Sylius and Shopify.

OpenMage is for Companies, which for diverse reasons would not switch to Magento 2 anyway, but would consider to switch to one of the other Platforms. For them, OpenMage is the more cost efficient solution, as it only leads to the price of an update, not a replatforming.