Hallo Eric, Ralf hat es schon erklärt: Shopbetreiber sind keine Entwickler und dass die CE ab 6.2 nur mit composer installiert werden kann hat viele abgeschreckt. Hier muss für den O3-Shop eine praktikablere Lösung gefunden werden.
1 Like
Hallo,
@HaPe da hast du natürlich recht. Shopsysteme verschwinden nicht von selbst vom Markt und das bedient hier von der Architektur auch nicht mehr den aktuellen state of the art im enterprise Bereich, dennoch gibt es noch einige Tausend Händler welche mit der Lösung halbwegs zufrieden sind - und eine Lösung benötigen.
Den aktuellen core in eine composable commerce Richtung zu biegen ist aber eine grundsatzfrage und man ist vermutlich schneller mit einem rewrite - um hier eine Architektur Richtung commercetools oder andere frameworks wie elasticpath zu bekommen.
Würde ich eine neue ecom Platform entwickeln (das wäre jetzt glaub ich meine vierte nach xt:Commerce in den letzten 20 Jahren), wäre dies auch der einzig richtige weg, wobei sich hier auch die grundsatzfrage stellt - ob es überhaupt noch eine weitere composable Plattform benötigt, es gibt hier schon einige coole Lösungen am markt.
Ich bin der Meinung das es im SMB Bereich (vor allem in DACH) noch einige Jahre eine sichere, stabile und erweiterbare hybrid Lösung benötigt, auch für all jene Kunden welche sich nicht in ein 100k+ headless Projekt stürzen möchten und auch teilweise noch ohne Agentur starten.
Aus Agentursicht natürlich auch verständlich da man für ein headless projekt gleichmal um faktor x verrechnen kann, aber der normale SMB Kunde benötigt eine kostengünstige und wartungsarme Lösung zum Start, welche skaliert und im späteren Fall flexibel mit einer PWA und wachsenden Anforderungen mit PIM und OMS erweitert werden kann, ohne das System zu wechseln.
Nach meinem Exit habe ich beide Welten gut kennen gelernt. Die Anforderungen von 100tsd+ xt:Commerce Händlern über die Jahre davor, habe aber auch selbst als Kunde, Millionen in sap commerce cloud Projekten mit PWA und einigen composable Frameworks versenkt. 
@haho korrekt. Für eine Verbreitung und größere Akzeptant, und das ist das wichtigste für eine opensource/CE Version, müssen techn. Hürden abgebaut werden - und dazu gehört auch eine einfache Installation auf einem Standard-Hoster ohne Composer - indem man auch zusätzlich installationspakete für den normalen Upload zur Verfügung stellt.
Ich betreue seit ca. 20 Jahren OXID Shops und das Composer Argument habe ich eigentlich nie gehört.
Es ist die Frage was ein Shop Betreiber möchte. Möchte er verkaufen oder basteln oder Beides. Wenn ein Shop Betreiber selbst “alles können will” dann wird er auf einem niedrigen Umsatz Level stecken bleiben. Und dann wir er versuchen Geld zu sparen indem der er selbst mit dem Composer probiert. Möglicherweise wird er seine Produkte und die eigentlich wichtigen Daten im Shop nicht so gut pflegen.
Und ich denke da gerade an Shopware. Einem System was aus meiner Sicht elend überfrachtet ist. Es ist voll mit Modulen die so wirklich niemand benötigt. So ein richtiges “ich bastle mir einen Shop zusammen und werde hoffentlich damit erfolgreich”.
Für mich funktionioniert E-Commerce so nicht.
Aus meiner Sicht ist OXID aus Gründen in Trouble gekommen zu denen ich mich hier jetzt nicht groß äußern will. Es ist ja hier auch keine OXID Community. Wichtig ist aber dass hier die “richtige Politik” und ein gutes Miteinander vorhanden ist. Ich lasse mich ein Stück weit überraschen was hier passiert.
Ich glaube dass die Vorstellungen wie ein O3 Shop aussehen sollte extrem weit auseinander liegen. Deshalb sehe ich für die Idee nur eine “gute Zukunft” wenn klar wird wie die Richtung sein soll.
1 Like
PS: Ich habe heute Nacht vom O3 Shop geträumt, Scherz 
Nein, ich habe mir aber Gedanken gemacht:
Ist der O3 Shop ein “Rettungsanker” für alle bisherigen CE Kunden die ja sonst keine Updates mehr bekommen. Oder soll daraus etwas ganz Neues, also wirklich komplett Neues entstehen?
Ich denke wenn ich an “Neues” denke an einen reinen Symfony Shop, API-Plattform und was Symfony noch so hat, also mit relativ wenig “old OXID” Technologie. Und ich denke an AI.
Was sind eure Gedanken dazu?
Ich vermute bisher, dass die O3 Idee für viele wohl erst einmal ein “wie rette ich die CE-Shops” ist. Und vielleicht auch ein bisschen weniger oder mehr Frust, Trotz,… erlaubt mir diesen Comment.
Oh nein!! Du hast nicht wirklich von O3 geträumt, oder?
“Ist der O3 Shop ein “Rettungsanker” für alle bisherigen CE Kunden die ja sonst keine Updates mehr bekommen.”
Das ist einer der Gründe. Natürlich. Daher auch 1:1 in der V1, damit ein klarer Migrationspfad gegeben ist.
Natürlich wollen wir auch allen Kollegen aus dem Savy
Programm, welches ja auch von jetzt auf gleich und ohne Worte auf einmal weg war, bieten.
"Oder soll daraus etwas ganz Neues, also wirklich komplett Neues entstehen?’
Wir wissen doch alle, was wir hier vor uns haben. O3 ist ein Stück alte Software… aber es ist eine Software, mit mir einer der sichersten Transactionsengines überhaupt.
An der Stelle ein kurzer Ausflug Back to 2003. Federführend hat Lars damals ein Framework gebaut. Damit man ein bisschen zeigen kann, was man damit so machen kann, wurden dann halt ein paar eCom Funktionen dazu gebaut und diese mit einem wirklich hässlichen ungestyltem Frontend versehen… um Funktionen zu zeigen. … Uns beide hat es damals dermaßen gerissen als wir gesehen haben, dass Shops damit tatsächlich online gegangen sind, kannst Du Dir nicht vorstellen. Deshalb wurde dann Recht bald ein etwas schöneres Frontend mit ausgeliefert.
Als ich Anfang letztes Jahr, als es um die Unzer SS ging, mir mal wieder die aktuellste Version angeschaut habe, könnte ich das nicht glauben. Das war alles genau so, wie es 2011 war als ich dort weg bin. … Das Backend … zusammen mit meiner damaligen Frau, die damals noch visuelle Kommunikation studierte, sassen wir 2003 Abend für Abend zusammen und haben das gemacht. Und damals war das ja auch richtig gut… Aber doch nicht mehr in 2023… Unfassbar.
“Ich denke wenn ich an “Neues” denke an einen reinen Symfony Shop, API-Plattform und was Symfony noch so hat, also mit relativ wenig “old OXID” Technologie. Und ich denke an AI.”
Das haben wir damals zusammen mit Burda doch schon vor gefühlten Äonen schon bei Fressnapf gemacht. Alles symfony außer dem Checkout. … es gibt doch auch jetzt schon so tolle Frontends (oh Gott… wie schreibt man das?)… Makaira zum Beispiel, auch Moga werden wir uns jetzt nochmal ganz genau anschauen, das macht zumindest auf mich einen guten Eindruck. Aber auch andere Kollegen arbeiten gerade an sehr guten Frontends (schon wieder dieses Wort)
AI ist ein fettes Thema. Da habe ich schon so einiges im Kopf.
Die Frage aller Fragen, die sich immer wieder stellt.
Bei dieser wirklich alten Software, gibt es ein Ökosystem, das zwanzig Jahre gewachsen ist. Es gibt unfassbar viele Anbindungen. Schmeißt man das alles mit einer kompletten Neuentwicklung weg? Ist das eine gute Idee? (Siehe Intershop 4, was nach der Neuentwicklung der EnfinitySuite dann unter dem Namen epages rauskam) definitv keine Entscheidung, die leichtfertig getroffen werden sollte.
Das ist die Stelle, an der die Wünsche der Shopbetreiber und die Wünsche der Agenturen aber sowas von ausseinander gehen.
ABER, das eine ist der Kern, die Transaction Engine. Das andere, das ist das aussenrum.
In den nächsten Tagen gibt es mal eine Roadmap. Manche Dinge sind dermaßen klar, da gibt es wohl niemanden der was dagegen hätte. Bei anderen Dingen gibt’s dann auf jeden Fall Diskussionsbedarf
1 Like
Ich glaube dass es wichtig ist auf ein “neues” UpToDates System zu setzen.
Irgendwann muss man mal aufhören die alten, technisch nicht mehr tragbaren Sachen wegzulassen. Ich denke da z.B. an Symfony 3.4 im bisherigen OXID Shop, der jetzt ja wenigstens Symfony 5.4 nutzt. Alte Lasten mit sich rumzuschleppen birgt massive Nachteile.
Ich arbeite z.B. mit Symfony der aktuellsten Version und damit ein Backend zu erstellen bei dem auch CE Shop Betreibern mal so richtig das Herz aufgehen kann, kann ich mir sogar mit Symfony easyadmin sehr gut vorstellen.
Auch glaube ich dass es so schwer nicht sein sollte bisherige CE Shops in eine Symfony Datenstruktur zu migrieren.
Allerdings müssten dann ettliche Module migriert werden was zum Einen einiges an Arbeit sein kann, aber auf der anderen Seite ist die Umsetzung mit modernen Technologien ja einfacher.
Und dann könnte man endlich mal mit aktuellen Standards mitgehen. Ganz zu schweigen von den vielen Möglichkeiten die Symfony als Standard bietet und die für OXID erst programmiert werden müssten (Was sie aber meistens nicht werden).
Allerdings bin ich nicht der Meinung dass es ein 2. Shopware werden sollte. Lieber schlank, leicht und klar anpassbar…und leistungsfähig.
Meine DOIT Module z.B. setzen schon ein großes Stück weit auf Symfony bzw. es wäre mir lieber gewesen mich dabei nicht an OXID anpassen zu müssen. Die OXID Shop Technologie empfinde ich also in gewisser Weise als Blockade. Und das schon seit Jahren.
@Eric Was bezeichnest du denn als Transaction Machine. Ich verstehe nicht was du damit meinst. Meinst du kein OXID Admin, kein OXID Frontend, keine OXID Datenbank und nur “den Rest”? Was auch immer das dann noch ist
Hello, wenn Ihr mich fragt bräuchte O3 folgendes am nötigsten, um eine eigenständige Chance am Markt zu haben:
- Performante REST API, damit in Projekten Headless Frontends und bessere ERP Anbindungen möglich sind
- Neuer Admin, damit man das Ding Interessenten auch vorzeigen kann (am besten direkt Headless über die REST API)
- Eine eigene darauf aufbauende Modullandschaft
- Ein Geschäftsmodell, was all diese Entwicklungen finanziert.
Ihr könnt ja auch mal voten
Moin
Gebt mal bitte Feedback, wie euch O3 selbst und vor allem die Idee dahinter gefällt.
der Name O3 gefällt mir. Die Idee die letzte GPL Lizenz Version unter dieser weiter zu betreiben erscheint im ersten Moment positiv.
Leider wurde anscheinend bewusst vor dem Release der 6.5er Serie - mit dem wichtigen Update der veralteten Symfony Components - die Nutzungsgebühr für die Community Edition eingeführt.
Negativ daran ist, dass man nun die ganzen technischen Schulden für die Weiterführung mit sich rumschleppt.
Worauf sollen wir achten?
Wer sich mit Symfony beschäftigt merkt schnell, dass der OXID eShop nie etwas mit Symfony zu tun hatte außer sich die Symfony Components zu eigen zu machen.
Daher können aus meiner Sicht die ersten Schritte nur sein
-
Symfony Kernel endlich verwenden, dazu gab es seitens der OXID Community einen Anlauf zu sehen unter GitHub - OXIDprojects/oxid-symfony-kernel: Symfony Kernel für Oxid; Routen, Events, What ever; Module & Themes mit Symlinks installieren. welcher es bis Heute nicht in ein Release geschafft hat
-
Der Template Engine Umstieg von Smarty auf Twig muss endlich vollzogen werden, dort ist die kommerzielle Nutzungslizenz auf einem guten Weg. Dort fehlen die Twig Repos unter O3 Gitlab · GitLab leider komplett. Die letzte integrierte Smarty Version bildet bereits die nächste Sicherheitslücke…
Was ist euch wichtig?
Wichtigste Punkt wäre eine klare Kommunikationsstrategie mit der lebenslangen Garantie, dass es bei der GPL Lizenz bleibt.
Und ganz wichtig… inwiefern könnt und wollt ihr euch einbringen?
Die Schwierigkeit liegt darin, dass die Nutzerbasis von Händler * innen die einen OXID eShop einsetzen weiter abnehmen wird. Daher müsste es gelingen einen Turnaround zu schaffen neue Händler * innen zu begeistern.
Erst wenn ein Proof of Concept vorliegt und zeigt, dass neue Händler * innen O3 Shop Vertrauen entgegen bringen und einsetzen, dann macht ein einbringen erst Sinn - wenn es kein Hobby Projekt darstellen soll.
Dies kann ich leider nicht erkennen. Dies liegt aber vor allem an der starken, diversen Konkurrenz an Shopsystemen welche eine bessere Alternative darstellen anstatt auf eine OXID Framework Basis zu setzen.
Ich würde vermuten, dass es wie mir vielen Anderen auch geht: Welche erstmal die weiteren Entwicklungen von O3 gespannt abwarten. Aber im Grunde ist der Umstieg weg von OXID eShop im Hintergrund bereits im vollen Gange und aus meiner Sicht nicht mehr aufzuhalten.
Hey indianer3c
Danke Dir für dieses sehr konstruktive Feedback.
Eines vorweg: O3 ist und wird unter der GPL bleiben. Und im Gegensatz zum Ursprung oder z.B. der Shopware Community Edition, wird es kein kein kommerzielles Produkt daneben geben.
O3 ist und wird Community based sein.
Natürlich wartest Du erstmal ab. Logisch. So, wie sich viele viele andere, die sich hier im Forum schon registriert haben.
Wir sind gerade im Hintergrund am “werkeln”. Es kamen so viele auch uns zu, die gerne mitmachen möchten, die sich einbringen wollen, dass wir unbedingt vorab Die Strukturen und Verantwortlichkeiten definieren müssen.
Ansonsten wird das großes Chaos.
Parallel stimmen wir die Roadmap ab. Ich denke, sobald diese veröffentlicht ist, wird schon vieles klarer.
Liebe Grüsse
Eric
1 Like
Ich bin ein bisschen zwiegespalten. Die Frage, die ich mir stelle, ist in welche Richtung sollte O3 gehen? Entwickelt man den Monolith weiter und verbessert das „Shop Erlebnis“ und bedient somit die kleinen Händler die mit Anfangs kleinem Budget ohne WaWi oder PIM arbeiten, oder setzt man auf die neuen Technologien mit Headless, Composer und Co und baut alles individuell.
Meine Traumversion von O3 wäre, das UX im Shop-Backend stark zu verbessern. Optisch als auch funktional. Darunter gehört auch das Hinzufügen von Modulen und Patches ohne Composer. So einfach wie eine App in Windows oder iOS zu installieren. Um heute Module zu installieren, muss man mittlerweile ein Programmierer sein. Hier sollte man ansetzen und diesen Prozess wieder vereinfachen. Bei gewissen anderen Webanwendungen z.B. Shopware oder WP geht das auch.
Meines Erachtens sind da draußen immer noch sehr viele Händler, die eine Shopsoftware benötigen in der sie Ihre Produkte und Bestellungen ohne teure WaWi und PIM Systeme selber verwalten können.
Ich arbeite nun seit über 13 Jahre mit Kunden aus dem Mittelstand zusammen die aktuell eine CE Version im Einsatz haben und auch weiterhin verwenden würden. Wobei mich schon viele nach Shopware gefragt haben. Es sei da alles so „Schick und einfach“.
Allerdings haben diese Kunden alle eines gemeinsam. Die haben klein angefangen und sind mit der Zeit gewachsen. Anfangs mit „Standard Modulen“ und später kamen immer mehr Individuelle Wünsche hinzu bei der dann die Agenturen gefragt war.
Ich denke man sollte anfangs erstmal auf die kleinen Händler setzen. Zumindest so lange bis O3 eine gewisse Bekanntheit erreicht hat.
Das Grundziel ist und sollte aus meiner Sicht bleiben ein Monolith bereitzustellen um ehemaligen CE Nutzer * innen eine kostenlose Alternative bereit zu stellen.
Ein Monolith wird nie ein Themenbereich in der Tiefe abdecken können und es wird je nach Priorität des einzelnen Händler * in erforderlich machen sich seinen Online-Shop in den Themenbereichen erweitern zu lassen.
Der USP von O3 Shop könnte, wie bereits von den Machern im Hintergrund von O3 angedeutet, darin liegen die Community wieder mehr in den Mittelpunkt zu stellen und die Zusammenarbeit mehr zu fördern.
Die Philosophie kein kommerzielles Konkurrenz Produkt in Form einer höheren Lizenzform anzubieten kommt dem entgegen. So bietet O3 Shop Agenturen, Händler * innen und Programmierer * innen genügend Freiraum um kleine bis große Projekte damit umsetzen - eine gemeinsame Basis.
1 Like
Um den “kleinen” Händler mit geringerem Budget bedienen zu können, benötigt man den Monolith - ein Monolith schließt aber nicht grundsätzlich headless und co aus.
Auch muss man nicht jedes Shopprojekt mit einer PWA erschlagen, da muss man auch einmal die kirche im Dorf lassen.
Der Schlüssel für einen neuen Admin, PIM/ERP Anbindungen ist hier immer eine performante rest api welche absolut die höchste Priorität hat - damit kannst du einen Monolith auch 100% aus dem ERP/PIM/MDM verwalten, im täglichen Betrieb gibt es hier keinen Grund den Shop-Admin zu verwenden, bei vernünftiger Anbindung.
Um O3 im Grundsatz von einem Monolithen in eine wirklich moderne API First Plattform zu wandeln, gäbe es meiner Meinung nur einen weg, einen rewrite from Scratch.
Ich glaub, wir reden hier in unterschiedlicher Bedeutung von “Monolith”
Für mich ist ein Monolith eine Software, die im Inneren “aus einem Stück” besteht. Heisst konkret im O3-Shopumfeld (überzogen ausgedrückt): Um nur ein einziges Smiley im Browser auszugeben, muss man das gesamte Framework hochfahren. Mit dem entsprechenden Overhead und der Zeit, die das kostet.
Wenn man im Inneren sauber und geschickt modularisiert, in Komponenten teilt und die Komponenten geschickt miteinander kommunizieren lässt, kann man dasselbe Smiley ausgeben, indem man nur die Komponenten hochfährt, die dafür gebraucht werden.
Und das kann dann sackschnell werden - was sich auf die Time-To-First-Byte auswirkt und damit auf die Conversion Rate. Alleine dafür schon muss die Software schnell sein.
Gleichzeitig bin ich dafür, das Ganze “an einem Stück” auszuliefern. Der Auslieferungszustand hat nix mit der inneren Architektur zu tun.
Am Ende wird das, da geb ich @o3shop recht, auf einen kompletten Rewrite rauslaufen.
Und ich denke, dass es möglich ist das ganze Peu-à-Peu zu machen.
Hallo Eric,
gibt es mittlerweile eine Roadmap?
Liebe Grüße
Dayana
Für die Roadmap gibt es eigenen Thread unter https://community.o3-shop.com/t/update-2023-03-27-roadmap-und-bugtracker-online/ und die Roadmap findest Du unter Roadmap - MantisBT
1 Like
Hier ist ja (öffentlich ) seit Monaten nichts Neues zu sehen. Ist das Projekt jetzt gestorben oder wird nun nur im Stillen daran weitergearbeitet?
Servus taipan,
Da wird im stillen weitergearbeitet und demnächst gibt es auch Infos zu realeasestatus und der weiteren Strategie
Eric
Gefühlt, zusätzlicher Zirkus.
Mit “FTP” entpackst du das Archiv gleich wo du willst; öffnest das “Setup” und Gut ist.
Nun ist es gefühlt ein Mehraufwand und irgendwas klemmt mit Composer immer.
Es ging und geht auch ohne Composer. Das ist ein “Entwicklerspielzeug”.
Shopbetreiber haben oftmals keine Zeit oder Interesse.
Es ging und geht auch ohne Composer.
Es ging früher auch mal ohne elektrischen Strom.
Sorry, das ist aber ein Schmarren. Moderne Projekte setzen Composer ein.
Ob dieser für die Installation unbedingt sichtbar sein muss ist eine andere Frage. Wir haben keine Investoren im Rücken. Alles zu seiner Zeit.
Ich nehme mal deine Worte: Sorry, das ist aber ein Schmarren.
Nicht alles “Modernes” ist für uns ein Fortschritt.
Wir brauchen dabei nicht mal soweit nach hinten blicken.
Und bieten auch Archive an. Nicht nur um die alten Hasen nicht zu verschrecken.