Gebt mal bitte Feedback, wie euch O3 selbst und vor allem die Idee dahinter gefällt. Worauf sollen wir achten? Was ist euch wichtig? Und ganz wichtig… inwiefern könnt und wollt ihr euch einbringen?
1 Like
Wir wollen mit unserer Integrationslösung für SAP Business One O3 ebenfalls unterstützen. Es wäre schön, wenn sich O3 künftig nicht zu weit von Oxid entfernt, damit wir keinen erheblichen Zusatzaufwand haben. Wenn sich das gewährleisten lässt, denken wir über eine neue Lösung für S4/Hana nach.
Die Idee an sich finde ich gut.
Den Cast der das umsetzt allerdings, mit Verlaub, ungewöhnlich.
Die eigentliche Frage ist zunächst welche Roadmap vorhanden ist. Lediglich ein altes System zu erhalten und weiterzuentwickeln kann sich in die gleiche, meiner Meinung nach falsche Richtung wie bei Oxid selbst bewegen. Ich meine explizit weniger die Lizenzfrage, eher was man wie technisch umsetzt und welche Vorstellungen es gibt ein modernes eCommerce Framework, und nichts anderes sollte ein Shopsystem heutzutage sein, umsetzt und entwickelt.
Meine persönliche Vorstellung wäre die Abschaffung von Frontend und Backend, ein api only System das mit einer möglichst breitbandig verwendbaren Menge an Schnittstellen daherkommt welche offen und transparent dokumentiert sind. Designentscheidungen für Frontend sollte die Verwender*in treffen, altertümliche Konstrukte wie Smarty oder Twig braucht kein Mensch. Ebenso kein Backend in dem man Kategrorien oder Produkte oder warenwirtschaftliche Daten pflegen muss, dazu gibt’s PIMs und ERPs die das viel besser können. Gleiches gilt für Kunden, sowas gehört natürlich in ein CRM System. Nimmt man diese Aspekte weg bleibt mehr Zeit sich auf das Wesentliche, ein zukunftsfähiges Framework innerhalb dessen Entwickler alles überschreiben und sich nicht nur an irgendwelche Events hängen dürfen. Ein System das funktional beliebig erweiterbar ist, das immer eine einfach zu bauende entsprechende Erweiterung für das headless API Konstrukt anbietet. Das Agenturtauglich ist, ohne sich darauf komplett zu konzentrieren.
Ich bin gespannt wo die Reise hingeht und wäre bereit ggfls. Code und Knowhow beizusteuern.
Es kommt doch darauf an wer die Zielgruppe des Shop ist.
Sollen die bisherigen CE Benutzer “aufgefangen” werden, die wohl meistens eher auf dem gleichen Level weiter arbeiten wollen, oder etwas komplett Neues und Anderes entstehen?
Kein FrontEnd / kein Backend bedeuet ja für den bisherigen CE Nutzer eine absolute Überforderung.
1 Like
Hey HaPe,
Danke Dir!
Was meinst Du mit: “Den Cast der das umsetzt allerdings, mit Verlaub, ungewöhnlich.”
Ziel dieser allerersten Version ist es, einen definierten Migrationspfad bereitzustellen.
(Sonst hätten wir ja gleich ein neues System bauen können)
Ich werde morgen/übermorgen mal zusammenschreiben, was ich mir für die Zukunft vorstellen/wünschen würde.
Ob das dann allerdings der “WayToGo” ist, das steht in den Sternen. Das hängt davon ab, was wir alle zusammen hier dann entscheiden, und davon, wer das dann umsetzt, sich einbringt.
“Ich bin gespannt wo die Reise hingeht und wäre bereit ggfls. Code und Knowhow beizusteuern”… Und ich erst 
Eric
Nunja, Mario Zanier und Eric Jankowsky in einem Boot ist für Leute die etwas länger in der Branche sind an sich schon ungewöhnlich.
Ich bin auch Einer von denen die mal ein Shopsystem auf osC Basis am Start hatten, und weiß das man früher durchaus mal als Konkurrent hätte gelten können. Alte Zeiten halt. Olle Kamellen.
Letzten Endes sehe ich es gegenwärtig so das wenn Systeme vom Markt verschwinden das seinen Grund hat. Was Oxid angeht sehe ich persönlich kein klares Konzept, dazu eine stark schwindende Basis was die Agenturseite anbelangt und auch was die Community angeht.
Dazu durchaus bedeutende personelle Abgänge, generelle Umstrukturierungen und ein für meine Begriffe nicht unbedingt überzeugendes zukunftsfähiges technologisches Konzept.
Ich glaube nicht das Oxid selbst CE Kunden vermisst, die wandern eh gerade aufgrund der Lizenz-, Preispolitik ab und auch ich empfehle, obwohl ich im OXID Umfeld arbeite, OXID bestenfalls in Ausnahmefällen.
Eine Alternative zu schaffen ist lobenswert, aber um damit tatsächlich jemanden zu erreichen genügt eine Fortführung des Systems was Anpassung auf aktuelle PHP/Symfony Versionen angeht wohl eher nicht. Also bleibt die Frage nach dem Konzept für die Zukunft wohl die entscheidende Frage.
Meine Vision wie ein modernes eCommerce Framework aussehen sollte habe ich ja bereits zum Besten gegeben.
Ich bleibe also gespannt welche Vision da morgen/übermorgen auf uns zukommt.
ich war über 10 Jahre im Oxid-Forum aktiv und habe den Niedergang der CE miterlebt. Damit der O3-Shop nicht das gleiche Schicksal erleided dürfen nicht die gleichen Fehler gemacht werden!
Aus Händlersicht war die Installation / das Update mit composer der Todesstoss für den Shop!.
1 Like
Hey Haho, Welcome!
Danke Dir. Sorry, wenn ich nachbohre. Was genau war an Composer schlecht?
Und eine Frage an die Entwickler: seht ihr das auch so? Ist Composer der Way to Go? Oder nicht, oder war es ggf nicht gut umgesetzt? Bitte bitte Feedback
Hey Kai
Ich ruf Dich an …oder Du mich
Schön, dass Du da bist!!
Technisch und als Entwickler ist der composer ein super Tool.
Die Shopbetreiber sind meist keine Entwickler. Und das soll(t)en sie auch nicht sein. Deren Job ist genau eins: Verkaufen. Und ihren Shop erfolgreich machen, gute Geschäfte haben und die Technik den Technikern überlassen.
Das heisst IMO: Die Technik muss soweit gekapselt sein, dass jemand, der mal einen Webshop ausprobieren will und kein Techniker ist das Ding trotzdem installieren können soll.
Was das jetzt für die Zukunft von O3 heisst, wird die Community hier entscheiden
1 Like
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.