Was hätte aus Magento werden können, wenn es nicht viel zu früh ausgerechnet an Ebay gefallen wäre. Nach diversen Zwischenstationen bei Paypal hat Ebay Magento nunmehr in den – ebenso problembeladenen wie führungslosen – Enterprise-Bereich abgeschoben.
Nach der jüngsten Entlassungswelle gab der scheidende Magento-Gründer Roy Rubin diese Woche seine Abschiedsvorstellung. Dass man die Magento Imagine parallel zur Meet Magento gelegt hatte, obwohl Deutschland für Magento angeblich der zweitwichtigste Markt ist, spricht eigentlich Bände.
Ein paar kleinere Neuerungen gab es zwar. Mit dem lange überfälligen Magento 2.0 kann der Online-Handel allerdings frühestens Ende 2015 rechnen:
Impulse für den Online-Handel gehen von Magento schon seit Jahren nicht mehr aus (siehe auch Wo stehen wir im Online-Handel technologisch?).
So ist Magento etwas für Liebhaber geworden. Der Markt hat sich weiterentwickelt – sei es in Richtung Vernetzung oder in Richtung Anwendungen. Doch bei Magento scheint die Zeit irgendwie stehengeblieben.
Geblieben ist eine überaus rührige Entwickler-Community, die allerdings zunehmend abgekoppelt agiert vom offiziellen Magento und die daher auch nicht davor zurückschreckt, den Finger in die Wunden zu legen (siehe The Harsh Truth of Magento Enterprise) und dabei ihren Spaß hat.
Über unsere Lieblingssession („Female Commerce: Standard-Shops sind nicht “neutral”“) auf der Meet Magento hatten wir schon berichtet.
Frühere Beiträge zum Thema:
- Exchanges #40: Was ist eigentlich bei Ebay los?
- Exchanges #12: Shopsysteme gestern, heute und morgen
- Ebay und die Sorgen mit dem Enterprise-Geschäft
- Magento-Gründer Yoav Kutner über seinen Ausstieg bei Ebay
Kategorien:Open Source, Shoptech
Im Wesentlichen handelt es sich doch um eine Enterprise-artige Release Kommunikation. Das beisst sich, sobald man die Open Source Arena betritt, denn hier geht es um eine transparente, kontinuierliche Kommunikation. Kommunikation ist dort keine Einbahnstrasse.
Denn da sind die Scheinwerfer auf AN gestellt. Vermutlich wäre der Aufschrei nicht sonderlich groß, wenn es eine stete Kommunikation über Pläne (ja, auch diese ändern sich!) gäbe.
Und auf dem entsprechenden GitHub Repository, auf dem sich der Quellcode von Magento in einer halb-offenen Weise findet, nicht unheimliche Stille wäre – was sich allerdings in der jüngsten Zeit etwas geändert hat.
Die Frage ist nur: für wie lange?
Insofern: die Karawane sollte links und rechts des Weges schauen, was es sonst noch so gibt. Das gilt übrigens auch für Händler, die oft noch dem Marketing der Hersteller erlegen sind und bereits vor Projektbeginn geistig auf ein System verankert sind. Etwas mehr Offenheit wäre auch hier hilfreich.
Ja, was hätte aus Magento werden können wenn es nicht an EBay gefallen wäre.
Dann wäre wohl inzwischen magento3 mit ersten Beta release veröffentlicht worden. Was wiederum eine Vielzahl an Händlern und Modul Anbietern verärgert, weil es wieder BC Breaks gibt.
Der Marketshare wäre also anzunehmender weise wesentlich geringer, vermutlich sogar fallend in absoluten Zahlen. Die Qualität an Modulen und deren Auswahl wesentlich geringer, da die Leute nicht viel Geld/Zeit darin investieren wollen, wenn die nach 2 Jahren schon wieder überarbeitet werden müssen.
Diese Pläne waren vor der Übernahme durchaus absehbar, und haben sich erst nach der Übernahme durch EBay darauf geändert, lieber ein langfristig Stabiles Basissystem zu bauen, auch wenn das zur Folge hatte, längere Zeit keine Zeitpläne herrausgeben zu können. Schließlich erfordert die Entwicklung eines solches Systems durchaus ein großes maß an Forschung und tests. Das wurde durch EBay intern erledigt, anstatt wie bei anderes Systemen den User als Testobjekt zu verwenden um zu sehen wie es wird.
Konzern übernahmen sind nun mal leider etwas, dass eine ganze Zeit lang jede menge Ressourcen „verschwendet“. Aber wir haben nun seit einem Jahr einen stetigen Einblick in die Entwicklung. Bekommen regelmäßig auch auf anderen Kanälen Updates über Entwicklungen und es wird auf mehr als nur einem Weg nach Feedback zu Plänen, Ideen und Entscheidungen gefragt.
Vielleicht hat Magento einiges an vertrauen verloren durch die Lange Zeit bis zum nächsten Release, aber die Version 1.x wurde ja trotzdem weiter entwickelt und es gab jedes Jahr ein neuen Release. Die Updates hier nebenbei erwähnt, sind seit der Übernahme von EBay auch wesentlich stabiler mit weniger BC breaks geworden.
Aber wenn die anderen Shopsysteme weiter mithalten wollen. Ihr habt den Zeitplan. 1,5 Jahre.
Wenn ihr bis dahin nicht geschafft habt gleich auf zu ziehen mit dem was Magento2 bieten wird, könnte das ein leichter Sieg werden. Unterschätzt nicht die Bedeutung ein großes unternehmen wie EBay im Rücken zu haben, wenn es um e-commerce geht. Und bedenkt auch, die Nationalen Märkte ticken sehr unterschiedlich.
Björn, musst du überall deine lauen Lüftchen ablassen, ich kann gern davon schwadronieren, welche Bugs bspw. ein Oxid seit Jahren mit sich rumschleppt oder die grausame Architektur, die keine ist usw. Aber naja es ist natürlich leichter auf etwas drauf zu hauen, wenn man keine Argumente hat, was eher im Geschäftsbereich bzw. der Kommunikation des Herstellers liegt.
Vielleicht kannst du uns ja alle erleuchten und die Fackeln im Sturm aufzeigen, die das alles viel besser machen?
… da bin ich sehr gespannt drauf …
Magento ist nicht vollumfassend toll, aber so ziemlich das kompletteste und ausgereifteste System unter den PHP Shopsystemen mit einem großen Support an Agenturen und Community.
Es spricht rein gar nichts dagegen, dass Björn hier seine Meinung abgibt. Falls Ihr ein persönliches Problem miteinander habt, dann macht das bitte untereinander aus.
Hallo Matthias,
danke für deine Meinung.
Im Prinzip ist es für mich zunächst einmal belanglos ob Magento, OXID, Shopware, sylius.org (noch in den Anfängen), http://leaphly.org/ (noch nicht ausprobiert) , http://thelia.net/ (noch nicht ausprobiert), sphere.io oder andere Frameworks/BaaS Lösungen genutzt werden.
Dass ich OXID durchaus kritisch betrachte (und wir es dennoch auch neben anderen Lösungen und Individual-Entwicklungen einsetzen), weiß OXID nicht erst seit http://blog.mayflower.de/3218-Das-neue-OXID-Partnerprogramm-im-Detail.html
Was die Fackeln im Sturm betrifft, deklinieren wir das doch einfach mal der Reihe nach kurz durch:
Der „Enterprise“-Bereich mit seinen lahmen Release-Zyklen wird umdenken müssen, wenn er weiterhin innovativ bleiben und morgen überleben will. Dh. Kunden müssen umdenken.
Ich weiß aus Gesprächen mit Kunden – und zwar nicht nur im E-Commerce Umfeld -, dass sie alle gerne flexibler, schneller, innovativer (Budget-Verhältnis run-the-business zu change-the-business) wären.
A-L-L-E. Wirklich alle.
Die Welt da draussen ist stürmisch. „Sicherheit“ war gestern. End-to-End-Planung war vorgestern. Agile Methoden sind da nur ein Teil und ich will jetzt auch wirklich nicht das Scrum-Kanban-Fass aufmachen. Doch eines der Prinzipien aus der Agilen Welt möchte ich heraus stellen:
Embrace Change.
Change ist eingebaut. Change ist ein so fundamentales Grundprinzip in der Anwendung dieser Methoden, dass es wunderbar passt zu der heutigen Welt, in der die Kunden und Situationen nicht mehr vorhersagbar sind. Der Zusammenhang zwischen Ursache und Wirkung hebt sich immer weiter auf.
Ich kann verstehen, wenn einem das Angst macht, weil es Unsicherheit bedeutet. Was viel wichtiger ist, ist mit dieser Unsicherheit umzugehen. Die Welle zu reiten, auf der Eure Kunden unterwegs sind.
Das wiederum wirkt sich auf die IT-Landschaft und ihre Systeme aus. Wo dein Markt unscharf wird, musst du schnell reagieren, weil du in deiner Software CHANGE realisieren musst. Das kann zum Einen dadurch erreicht werden, in dem Komplexität in Software-Architekturen und -systemen reduziert werden. Auf der anderen Seite muss Komplexität erhöht werden, um mit der erhöhten Komplexität der Märkte Schritt halten zu können.
Wenn du also weißt, dass du flexibel – und noch dazu „ein datengetriebenes IT-Unternehmen, das zufällig auch verkauft“ – sein musst, weil du den CHANGE realisieren musst um morgen überleben zu können, dann benötigst du Software-Systeme und -Architekturen, die auf diese Möglichkeiten positiv einzahlt.
Ich bin der Meinung, dass alle drei genannten Systeme da ihre mehr oder weniger großen Schwachstellen haben. Shopware scheint im Moment einen guten Vorsprung zu haben, was die Standardisierung auf dem Symfony2 Framework betrifft, und geht konsequent den Weg der Modernisierung.
Eine andere große Schwachstelle ist das, was ich in Gesprächen gerne als „Monolith“ bezeichne. Shopping Clubs waren gestern, Amazon Dash ist heute und wer weiß wie die Kunden morgen einkaufen werden.
Wenn die „Standard“-Systeme nicht entsprechend echte Komponenten-Orientierung aufweisen, dann habe ich auf dem Schuldenkonto (quasi das Gegenkonto zur Flexibilität) einen hohen Berg, den ich erst einmal abtragen muss. Das wiederum kostet Zeit und Gewinn, den ich an einen anderen, flexibleren Mitbewerber verliere, weil ich nicht in der Lage bin, online mein Geschäftsmodell weiter zu entwickeln.
Hinzu kommt, dass die Hersteller häufig technologisch mehr oder weniger stark hinterher hinken. Auf der einen Seite ist es verständlich, das ist bei gewachsenen Systemen oft so, und in diesem Kontext auch wenn man mal schaut, woher die Systeme kommen: aus der Installationsbasis von kleinen Shop-Händlern, denen damals der Monolith ausreichte.
Darüber hinaus ist es wichtig, dass die „Monolithen“ die modernen Technologien und Tools nutzen, die in der Entwickler-Community gerade en vogue sind. Damit meine ich nicht, dass ständig hinter den neuesten Trends hinterherzuhecheln ist.
Dies ist aus zwei Blickwinkeln zu betrachten:
1.) Recruiting. Auch wenn’s mich als Dienstleister schmerzt, aber jeder Kunde der keine eigene IT-Entwicklungsabteilung hat, investiert nicht in seine Zukunft. Die Entwickler von heute, und ganz besonders die (guten) Entwickler von morgen, die wollen dort arbeiten wo moderne/aktuelle Tools und Methoden im Einsatz sind. Es ist ein eklatanter Wettbewerbsvorteil, nicht im selbstgeschriebenen MVC von herumwühlen zu müssen, sondern im standardisierten zu arbeiten
2.) niedrigere TCO und besser Time-to-Market: mit einem Shop-System, das selbst auf etablierte Standard-Frameworks setzt und moderne Tools, Abstrahierungen und Schnittstellen bietet, bin ich in der Lage, eine niedrigere TCO und eine bessere Time-to-Market mit niedrigeren technischen Schulden zu erlangen.
Wie ich neulich schon auf twitter und in meinem Blogbeitrag schrieb: ich will gar nicht in die „Mein OXID ist aber besser als dein Magento ist aber nicht so schön wie mein Shopware“-Diskussion rein. Es geht um eine andere Ebene und, um das jetzt mal konkret zu formulieren, um eine andere Fragestellung:
Wie muss Ich als Händler, wie müssen meine IT-Systeme und wie muss mein Shop-System aufgestellt sein, um die Gewinne von Morgen gut einfahren zu können, auf einer Wegroute, die ich heute noch nicht kenne?
„aber jeder Kunde der keine eigene IT-Entwicklungsabteilung hat,“ – ich meine natürlich „jeder Händler“ ;-)
Eine Antwort auf diese Frage versuchte ich übrigens unter http://blog.mayflower.de/4781-Disruption-das-Neue-Normal.html zu geben:
„From a competitive standpoint, a company must be able to create software, deliver it and continue innovating on it. And this innovation must occur frequently and rapidly.
In fact, software must become a core competency for enterprises.“
Jedes (Shop-)System, das dies unterstützt und im Positiven darauf einzahlt, gewinnt.
Wo Du oben CommerceTools erwähnt hast. Die sind ziemlich weit in der Richtung „weg vom Monoliten“. Ich bin der festen Überzeugung, dass (zumindest erst mal im Bereich B2C) Standard-Systeme überholt sind, zumindest, wenn man vorn mitspielen will. Frameworks und APIs, die es erlauben, schell und günstig das optimale Individualsystem zu bauen, werden der „Standard“ werden. Sein Geschäft an die Release-Zyklen eines Software-Herstellers zu binden, wird immer mehr aus der Mode kommen.
PS: Den großen Unternehmen – die meist kein Oxid einsetzen / oder nur einmal in ihrem Leben / oder nur rudimentär (für den Rest wird dann ein CMS eingesetzt, weil Oxid fast nix kann …) – ziehen es vor planen zu können und zwar auch Update Releases. So ist das im Enterprise Bereich, dass das unter Umständen nicht mit dem Open Source und Community Gedanken vereinbar, natürlich. Aber es ist auch nicht der Anspruch des Unternehmens Magento, es allen – vor allem denjenigen, die keine Lizenzgebühren berappen und das Unternehmen und damit auch die CE finanzieren, glücklich zu machen. Das ist bei anderen Plattformen genauso, wenn sie in der Lage wären eine Marktdruchdringung zu erreichen, die den Fokus auf Enterprise Projekte erlaubt. Wer etwas anderes vermutet, der ist entweder sehr naiv oder die Geschäftsführer des jeweiligen Shopherstellers handeln wider jeglicher ökonomischer Vernunft, und vom Gelde ist nunmal jeder Softwarehersteller abhängig.
Auch wenn ich deiner Argumentationslogik nicht ganz folgen kann, so finde ich wirfst du hier einen interessanten Punkt auf: nämlich den des Geschäftsmodells eines Commercial Open Source (Shop-)Herstellers und die Umsetzung bei den genannten Systemen Magento, OXID und Shopware
Wer als Großunternehmen im B2C noch so denkt, wird über kurz oder lang verlieren. Wenn ich neue Ideen nicht innerhalb von 2 Monaten an den Markt bekomme, macht sie jemand anderes.
Ich weiß, große Enterprises ticken genauso wie Du sagst, die Cheffes ganz oben wissen aber, daß das ein Auslaufmodell ist. Deswegen gibt es Collins & Co. Nimmt Collins Magento? Eher nicht. Rocket Internet? Nein. Project A? Auch nicht. Das sind aber die, die ganz vorn dabei sind.
Was nehmen die denn? Rocket / Project A?
http://excitingcommerce.de/2012/08/23/yves-zed-project-a-ventures/
Du sagst es, Claus.
Es kann auch eine andere Strategie sinnvoll sein: zunächst mit einem Out-of-the-Box System schnell den Shop zusammenklöppeln, um das Geschäftsmodell zu testen. Um dann, im Scale-Out, wenn das Geschäftsmodell funktioniert, eine andere Weiche zB in Richtung Individual zu stellen – siehe Zalando, waren zuerst auf Magento unterwegs.
Wenn es jetzt also ein Shop-System gibt, das diesen Out-of-the-Box Modus automatisch unterstützt, dann brauchst du nachher auch nix mehr wegwerfen (im PHP-Welt-Sprech: Komponenten als Symfony2 Bundles, das System nennt sich „XYZ Shop“ und ist eine Zusammenstellung dieser verschiedenen Komponenten, die ich aber im „Super-Spezielles-Geschäftsmodell“-Case auch einzeln nutzen könnte).
Es ist doch völlig irrelevant, ob Magento so oder So. Solange Systeme am Markt sind gibt es genug zutun für uns.
Meine persönliche Meinung ist, das es Magento sehr weit nachvorne bringen wird, da der Fokus jetzt nicht mehr auf irgendwelchen Funktionen liegt, die irgendwelche OpenSource Fuzzies denken zu brauchen, sondern auf Marketing, Abverkauf und Payment. Das sind die wichtigsten Kriterien für erfolgreiches E-Commerce.