Björn Schotte, der Geschäftsführer von Mayflower (einem auf PHP Entwicklung spezialisierten Dienstleister, der sich 2007 im Bereich e-Commerce durch die Zertifizierung einiger seiner Programmierer auf Oxid ausgerichtet hat) stellte bei der e-Commerce Conference dieses Jahr bereits zwei mal einen Vergleich von Magento, Oxid und xt:commerce vor.
Verglichen werden die Aspekte Performance, 3rd party Module, Dokumentation für Entwickler, Community, Erfahrung im Bereich Enterprise, Code Qualität, Modernität und TCO. Die out-of-the-box Funktionalität der Shopsysteme wird hierbei außer Acht gelassen, was mich doch sehr verwundert, da sie nach meiner Erfahrung eine große Rolle bei der Wahl des Systems für Interessenten spielt und sich auch erheblich auf die TCO auswirkt. Magento hätte bei diesem Aspekt weit vor Oxid gelegen.
Bei der Next09 vor zwei Wochen hatte ich mich direkt mit Björn über seinen Vergleich ausgetauscht und wir sind zu der Erkenntnis gekommen, dass Magento bei dem viel diskutierten Punkt out-of-the-box Performance sicher noch seine Schwächen hat, es für die in der Präsentation angesprochenen Enterprise Interessenten jedoch wenig von Interesse ist wie sich das System ohne Optimierung und nicht zugeschnitten auf die Anforderungen verhält. Wenn man sich bei den Referenzen von Oxid und Magento umsieht und dort die Ladezeiten vergleicht sieht man schnell, dass sich diese bei den Top Referenzen auf einem Niveau bewegen. Der VOD Shop von Premiere (Ein Oxid Shop an dem auch Mayflower beteiligt war), wie auch der online Shop von Jack Wolfskin (Ein Magento Shop umgesetzt durch Visions) liegen beide konstant bei ca. 1,3 bis 3,5 Sekunden im Seitenaufbau je nach Seitentyp.
Bei den Themen Modernität und Codequalität muss ich aus meiner Sicht und der unserer Entwickler, die sich mit beiden Systemen beschäftigt haben, den Aussagen von Björn in der Präsentation widersprechen. Technisch ist die schlechte Bewertung von Magento im Vergleich zu Oxid dort nicht nachvollziehbar.
Zusammenfassend denke ich, dass Oxid in jedem Fall den richtigen Schritt gemacht hat, indem sie den Weg von Magento eingeschlagen haben und zum kommerziellen Open Source Anbieter geworden sind. XTC scheint mittlerweile weit abgeschlagen. Wie gut sich Magento und Oxid im Markt der Enterprise e-Commerce Lösungen platzieren können mit ihren offenen Konzepten wird sich wohl in den nächsten 12 Monaten deutlich zeigen. Jochen Krisch sieht in Magento und Oxid jetzt bereits gute Alternativen zu individuellen e-Commerce Lösungen. Genau diese Einschätzung kann ich auch bestätigen, da die meisten Magento Projekte, mit denen ich mich aktuell beschäftige, in-house Lösungen ablösen.
Alexander Ringsdorff 
Hallo Alexander,
vielen Dank für deinen konstruktiven Beitrag. Die out-of-the-box Funktionalität zu vergleichen, hätte die Präsentation gesprengt. Diese ist als Whitepaper verfügbar und steht den Teilnehmern der E-Commerce Conference zum Download zur Verfügung.
Hierbei sehe ich einen leichten Vorsprung bei OXID, jedoch hat auch Magento ohne Zweifel eine Menge out-of-the-box Funktionalität zu bieten.
Was Code-Qualität betrifft: vergleicht man mal den Kommentar auf der Präsentation zu Slideshare
“Der letzte Verweis auf das Magento Forum auf Slide 18 ist Unsinn! Core Dateien müssen in Magento NIE direkt überschrieben, sondern dupliziert und im local-Scope angepasst werden, so dass die Anpassungen bei Updates erhalten bleiben.”
… so muss ich doch sagen, dass dieser Weg wirklich “it’s so nineties” ist :-) OOP Vererbung wäre hier das richtige Mittel der Wahl (kann man sicherlich auch bei Magento, die Frage ist aber ob man hier gezwungen wird oder nicht). OXID zwingt den Entwickler eher dazu, über Vererbung zu arbeiten, was am 2 Jahre dauernden Refactoring liegt, das die Jungs mit V4 hinter sich haben und damit eine deutlich bessere Code-Qualität bieten als Magento und xt:commerce.
Alleine daran, wieviel Aufwand OXID in die Bereiche QA, automated testing, test reports, code coverage, ticket stats etc. steckt, sieht man den technologischen Vorsprung bei OXID schon sehr stark. Magento kann man das nicht so recht anlasten, schließlich sind sie erst seit einem Jahr (war ja auch deine Zustimmung) so richtig auf dem Markt.
Gleichwohl denke ich, dass Magento einen guten Vorsprung im Bereich der Community hat. Hier hat OXID noch Nachholbedarf und ich finde es etwas schade, dass xt:commerce in diesem Punkt so abstürzt. Ob das ausreicht, muss jeder für sich selbst entscheiden.
Viele Grüße, Björn.
Hallo Björn,
Zwang ist hier das richtige Stichwort.
OOP Vererbung ist für Fälle wie oben beschrieben die richtige Wahl und geht mit Magento. Wir sind damit bisher bei allen Projekten ausgekommen und mussten nie Klassen duplizieren, weder für die Hotelbuchungsseite, noch für die mandantenfähige Supplierplattform für mydeco.
Zu dieser Vorgehensweise wird man in Magento aber nicht gezwungen. Entwickler haben prinzipiell alle Freiheiten, so weit wie sie wollen in alle Bestandteile des Systems einzugreifen. Sogar ins Zend Framework, was Varien selbst auch getan hat, um die Apc, File und Memcached Backends von Zend_Cache zu customizen. Es existieren somit keine Grenzen für Anpassungen und Erweiterungen.
Diese Freiheit hat natürlich seinen Preis. Durch fehlende Grenzen in der Architektur kann die Softwarequalität stark in Mitleidenschaft gezogen werden. Das Aufrechterhalten der Qualität erfordert hier mehr Aufwand als bei “ausbruchssicheren” Frameworks. Das Zend Framework zählt mit seinem Use-At-Will Konzept sicherlich nicht dazu (was einer der Gründe ist, warum Varien sich für dieses Framework entschieden hat).
Für mich persönlich ist es wichtig, nicht in einem Framework oder einer bestimmten Architektur eingesperrt zu sein. Ich will zum Tag X die Option zum Ausbrechen einfach haben. Über die Konsequenzen muss man sich als Verantwortlicher aber im Klaren sein und Kosten und Nutzen abwägen können.
Viele Grüße,
Dimitri
Da hier so schön die Praxis von Magento, das Dateien dupliziert und im local-Scope angepasst werden, angesprochen wird, eine Frage dazu: Was passiert, wenn die originale Datei, die man für die Anpassung herangezogen hat, von Seiten Varien bei einem Update geändert wird. Wie passt das ins Thema Updatesicherheit? Oder sehe ich den entscheidenden Punkt nicht?
Der entscheidende Punkt ist, dass man normalerweise nie Dateien duplizieren und im local Scope ändern muss. Man kann, muss es aber nicht, da Anpassungen und Erweitetungen wunderbar über Vererbung und Anpassung der Konfiguration der Objekt-Factory lösbar sind.
Um Ihre Frage zu beantworten: die Änderungen durch ein Update von Varien würden nicht berücksichtigt werden, Sie müssten sie mit Ihrer modifizierten Klasse mergen. Deshalb rate ich von dieser “Praxis” ab.
Danke für die Antwort, genauso dachte ich mir das.
Wobei natürlich auch bei Vererbung und überschreiben einer Funktion sowas auch passieren kann, wenn sich die überschriebene Funktion ändert, oder?
Ich sehe außerdem die Schwierigkeit bei Modulen, wenn von Grundklasse A die Module B und C mittels Vererbung jeweils die gleiche Funktion überschreiben wollen. B weiß ja nichts von C und umgekehrt. Ich gehe dabei von fertigen Modulen aus, die ja für den Shopbetreiber die Sache vereinfachen sollen. Hier wäre für mich aktuell wiederrum nur eine Lösung, das ein Programmierer ein Modul erstellt, das die Funktionen von B und C in einem vereint und dann A erweitert, oder gibt es da gute Ansätze (Stichwort reicht)?
Klar, das kann passieren. Jedoch bietet sich viel weniger “Reibungsfläche”, wenn man mit Vererbung arbeitet, da man sehr gezielt Änderung vornehmen kann.
Der Fall, wo Module B und C die selbe Klasse von A überschreiben führt natürlich zu einem Konflikt, so dass die Module nicht mehr miteinander kompatibel sind. Eine Lösung dafür wäre diesen Konflikt im local Scope (angenommen B und C sind Fremdmodule und liegen im community Scope) aufzulösen, indem man sie vereint.
Module, die diese rewrite Möglichkeit verwenden, greifen aber schon ziemlich tief in Magento ein. Übliche Erweiterungen wie Paymentmodule, Module für spezielle Datenexports und -imports, etc. kommen auch ohne rewrites aus.
Ich habe ganz schlechte Erfahrungen mit xtcommerce gemacht.
Das System ist leider nichts im Vergleich zu ähnlichen Produkten wie z.B. Magento auf dem Markt. Quellcodes sind zu großen Teilen verschlüsselt, Adonns werden verschlüsselt ausgeliefert, sodass keine oder nur geringfügige unzureichende Modifikationen möglich sind.
Lizenzen lassen sich nicht übertragen, man darf keine nicht mehr benötigten Lizenzen weiterverkaufen und der Support lässt auch zu wünschen übrig.
Letztendlich muss es jeder selbst wissen, jedoch kann ich nur von der Benutzung abraten.
Danke für den Vergleich. Magento ist nach meinen Erfahrungen einfach zu träge. OXID sehr kompliziert, aber es lohnt sich dort hinein zu arbeiten. Einfachste Anpassungen sind bei OSCommerce und XTCommerce möglich, aber leider kein Designwunder.