Blog OpenMage

Wie Du wahrscheinlich schon gehört hast, ist das eol (End of life) für “Magento 1” auf Juni 2020 festgelegt (wie hier angekündigt: https://magento.com/blog/magento-news/supporting-magento-1-through-june-2020 ).

Bereits vor einiger Zeit wurde das OpenMage-Projekt gestartet, um die Bugfix-Situation für Magento 1 zu verbessern, denn selbst wenn bereits ein Fix zur Verfügung gestellt wurde, wurden sie oft noch Jahre später nicht in offizielle Versionen integriert. (Dies änderte sich mit Magento 2 sehr zum Besseren.)

Dies war nur einer von mehr als 5 Forks, die ich in den letzten Jahren gezählt habe (und es waren wahrscheinlich noch mehr). Aber es ist der einzige, um den sich eine Gemeinschaft gebildet hat, die ein breiteres Spektrum von Benutzern und Mitwirkenden hat.

Lasse uns über einige Zahlen sprechen, inzwischen sind wir und haben getan:

• 9 + 3 Betreuer (9 mit Admin-Privileg)
• 68 Code-Beitragende
• 146 direkte Forks auf Github
• Über 200 zusammengeführte Pull-Anfragen
• 273 Sterne auf Github
• ~80 Besucher täglich auf dem Github-Repository
• 110 Follower auf Twitter ( https://twitter.com/OpenMageProject )

Wir strukturierten das Projekt in mehrere Phasen, die sich am offiziellen Unterstützungsstatus von M1 orientieren. Derzeit befinden wir uns in Phase 2.

Phase 1

Als es noch kein offizielles EOL gab:

Behalte ein Maximum an Rückwärtskompatibilität zum offiziellen Release bei, damit ein Wechsel ohne Verlust von Funktionen möglich ist. Es wurden auch keine neuen Features entwickelt.

Wir haben uns auf Bug- und Performance-Fixes konzentriert.

Phase 2

Ein EOL wurde angesetzt und nähert sich langsam:

Wir beginnen, kleinere Lücken bei der Rückwärtskompatibilität zu akzeptieren. Wir bereinigen den Code von Teilen, deren Verwendung nicht mehr empfohlen wird, da sie veraltet oder sogar schädlich sind.

Beispiele sind die Entfernung der View-Protokollierung (dieses Ding, das bei jedem Seitenaufruf in die Datenbank schreibt und in fast allen Fällen besser durch Google Analytics ersetzt wird) und die Entfernung des Compiler-Features (das in Magento1 nicht mehr benötigt wird, da PHP seinen eigenen OpCache mitbringt).

Phase 3

Archivierung einer geeigneten Umgebung für die kontinuierliche Integration, um genügend Stabilität für größere interne Änderungen zu gewährleisten (wir haben einige Leistungsverbesserungen für eav-bezogene Datenbankabfragen und den Index-Prozess im Allgemeinen in der Pipeline):

Auch in dieser Phase werden wir einen ordnungsgemäßen Veröffentlichungszeitplan aufstellen. Der aktuelle Plan sieht vor, jedes Jahr im Januar ein stabiles Major-Release herauszubringen, das neue Funktionen und mögliche Unterbrechungen der Rückwärtskompatibilität enthält, vielleicht eine Bugfix-Version pro Monat. Wir werden wahrscheinlich alle 2 oder 4 Jahre ein LTS-Release aufsetzen, je nachdem, woran die Benutzer mehr Interesse haben. Das erste LTS-Release ist das aktuelle Magento 1-Release, das wir weiterhin mit Fehlerbehebungen für mindestens 2 LTS-Releases versorgen und dann entscheiden werden, je nachdem, wo wir wie viele Benutzer haben.

Trotzdem werden wir mit den bestehenden Anbietern von Erweiterungen zusammenarbeiten, um sicherzustellen, dass eine spätere Hauptversion von OpenMage keine größeren Brüche verursacht.

Phase 4

Wenn wir diese Phase erreicht haben, sind alle unsere Prozesse stabil genug, um die tatsächliche Entwicklung von Features anzugehen.

Einige davon können ein leichteres Standard Theme beinhalten, das weniger Javascript-lastig ist, in den Google Pagespeed Insights besser abschneidet und mobilfunkfreundlicher ist.

Auch ein Auto-Updater, wie er mit WordPress etabliert wurde, könnte möglich sein, um die Situation für die Shops zu verbessern, die es vorziehen, selbst zu hosten und versuchen, die Wartungskosten niedrig zu halten.

Ein weiterer wichtiger Punkt, den man im Auge behalten sollte, ist die Sicherheit.

Wir haben zwar über die Gemeinschaft Kontakt zu einigen der Sicherheitsforscher, aber das hilft nur, Probleme zu beheben, die bereits gefunden wurden. Wir werden auch den Kontakt zu Hosting-Unternehmen aufrechterhalten, die gut darin sind, Sicherheitsprobleme aufzuspüren, die bereits im Internet auftreten.

Aber der beste Weg, Sicherheitsprobleme zu finden, sind erwiesenermaßen Bug-Bounties. Da dies einen gewissen Geldfluss erfordert, wird das OpenMage-Projekt diesen Teil nicht bereitstellen können.

Glücklicherweise gibt es einige Leute, die diesen Teil übernommen haben und eine Firma rund um dieses Sicherheitsthema aufbauen. Du kannst sie unter https://mage-one.com/ finden und verfolgen.

Manche mögen sich fragen, warum das OpenMage-Projekt versucht, mit Magento zu konkurrieren.

Der springende Punkt hier ist, dass Magento 2 sein Spiel um mehrere Stufen verbessert hat, und damit auch seine Zielgruppe. Magento 1 ist zwar recht leistungsfähig, und auch die Entwicklungsgeschwindigkeit ist besser als bei Magento 2, aber es skaliert nicht gut. Magento 2 ist für weitaus größere Händler und Projekte konzipiert und lässt sich noch weiter skalieren, um künftigen Anforderungen gerecht zu werden, die kommen werden.

Daher ist die Überschneidung in der potentiellen Zielgruppe recht gering.

Magento 2 eignet sich nun auch für große Projekte, die auf Magento 1 nie oder nur mit sehr großen Anpassungen laufen könnten. Daher eignet sich Magento 2 nicht mehr für viele kleine Händler oder für Self-Hosting. Mit Magento 1 konnte ein Händler es auf einem Webspace installieren, ohne einen Entwickler zu benötigen. Magento 2 ist selbst für einen einzelnen Entwickler manchmal schwer zu installieren.

OpenMage konkurriert nicht mit Magento 2.

OpenMage konkurriert mit Lösungen wie Shopware, Sylius und Shopify.

OpenMage ist für Unternehmen, die aus verschiedenen Gründen ohnehin nicht auf Magento 2 umsteigen würden, aber einen Wechsel auf eine der anderen Plattformen in Betracht ziehen würden. Für sie ist OpenMage die kosteneffizientere Lösung, da sie nur den Preis für ein Update, nicht aber für eine neue Plattform berechnet.