Eine Frage zu individualisierten OXID-Paketen: Gibt es eine einfache Möglichkeit, die Abhängigkeiten einer Compilation in eine flache composer.json aufzudröseln? Aktuell mache ich das manuell, möchte das aber bestmöglich vermeiden. Im Grunde würde ich gerne eine Installation einfach updaten, ohne mir Bestandteile einzufangen die ich nicht benötige oder eben die jeweiligen Versionsstände der Abhängigkeiten manuell abgleichen zu müssen.
Ideal wäre ja eine Compilation “light”, also nur das Notwendige, auf das man dann individuell aufbauen kann.
Kennt hier vielleicht jemand einen besseren Weg oder habe ich entsprechende Docs nicht gefunden?
Würde z.B. beim CE-Metapackage bedeuten dass ich dass ich Paypal-Modul erhalte, die Polyfills für PHP welche ich nicht benötige, und einige andere Dinge von denen man sich nicht sicher sein kann ob das nun produktiv in allen Anwendungsfällen wirklich unbedingt sein muss.
Und um das zu vermeiden, fällt mir eben nix Besseres ein als die ganzen Metapackages per Hand aufzulösen. Was zwar überschaubar, hinsichtlich kommender Updates aber nicht wirklich effizient ist.
Jetzt wo ich die Frage stelle fällt mir zudem eine Neue ein wegen den geänderten Lizenzbedingungen: Ich habe irgendwo gelesen, dass die Nutzung dieser Module verpflichtend ist. Ich gehe mal hoffnungsvoll davon aus, es ist ok, wenn man sie effektiv nicht benötigt? Ansonsten hat sich meine Frage eh erledigt
Die neue Lizenz verbietet dir nicht, Module wegzulassen. Sie verbietet dir, Module nachzubauen und einzusetzen, die von einem Drittanbieter kommen, aber dieselben Services anbieten.
Also beispielsweise kannst du problemlos das PayPal-Modul von OXID aus dem metapackage ausschließen. Du darfst dann aber nicht stattdessen einfach ein PayPal-Modul von jemand anderem installieren oder selbst eins bauen.
Wenn du es genau wissen willst, schreib bitte einfach an [email protected] und lass es dir erklären
Es muss doch die freie Entscheidung eines Shopbetreibers sein - welches Zahlungs Module er einsetzt ? Es geht gerade bei Zahlarten um viel Geld, was man verlieren kann, wenn die Zahlart nicht ordnungsgemäß funktioniert.
Und gelinde gesagt ist Amazon pay und PayPal checkout im aktuellen Ist Zustand eine Umsatzgefahr - weil es an vielen Stellen zu Problemen kommt.
Ich kann mir schon denken, wieso ihr so eine exklusiv Nutzung durchsetzen wollt - ihr werden wahrscheinlich von PayPal am getätigten Umsatz über diese Schnittstelle beteiligt - das ist auch ok - wenn die Schnittstelle qualitativ gut wäre und ihr auch die Haftung übernimmt bei kaputten Updates- da beides nicht der Fall - solltet ihr das schon den Shopbetreibern selbst überlassen.
Was passiert beim Verstoß ? Dazu kann ich nichts finden.
Ihr entzieht mit diesem Schritt div. Agenturen und Programmierern die finanzielle Grundlage - und ihr habt in Vergangenheit gerade wegen dieser Leute Lizenzen verkauft und neue Kunden gewonnen.
Das ihr euren Partner und langjährigen Community Mitgliedern so den Dolch in den Rücken rammt - ist ein starkes Stück - ich hoffe die Entscheidungsträger kommen noch zur Besinnung und realisieren was sie da gerade angerichtet haben und versuchen ihren in meinen Augen größten Fehler, den OXID je begangen hat wieder , gut zu machen, bevor das Vertrauen ganz verspielt ist.
Es können weiterhin Erweiterungen / Module basierend auf OXID Code entwickelt und genutzt werden, ohne von den neuen Nutzungsbedingungen betroffen zu sein.
Ausnahme ist dabei die Implementierung / Nutzung von Erweiterungen oder Features, welche das direkte Feature-Set von höherwertigen OXID Editionen, bzw. Erweiterungen aus dem OXID Portfolio nachimplementieren. Sollte dies der Fall sein, müssen diese nachlizensiert werden. Dazu meldet man sich direkt bei [sales(at)oxid-esales.com]
Und jetzt nochmal meine ganz persönliche Meinung hierzu:
Wir reden hier von der CE. Sprich wenn Agenturen und Programmierer hier Software verkauft und vertrieben haben, die unsere Verträge mit den Zahlungsanbietern umgehen, dann haben DIE UNS die finanzielle Grundlage entzogen und sorry: Die tun mir dann gar nicht so sonderlich leid. Außerdem haben die dann eben KEINE Lizenzen dazu verkauft. (Die CE war ja schließlich bisher kostenlos.)
Das ist aber nur meine ganz persönliche Meinung.und repräsentiert nicht zwangsläufig die OXID eSales AG.
Wenn die Zahlungsmodule einwandfrei funktioniert hätten, hätte man keinen Grund gehabt, ein anderes zu nehmen. PayPal ist das beste Beispiel, sieht man sich die Bewertungen an.
Und mit dem Abgang von Marco stand vor über einem Jahr fest, dass Open Source ausgedient hat. Die neuen Quartalszahlen werden zeigen, wo die Reise hingeht.
Glaube damit ist was Anderes gemeint. Die Frage nach Verstoß war aus meiner Sicht gemeint wie OXID eSales Verstößte kontrolliert, weil der Normalfall wird sein das sich Händler*innen nicht beim Vertrieb melden.
Dies kann vielerlei Gründe haben z.B. das Sie die CE-Lizenzänderung nicht mitbekommen oder es aussitzen bis OXID eSales auf Sie zukommt und drauf aufmerksam macht.
Dies sind interne Verträge mit vorinstallierten Modulen. Den genauen Inhalt kennt nur OXID eSales und die Zahlungsanbieter.
Das Kernproblem sehe ich mehr darin, dass seit 2015 immer mehr Marktanteile verloren gegangen. Dies für alle Parteien schlecht für Agenturen und Programmierer + OXID eSales etc.
Von der Kommunikation her hätte man die Sache auch anders angehen können, indem man Fremdmodule die gut verbereitet und gern genutzt werden direkt ansprechen hätte können.
Aktuell ist dies mehr stille Post Prinzip. Vor einem Jahr hat OXID eSales noch damit geworben, dass man über Partner-Agenturen und Programmierer mit Händler*innen kommunizieren möchte. Jetzt hat man es komplett gedreht und möchte wegen der Nutzungsgebühr direkt mit den Händler * innen kommunizieren. Dies verunsichert alle Beteiligten OXID eSales, Händler * innen und Agenturen & Programmierer.
Immateriell hat sich OXID eSales mit diesem Zick-Zack-Kurs stark selbst geschadet, weil die Einführung einer CE Nutzungsgebühr über Nacht die Reputation starkt gegenüber Händler*innen verschlechtert. Gerade im B2B ist Vertrauen eine wertvolle Währung.
Alleine die Aussage, dass sich durch die Einführung der Nutzungsgebühr die Qualität der Module verbessern soll darf bezweifelt werden. Da sei die Frage erlaubt warum dies vorher dann nicht möglich war?
Für das OXID Framework macht Ihr einen guten Job, indem Ihr es pflegt. Der zeitliche Verzug bei der Pflege des Framework aber schon eklatant.
Der Startpunkt ist kostenlos bei der Lizenzfrage. Aber mit der Entscheidung für eine CE entstehen Kosten für Installation, Einrichtung, Individualisierung und Betrieb.
Der kostenlose Startpunkt hat die Entscheidung pro OXID eShop einfacher gemacht. Jetzt braucht es starke Argumente um Neukunden zu überzeugen.
Die Frage ist dort erlaubt, warum weiß OXID eSales so wenig über seine CE Händler*innen?
Warum hat man es nicht geschafft aus der Nutzung der CE Profit zu schlagen, indem man kostenpflichtigen Mehrwert generiert?
Die Händler*in ist an der für sich besten Lösung interessiert. Dabei spielt es keine Rolle ob das Modul von OXID eSales oder einem Fremdanbieter kommt.
Aktuell wird die Lage für Customizing Software nicht besser, weil die allgemeine wirtschaftliche Situation mehr Standard Softwarelösungen befeuert.
OXID eShop Community Edition und Co fallen aus meiner Sicht unter Customizing Software.
Sven, die Modulhersteller kennen eure Verträge doch gar nicht. Und glaubst du dass es zukünftig mehr CE-Nutzer geben wird, die eure Module nutzen? Die Änderungen haben doch eher den gegenteiligen Effekt.
