Und wer sagt das SW nicht in ein paar Monate das auch so macht? ,-)
Denn SW und OXID sind nun mal die einzigen 2 Player am Markt für diese Zielgruppen.
Die Frage ist auch:
Wer bezahlt die Migrationen wenn man zu SW wechseln will, oder macht ihr das für 0€ ?
Würde das wirklich einen Sinn machen? Nicht zu vergessen Bestandskunden sollten auch nicht durch eine eine neue UI verunsichert werden.
PS: ich will hier damit aber nicht sagen dass ich das Vorgehen von OXID gutheiße!
Das ist schade - die neuen GraphQL-Möglichkeiten von OXID sahen gut aus. Ich hatte angefangen, einen OXID-connector für Next.js-commerce zu entwickeln (Link zu next.js Commerce: Next.js by Vercel - The React Framework). Ich bezweifle inzwischen, dass das Projekt sinnvoll ist: Es gibt andere sehr performante Webshops mit GraphQL-Anbindungen, performante E-Commerce- und DXP-Lösungen. Warum sollte ich OpenSource-Code für ein Projekt entwickeln, das nicht Opensource ist?
Allgemein frage ich mich, wie es mit dem OXID Forum weitergehen wird. Meine Erfahrung ist, dass das Forum wesentlich schneller und professioneller in der Vergangenheit weitergeholfen hat, als der OXID Support (“Senden Sie bitte meinem Kollegen einen Test-Case den er reproduzieren kann”). Das Know-How im Forum ist einzigartig und war immer ein großes Argument für OXID.
Gab es keine andere Möglichkeit, Geld zu generieren? Aggressivere Cloud-Politik? Erweiterter Support? Bessere Vermarktung der ERP-Module?
eher halbfertig. Generell, es gibt ja nicht mal mehr ein aktuelles Template, die BS5 Version kommt ja auch aus der Community.
Interessieren würden mich Deine Erfahrungen mit GraphQL im Zusammenspiel mit OXID?
Weil ich selber angefangen mit React + Gatsby erster Erfahrungen zu sammeln oder Apollo als GraphQL Client.
Eins der ersten Dinge worauf man stößt, ist das Thema CORS und halt SEO Geschichten bezüglich URLs mit React. Dann hat der Build Prozess bei React ein hohes Fehlerpotenzial, dass man als Entwickler häufig an kleineren Fehlermeldungen hängen bleibt die man beheben muss.
Mit dem Argument wird es für Fremdsoftware generell schwierig. Dem Anbieter muss man schon etwas Vertrauen entgegenbringen, auch wenn das in bestimmten Bereichen gerade mit Füßen getreten wird. Sonst strickt jeder bald seinen Shop selbst, mit allen Nachteilen.
Um den viel zitierten Vergleich mit dem Ladengeschäft zu bemühen: Wenn mich der Vermieter nicht mehr leiden mag, steht mir auch ein teurer Umzug bevor. Vielleicht muss man solche Momente auch einfach als Chance sehen und seinen Status Quo hinterfragen.
Interessieren würden mich Deine Erfahrungen mit GraphQL im Zusammenspiel mit OXID?
Weil ich selber angefangen mit React + Gatsby erster Erfahrungen zu sammeln oder Apollo als GraphQL Client.Eins der ersten Dinge worauf man stößt, ist das Thema CORS und halt SEO Geschichten bezüglich URLs mit React. Dann hat der Build Prozess bei React ein hohes Fehlerpotenzial, dass man als Entwickler häufig an kleineren Fehlermeldungen hängen bleibt die man beheben muss.
Das ist mein zweiter Versuch eine Oberfläche auf Basis von der OXID GraphQL API umzusetzen. Letztes Jahr war eine Umsetzung nicht möglich. Das ist nun anders: Die mir bekannten Fehler in der GraphQL-API sind behoben, die fehlenden APIs für das Frontend wurden ergänzt.
Einigen Sachen fehlen in der OXID-Welt: insbesondere ein sinnvolles CMS mit Versionierung und Workflow-Funktionalitäten. Virtual CMS ist allgemein dafür nicht geeignet. Ich verwende das Headless CMS System “directus” für die Erstellung von Landing-Pages.
Allgemein gefällt mir React für die Frontend-Entwicklung sehr gut. Die Lernkurve ist am Anfang steil (CORS 
). Kurse, die älter als zwei Jahre sind, sind veraltet. Die Entwicklung von Oberflächen ist mit React und Javascript wesentlich schneller. Es gibt viele gute Komponenten-Libraries. Die Benutzeroberflächen sind angenehmer zu benutzen, da z. B. nicht bei jedem Seitenwechsel die Seite neu geladen werden muss.
Wenn komplizierte und dynamische Benutzeroberflächen umgesetzt werden müssen, gibt es m. E. aktuell keine Alternativen zu React / Vue.Js: Der Entwicklungsaufwand mit jQuery ist einfach zu hoch.
Visual Studio Code hat eine geniale Unterstützung für React. Außerdem gibt es performante und kostengünstige Cloud-Systeme wie Vercel und Netlify. Auch diese vereinfachen die Entwicklung und das Deployen enorm. Das Deployen auf einem eigenen Server würde ich deshalb nicht mehr empfehlen.
Mit Gatsby habe ich bis jetzt keine Erfahrungen gemacht – hier bin ich gespannt, wie du es findest.
@Daniel_Beck vielen Dank für Deine Learnings. Ich habe ähnliche Erfahrungen, indem eigene GraphQL Module die OXID eShop erweitern machen können. Man kann gut mit den GraphQL Modulen arbeiten, wobei natürlich die neueren Versionen Schwachstellen/Probleme beheben.
Mit React und Gatsby sind meine Erfahrungen noch relativ frisch. Mir gefällt am React Ansatz gut, indem das Frontend mehr in den Vordergrund rückt. Anstatt sich auf Backend Funktionalitäten zu konzentrieren.
Gatsby selber habe ich mich mit beschäftigt um die SEO-URLs setzen zu können, damit Suchmaschinen die Seiten besser indexieren können.
Das mit den Ladezeiten bei einem Seitenwechsel ist gigantisch man merkt gar nicht das man eine neue Seite aufruft, wenn sich die Inhaltselemente nicht ändern würden.
Aber React hat auch Nachteile, es ist sehr komplex man muss weiter mehrere neue Techniken lernen… Das erhöht Wartungsaufwand und mit kleinen Fehler im JavaScript kann die ganze Seite lahm gelegt werden nach Build Prozess.
Zusätzlich funktioniert das native Browser-Caching von React Webseiten nicht mehr. Also man verzichtet auch wieder auf Vorteile die normale Web-Browser mitbringen. Ich fand dort folgendes Video interessant https://www.youtube.com/watch?v=S1wQ0WvJK64
Mein Bekannter nutzt OXID 642 und wird im Admin darauf hingewiesen, auf 6.5 hochzugehen. Wenn ich auf die Anleitungen gehe wird mir aber nirgendswo angezeigt, daß ich eine neue Lizenz bekomme.
Und die Infos zu 6-5 sind von 6-4 kopiert. OXID eShop 6.5.0 — OXID eShop 6.5 | Anwenderdokumentation
Seltsam, ich sehe in den besagten Release Notes eine große Infobox über die geänderten Lizenzbedingungen, direkt unter den Breaking Changes.
Vielleicht Cache leeren 
Das wars 
. Allerdings kommt der Hinweis nur in 6-5. So würde ich annehmen, daß bis zu dieser Version alles bleibt, wie es ist, oder?
Wie es aussieht sammelt der Vertrieb Detailfragen, daher kannst Deine Fragen nur direkt an den Vertrieb unter [email protected] stellen um eine verbindliche Antwort für Deinen Fall zu erhalten.
Meistens bekommt man anscheinend eine E-Mail Bestätigung auf seine Frage(n) als Bestätigung wie es scheint. Damit auch nachweisen kannst, dass in Deinem Fall es so ist wie es Dir gesagt wurden ist.
Das erspare ich mir, denn ich habe eben Kontakt zu einer Anwältin aufgenommen: Die Installation von OXID 6.4 beinhaltet immer noch die GPL und wenn mann den Shop installiert, muss man die Annahme dieser Lizemz bestätigen. Diese Lizenz kann nichts einfach durch Überschreiben geändert werden. Bei der nachträglichen Installation, egal von was, muss ein deutlicher Hinweis erscheinen, daß sich etwas ändert. Die Button-Lösung sollte ein Begriff sein. Ohne Bestätigung kein Deal.
Es dürften 1000e gleiche Fälle sein.
Dies ist aus meiner Sicht die Laiensicht wie die Software bezogen wird. Der Streitpunkt dürfte sein, ob es zulässig ist Rückwirkend ab einem Stichtag auch ältere Versionen die noch mit GPL gekennzeichnet sind unter die neue Lizenz fallen zu lassen.
Wenn dem so ist, wäre Deine Fragestellung beantwortet.
Im Prinzip sollte es zu einer gerichtlichen Auseinandersetzung kommen - dann entscheidet am Ende ein/e Richter*in nach Anhörung beider Parteien. Da ich die Aussage nicht in Stein gemeißelt sehen würde, sondern mehr Auslegungssache ist.
Dies würde ich in der B2C Welt so einordnen, aber nicht in B2B.
Ja, aber trotzdem wäre es mit geänderter Lizenz für beide Seiten OXID eSales und Händler*in zielführend dort in Kommunikation zu treten um dort wieder eine Planungssicherheit herzustellen.
Aus meiner Perspektive, wenn man langfristig plant durch die neue Nutzungsgebühr das System zu wechseln und man dies kurzfristig nicht von Heute auf Morgen umgesetzt bekommt.
Dann würde ich es als Übergangsfrist mit der Aussage Deiner Anwältin mit welcher Du gesprochen hattest es dabei belassen ohne Rücksprache mit dem Vertrieb Module zu installieren oder Änderungen vorzunehmen.
Dann sollte mittelfristig das Ziel sein bereits den Systemwechsel zu vollziehen in den nächsten Monaten.
Kein Customer, sondern Lizenznehmer. Da ist es egal, ob ich eine Firma habe oder nicht.
https://www.medienrecht-urheberrecht.de/it-recht/181-lg-muenchen-gpl-lizenz-wirksam.html
GPL hat eine Art Bestandsschutz und kann nicht einfach geändert werden. Hier wollte das doch jemand prüfen lassen.
Es ist sicher nicht alles verwertbar, aber
'##Es gilt: Einmal GPL, immer GPL!
Um in der Praxis nicht plötzlich (kostenpflichtigen und imageschädigenden) urheberrechtlichen Ansprüchen von Miturhebern Freier Software gegenüberzustehen, ist die eigene Vertriebskette an der GPL auszurichten. Es ist sicherzustellen, dass die bei der Weitergabe des Sourcecodes oder des Objektcodes teilweise unterschiedlichen Lizenzpflichten erfüllt werden.
Wurde ein GPL-Programm verändert oder ergänzt und soll nun die modifizierte Software weitergegeben werden, ist vor allem auf die Besonderheit der GPL-Lizenz gegenüber anderen OSS-Lizenzen zu achten.’
ist interessant.
Man kann nicht rückwirkend sagen, die GPL gilt jetzt nicht mehr, lösch bitte deine GPL-Version. Aber der Urheber ist auch nicht gezwungen, seine Software weiterhin unter GPL zu veröffentlichen. Also wenn man ein Update auf 6.5 macht, dann gilt m.E. auch die Lizenz von 6.5. Zwingt einen ja keiner das Update zu machen.
danke für den Tipp. Ich bin seid 2012 dabei und war von OXID begeistert. Mein größter Dank geht an diese Community, das war für mich stets was für OXID sprach. Es war toll … Danke.
Als Entwickler der alten Generation sehe ich das Thema so: Wenn ein Unternehmen jahrelang das Wissen und Experience tausender User als “open source” abgreift um das eigene Produkt voranzubringen und dann das Ergebnis kostenpflichtig wird, hat die kaufmännische Gier einmal mehr mit den Regeln des freien Internets gebrochen. Schade und aus Prinzip nicht vertretbar. Wir haben CE 6.4, werden aber wohl aus Prinzip wechseln, auch weil mit Paypal einer der wichtigsten Module ein Wackelkandidat ist.
Trotz allem bin ich vielen hier unglaublich dankbar.
Bleibt wie ihr seid.
Das kann sein. Aber das für mich und bestimmt ^1000 andere wichtige ist, daß mein Freund nichts zahlen muss, wenn eine zusatzsoftware, also ein Modul installiert wird. Das geht nicht und sollte hier geschrieben stehen.
Bis 64 braucht keiner Angst haben. s. Artikel. Wir warten auf Agrosoft.
Ein voreiliger “Verzweiflungsakt” nach folgender Geschäftsentwicklung und Führungswechseln:
https://www.northdata.de/OXID+eSales+AG,+Freiburg+i.+Breisgau/Amtsgericht+Freiburg+HRB+701648
Diskussion mit Hintergrundinfo:
https://www.kussin.de/development/oxid/oxid-esales-erfahrungen-strategische-neuausrichtung-oder-letzter-atemzug/