Open Source Code Patch Tool

[Unlikus]

Es ist vielleicht nicht zwangsläufig ein Widerspruch, aber wer opensource entwickelt hat eine bestimmte Einstellung, und diese sieht nicht vor, für schlechtere Software zu zahlen, die es in besser auch kostenlos gibt. Ich sehe keinen wirklichen Vorteil gegenüber Git, mit Github hat man sogar kostenlose Server und einen Clienten zu installieren (#apt-get install git) ist auch kein Nachteil. Aber lustig wars

[2manypeople]

Parasiten können auch verhungern

hallo Mermshaus,

vielen Dank für Deinen ausführlichen und für mich hochinteressanten Beitrag.

Meine Bemerkungen dazu:

Ich würde mich vom „Open Source“-Begriff lösen. Was du meinst, ist besser mit „unkompiliert“ beschrieben, denke ich, und bezeichnet konkret eben Software, die in PHP oder JavaScript oder so geschrieben ist. Um Lizenzen geht es dabei zum Beispiel eigentlich überhaupt nicht, an die denken aber wohl viele sofort.

Stimmt, es geht nicht in erster Linie um Lizenzen (das Thema hatte ich auch nicht aufgebracht) und es muss beides erfüllt sein, Offenlegung des Codes und unkompilierter Code.

Hier muss man erst überlegen, was jetzt ein OSC-Programm sein soll

Stimmt, gemeint war Open Source Code Programm

Als XML-Datei in einem von dir entwickelten Format, das nur deine proprietäre Software verarbeitet, nehme ich an. → Lock-in

Genau, die Code-Änderungen werden als XML-Datei vertrieben. Das lock-in-Problem beseht aber nicht, siehe weiter unten.

Ich weiß, dass so was manchmal schwer zu umgehen ist, aber eine schlechte Idee sind derlei Hacks in Third-Party-Software eigentlich immer von Beginn an.

Du versuchst da gewissermaßen eine schlechte Vorgehensweise zu kultivieren.

Denk einfach an die zahlreichen Plugins zu Programmen wie Joomla, Wordpress, etc. Eine nicht unbeträchtliche Zahl von Personen verdient damit Geld. Für diese Leute ist es sicher keine schlechte Idee.

diff- und patch-Tools sind da auch nicht völlig unfähig.

Stimmt, OSCPatcher geht aber einen Schritt weiter.

Na ja, aber auch nur theoretisch. Es ist reine Glückssache, ob ein Patch/Hack für die alte Version ohne weitere Anpassungen in die neue Version übernommen werden kann. Selbst wenn die n Zeilen vor einer Patch-Ergänzung unverändert sind, kann in der n+1-ten Zeile davor eine Änderung stehen, die die Ergänzung völlig wertlos macht. Das kann die bizarrsten Bugs verursachen, die du erst mal nicht mal mitbekommst, weil der Patch ja erfolgreich eingespielt wurde. Ich würde definitiv niemandem empfehlen, so was automatisiert durchzuführen.

Völlig richtig, ich habe aber nie behauptet, dass es eine Garantie gäbe, dass nach dem Upgrade noch alles funktioniert.
Diese Garantie kann es nicht geben, weil niemand voraussehen kann, wie eine fremde Software in Zukunft aussehen wird.
Es geht hier darum, Änderungen mit "minimal code changes" in die neuere Version zu retten.

Dann gibt es noch das Problem mit verschiedenen Patches, die überlappende Anpassungen durchführen. Das ist nicht automatisiert lösbar.

Natürlich gibt es Situationen, die nicht automatisiert lösbar sind.
Ich habe z.B. mit mehreren Patchen in derselben Source getestet. Im Allgemeinen geht das.
Schwieriger wird es, wenn innerhalb eines Patches nochmal gepatched wird. In den einfacheren Fällen muss man dann die Reihenfolge vorschreiben.
Vielleicht kann man auch kompliziertere Situationen konstruieren, die dann wahrscheinlich von keinem Patchtool befriedigend behandelt werden können.
Das macht weder starre Plugin-API`s noch OSCPatcher obsolet.

Auch will ein Patch vielleicht Sachen einführen, die etwas komplizierter sind. Datenbanktabellen, Dateien anlegen, … Dazu braucht es install- und uninstall-Hooks.

Völlig richtig. In dem Fall würde man eine Installationsanweisung erstellen, die z.B. so aussehen könnte:
1. Dateien entzippen
2. Dateien auf den Server hochladen (Dateien wurden mit Path gezipped)
3. Datenbank-Script ausführen.
Denkbar wäre auch, für 1.-3. ein Web-gestütztes Installations-Script zu schreiben.

Und im Grunde ist dein Überbau immer eine Krücke, die eigentlich nur dazu führt, dass entsprechender Code nicht in die Software selbst eingepflegt wird.

siehe dazu meinen Kommentar zu Joomla-Plugin-Entwicklung weiter oben

Das heißt sozusagen: Je mehr Code über deinen Überbau läuft, desto mehr Leute sind gezwungen, deine Software zu kaufen, und desto mehr Qualität und Wert wird aus der „Wirtssoftware“ selbst rausgezogen. Ist jetzt vielleicht ein wenig zynisch ausgedrückt, aber im Prinzip ist das etwas parasitär.

Ganz und gar nicht. Vielleicht habe ich das Konzept von OSCPatcher nicht deutlich genug dargestellt. Selbst wenn jemand, der Open Source Software vertreibt, 1.000.000 Kunden hat, braucht er dafür nur eine OSCPatcher-Lizenz. Die OSCPatcher-Software wird dann integraler Bestandteil seiner Software. Ich verdiene nur einmal daran. Der Verdacht (bei einigen Foristen hier zwischen den Zeilen zu lesen), dass ich dabei reich werden könnte, ist daher unbegründet.

Entscheidend scheint mir der Vergleich zu sein: starre Plugin-API wie bei Joomla, Wordpress oder OSCPatcher mit voller Flexibilität.

[2manypeople]

offen und unkompiliert

Open Source heißt auch in erster Linie Offenlegung des Quellcodes. Deine Anwendung hat da nur ganz enfernt mit zu schaffen.

Ich schließe mich da mermshaus voll und ganz an.

OSCPatcher ist ausschliesslich für Projekte mit offenem, unkompiliertem Code gedacht.

[tr0y]

Open Source in der Software Entwicklung meint heute in erster linie Lizenzrichtlinien der OSI. PHP ist nur sehr selten kompiliert. Weniger selten durch einen obfuscator geschützt.

[2manypeople]

nicht für jeden: OSCPatcher

Es ist vielleicht nicht zwangsläufig ein Widerspruch, aber wer opensource entwickelt hat eine bestimmte Einstellung, und diese sieht nicht vor, für schlechtere Software zu zahlen, die es in besser auch kostenlos gibt. Ich sehe keinen wirklichen Vorteil gegenüber Git, mit Github hat man sogar kostenlose Server und einen Clienten zu installieren (#apt-get install git) ist auch kein Nachteil. Aber lustig wars

Hi Unlikus,

danke für Deinen Beitrag.
ich weiss im Moment nicht, ob der Begriff opensource noch in anderem Sinn verwendet wird. Ich meine damit jedenfalls einfach nur offenliegenden Code.

Dazu können Personen durchaus verschiedene Einstellungen haben, zum Beispiel die, dass man ein Script verkauft, bei dem man den Usern die Möglichkeit geben will, es nach ihren Vorstellungen zu ändern und diese Änderungen vielleicht noch zusätzlich zu vermarkten.

OSCPatcher ist für eine bestimmte Marktnische gedacht. Dass es Leute wie Dich gibt, die ohne es auskommen, kann ich nicht komplett ausschliessen.


OSCPatcher.com

[ChristianK]

[...]
Denk einfach an die zahlreichen Plugins zu Programmen wie Joomla, Wordpress, etc. Eine nicht unbeträchtliche Zahl von Personen verdient damit Geld. Für diese Leute ist es sicher keine schlechte Idee.

Ich halte gerade Wordpress für einen schlechten Vergleich. Im Gegensatz zu Joomla hat Wordpress weder eine Plug-In-Schnittstelle noch irgendetwas vergleichbares. Wordpress ist Spaghetti-Code mit der Lizenz zum im Code herumwursteln. Da mag deine Software ihre Berechtigung haben - bei sauberer Software mit Plug-In-Schnitstellen ist ein solches "patchen" jedoch keine Anforderung.

[...] Natürlich gibt es Situationen, die nicht automatisiert lösbar sind.
Ich habe z.B. mit mehreren Patchen in derselben Source getestet. Im Allgemeinen geht das.
[...]

Ein Kriterium für mich wäre z.B. ob du die Patchs mit Unit-Tests überprüfen kannst. Nach dem Patchen müssen alle Tests erfüllt werden sonst wird der Patch abgelehnt (...).

Ganz und gar nicht. Vielleicht habe ich das Konzept von OSCPatcher nicht deutlich genug dargestellt. Selbst wenn jemand, der Open Source Software vertreibt, 1.000.000 Kunden hat, braucht er dafür nur eine OSCPatcher-Lizenz. Die OSCPatcher-Software wird dann integraler Bestandteil seiner Software. Ich verdiene nur einmal daran. Der Verdacht (bei einigen Foristen hier zwischen den Zeilen zu lesen), dass ich dabei reich werden könnte, ist daher unbegründet. [...]

Ich glaube, ob du damit reich wirst oder nicht interessiert hier niemanden. Der Kommentar dazu zielte darauf ab, dass du ebenen einen Lock-In hast. Wenn jemand eine Software aufbaut und dein System zum patchen (oder was auch immer) benötigt ist er an dich gebunden. Der Wert der originalen Software sinkt weil viel Logik/Source in deine Software ausgelagert wird. Anstelle die originale Software zu pflegen wird die "Pflege" als Reihe von Patchs mitgeliefert.

[tr0y]

Ich würde mal sagen es gibt kaum Leute die das ding wirklich brauchen, wenn an denen GIT nicht vollkommen vorbei gegangen ist.

[Unlikus]

Ich würde soweit gehen und sagen, es gibt niemanden und für Geld schon mal gar nicht.
Ich hab immernoch nicht verstanden, was denn der Vorteil gegenüber Git ist.
Und selbst wenn es welche gegen sollte, es gibt viele andere kostenlose Versionsverwaltungsprogramme, die deinem überlegen sein werden.

[2manypeople]

ChristianK,

bei sauberer Software mit Plug-In-Schnitstellen ist ein solches "patchen" jedoch keine Anforderung

Anforderung nicht, aber vielleicht eine Bereicherung.

Ein Kriterium für mich wäre z.B. ob du die Patchs mit Unit-Tests überprüfen kannst. Nach dem Patchen müssen alle Tests erfüllt werden sonst wird der Patch abgelehnt (...).

Mit Unittests gibt es keine Probleme. Der Plugin-Entwickler kann natürlich auch Tests mitliefern, die sich auf seine Änderungen beziehen. Diese laufen wahrscheinlich nur dann fehlerfrei, wenn die Patche aktiviert sind.
Aus meiner Sicht eine überschaubare Situation.

Wenn jemand eine Software aufbaut und dein System zum patchen (oder was auch immer) benötigt ist er an dich gebunden.

Ist er nicht, da er meine Software in sein System eingebunden hat und sie dann mehr oder weniger ihm gehört, hatte ich schon erwähnt.

Der Wert der originalen Software sinkt weil viel Logik/Source in deine Software ausgelagert wird. Anstelle die originale Software zu pflegen wird die "Pflege" als Reihe von Patchs mitgeliefert.

Erstens ist der Wert von Joomla nicht dadurch gesunken, dass Logik in (teilweise kostenpflichtige) Plugins ausgelagert wurde.
Zweitens: wenn OSCPatcher dazu verwendet wird, Bugfixes und kleinere Änderungen seitens des Herstellers der Basissoftware schnell an die Kunden zu bringen, das heisst also ohne eine neue Version der Basissoftware aufzulegen, dann schliesst dies nicht aus, dass es mittelfristig dann doch eine neue Version gibt, in der die alten Patche dann integriert sind.

[tr0y]

Der Patch, die Patches. http://www.duden.de/rechtschreibung/...tware_Programm

Ich krieg sonst heute das grinsen nicht mehr aus dem Gesicht.

[mermshaus]

*hust* „Versioneering“.

[Phpyton]

Wordpress ist Spaghetti-Code mit der Lizenz zum im Code herumwursteln.

*grins* Ich bekomm noch immer Brechreiz, wenn ich nur eine Datei davon sehe.

[tr0y]

<offtopic>

I <3 OctoberCMS. Wenn ich Wordpress ersetzen müsste und es ein Blog sein sollte und nodejs zur Verfügung stehen würde, würde ich wohl auf Ghost zurückgreifen.

</offtopic>

[litterauspirna]

Den Widerspruch sehe ich darin, dass versucht wird mit einem kommerziellen Produkt Open Source (also kostenfrei) zu unterstützen. Das ist als ob du die Solarkraftwerke mit Glühlampen unterstützen willst

Moin. Open Source heißt nicht automatisch kostenlos. Kostenlos wäre Free Ware. Open Source heißt nichts anderes als Quelloffen, kann deshalb trotzdem Geld kosten.

[ChristianK]

Ja, korrekt. Wobei die Open Source Initiative das so definiert:

Mit der Vervielfältigung und der Verbreitung von Open-Source-Software sind auch keine Zahlungsverpflichtungen gegen einen Lizenzgeber verbunden.