Kategorien
Open Source macht das Leben schwerer!
Dieses mal möchte ich einfach mit einer provokativem These in die Woche starten. Ich hoffe ihr seid mir nicht böse. Ich hatte vor kurzem eine Diskussion mit einem Kollegen, der Teile seiner Software immer als Open Source veröffentlicht. Ich hatte dann mal versucht mich aus Spaß auf die Closed-Source-Seite zu stellen. Ist mir auch in einem Punkt glaube ich ganz gut gelungen und das möchte ich heute mal kommunizieren in der Hoffnung, dass ihr eure Meinung preisgebt.
Um nochmal alles klarzustellen, ich bin ein sehr großer Fan von Open Source, bin aber auch Realist, manchmal zumindest. Also nehmen wir an, ich baue eine kleine Klasse, die wunderbar mit RSS Feeds hantieren kann und nehmen wir auch an, das gibt es noch nicht. Das Teil ist gut geworden und ich setze es in meinem Projekt ein. Ich will natürlich der Welt was zurückgeben und veröffentliche es als Open Source, jeder kann es kostenlos runterladen und verwenden. Was passiert jetzt im Normalfall. Ich stelle es live, es verwenden 10 Leute, oder vielleicht laden es sich 10 Leute runter und verwenden es dann doch nicht. Kann ja sein.
Macht doch nichts denkt man sich dann. Mein Problem ist dabei nur, sobald ich den Code öffentlich gemacht habe, habe ich meine Schnittstellen in Stein gemeiselt. Ich kann in meinem Projekt nicht mehr so einfach die Interfaces anfassen, denn da draußen gibt es Entwickler, die meinen Code verwenden und das auch noch nach dem Update meiner Version. Wenn ich damit breche, werden sie schnell wieder abspringen. Sobald ich also was öffentlich mache, muss ich die Abwärtskompatibilität einhalten und wahrscheinlich kostet das mehr, als es bringt. Vielleicht erweitern mir ja die Entwickler mein Tool um tolle Features, aber wenn ich die wirklich gebraucht hätte, wären sie dann nicht schon Teil meines Projektes?
Ich weiß, wenn jeder so denken würde, dann hätten wir ein paar wirklich tolle Projekte weniger auf der Welt und wenn ich ’ne gute Idee habe, dann würde ich die auch als OS veröffentlichen denke ich. Trotzdem finde ich den Gedanken diskussionswürdig. Das war jetzt übrigens euer Startschuss. Ich bin auf eure Meinung gespannt.
Ich bin überzeugt davon, dass dein Punkt ganz und gar nicht gegen Open Source spricht.
Erstens sagtest du selbst, dass du annimmst die Komponente sei gut. Damit sollte sie bereits grösstmögliche Stabilität erreicht haben.
Aber geschenkt. Der Haupt Fehler in deiner Argumentation ist, dass deine Schnittstellen durch das Open Sourcen in Stein gemeisselt seinen.
Das ist nicht richtig, sie sind durch die Benutzung durch andere Entwickler in Stein gemeisselt und das können auch Kollegen in einer Closed Source Welt sein.
Sobald die von dir definierten Schnittstellen an irgendeiner Stelle eingesetzt werden (und das ist doch ihr Sinn und Zweck) wird es schwieriger sie zu ändern.
Gegenüber fremden Entwicklern in der „Verantwortung“ zu stehen ist übrigens durch die meisten OS Lizenzen ausgeschlossen. Lediglich der Ruf deiner Komponente könnte leiden aber was soll’s? Nimmst du die Verantwortung aber wahr, dann zwingt sie dich, noch genauer hinzusehen, was du da entwickelst.
Selbst wenn du der alleinige Entwickler und Nutzer deiner Komponente wärest, würde dieser Effekt eintreten. Wir alle kennen das doch. Selbst wenn die Freiheit zur Änderung in diesem Fall sehr gross ist, heisst das mitnichten, dass auch sie auch einfach ist. Mit jedem Zugriff auf die Schnittstellen vergrössert sich der Aufwand sie zu ändern. Open Source, Closed Source, Eigenbedarf, egal.
Ich stimme Christian zu. Nur weil OS, ist nichts in Stein gemeisselt – für das gibts ja verschiedene Version. Zudem gibts ja auch die 10 User, die mit der neuen Version frisch einsteigen und nichts von früher wissen. Wichtig ist halt, dass nicht von einer Version zur anderen immer alles umgeschmissen wird und keine Richtung erkenntlich ist.
Vorteile und Nachteile… ja… hm…
Ich denke das kommt aufs Projekt an. Einerseits ist es schön für ein Team wenn es sich Accounts auf ner Page einkauft und nix installieren muss oder wegen nem SecurityLeak diese auf ihrem Server Upgraden. Andererseits liegen dann die Daten auf fremden Festplatten. Das ist jedoch nur eine von hunderten Arten von Software-erwerb, während es unter OpenSource meistens in den Lizenzarten nur um verschiedene Klauseln des veränderns / Dienstleistungsverkauf geht.
Man kann jetzt streiten ob und warum in verschiedenen Softwares, die wir jeden Tag nutzen, das richtige / falsche gewählt wurde. Macht das Sinn? Nein. Ich bin grundsätzlich gegen horrente Nutzungs-summen für Teams, wie sie bei den Atlassian Tools z.B. Anwendung finden. Und es lässt sich auf keinen Fall abstreiten, dass OpenSource Software wie PHP, SVN, Eclipse und Co. uns das Leben erleichtern.
Ich mache mir über solche Sachen gedanken wenn ich mit einem Stück Software fertig bin. Aber intressanter Gedankengang, Nils 😉
Ich denke auch, dass es unerheblich ist, wie ein Stück Software veröffentlicht wird.
Auch bei Closed-Source weiss ich oft nicht, wo sie eingesetzt wird. Entweder weil ich es vergessen habe oder weil es noch Kollegen gibt, die damit herum spielen. Closed-Source befreit ja nicht vom Grundgedanken, wie man Software entwickeln sollte.
Eine Änderung der Schnittstelle ist wie georg schon geschrieben hat, auch nicht wirklich schlimm. Es sollte nur nicht mit jeder Version geschehen und nicht wegen irrelevanten Kleinigkeiten- Solange Änderungen nachvollziehbar sind, sollte es kein großes Problem sein.
Was aber „für“ Closed-Source sprechen würde, ist in meinen Augen die Fülle an Software. Bei Closed-Software ist der Anbieter ja gezwungen, seine Features preis zu geben, wenn man Glück hat, gibts auch eine Anleitung an die Hand und man weiss was man kauft. Wie genau der Quellcode arbeitet entscheidet sich erst später und auch der Preis, ob die Software trotz Macken weiter im Einsatz bleibt.
Durch OS ist es aber schwerer geworden. Das Geld was man früher für Software ausgegeben hat, darf man heute gut und gerne in die Suche nach dem richtigen Projekt verwenden. Durch die Vielzahl an Angeboten, schlechte Dokumentation und Bewerbung ist es oft sehr schwierig zu erkennen, welches OS-Projekt das richtige sein wird. Da sehe ich noch am ehesten einen Ansatz zur Kritik.
Ich denke es ist ziemlich einfach. Du veröffentlichst was, die anderen sollen es Benutzen wie es ist und auch Änderungen in der Schnittstelle haben sie zu akzeptieren… Sie haben ja jederzeit die Möglichkeit sich selber einzubringen oder einen Fork zu ziehen (von dem du möglicherweise dann auch profitieren kannst).
Ist es nicht eigentlich ander herum? In dem Falle wäre Open Source besser weil du quasi eingreifen könntest wenn sich Schnittstellen geändert haben um Alternativen zu schaffen damit du deinen Programmcode nicht oder nur minimal ändern müsstest?
Was das Thema Abwärtskompabilität angeht ist es in meinen Augen eher die Einstellung des Teams hinter dem Produkt, nicht unbedingt ob Open Source oder nicht.
Bezüglich der verändernden Schnittstellen gibt es eine Richtlinie zur Versionsnummerierung, die deutlich signalisiert, dass sich die API noch verändern wird.
http://semver.org
Und wenn du die Software verkaufst, musst du doch auch eine Abwärtskompatibilität leisten, oder nicht? Wo ist denn der Unterschied zwischen Open Source und nicht Open Source Produkten, bezüglich der Abwärtskompatibilität? Das ist doch vollkommen unabhängig davon ob du es verkaufst oder nicht….
Ich denke, dein Denkfehler ist anzunehmen, dass es durchweg negativ ist, wenn deine Interfaces in Stein gemeißelt sind. Du weißt ja vorher, dass du deine Interfaces danach nicht anrühren kannst bzw. das zumindest mit mehr Aufwand verbunden ist. Daher machst du dir vorher mehr Gedanken darüber und gestaltest sie eleganter und flexibler als du es eventuell bei Closed Source getan hättest, denn „man weiß ja nie“. Und dann, eines Tages, tritt ein Fall ein wo du genau diese Flexibilität brauchst, und du hast sie zur Verfügung, ohne in den Code eingreifen zu müssen.
Open Source sorgt also dafür, dass du von vornherein besseren Code schreibst und dir in der Planung mehr Gedanken machst. Nicht zu vergessen: Wenn du nur einen Teil deines Projektes veröffentlichen willst, bist du gezwungen, diesen Teil mit so wenig Abhängigkeiten wie möglich zu gestalten.
Aus genau diesen Gründen denke ich mir mittlerweile oft „das ist zwar gut, aber so könnte ich es nicht getrennt veröffentlichen, daher muss ich es ändern“, obwohl meistens gar nicht mit dem Gedanken spiele, diesen Code zu veröffentlichen.
Also ich denke, da liegt ein ziemlicher Denkfehler vor.
Wenn ich Software als OSS veröffentliche, dann tue ich dies aus dem Grund, das ich etwas zurück geben möchte, oder ich will weiterkommen, mit dem Projekt. So habe ich einerseits die Verantwortung für den Quellcode und andererseits kann ich mich als Project-Leader an die Spitze der Entwicklung setzen.
Über API/Schnittstellen-Änderungen mache ich _grundsätzlich_ in den Changelogs aufmerksam! Das ist auch jeder, der OSS halbwegs professionell oder enthusiastisch einsetzt, gewöhnt. Außerdem kann ich die Änderungen jederzeit nachvollziehen, in dem ich mir die Sourcen anschaue. Das passiert ständig, in mehr oder minder kurzen Abständen, in den OSS-Projekten. Sei es beim Sprung vom Zend Framework von einer Major in die nächste Major Version, oder selbst beim Linux-Kernel.
Bei eingekaufter CSS kann man schon mal böse aufs Gesicht fallen, wenn die Änderungen _nicht_ausreichend dokumentiert sind. Da bin ich dann hundertprozentig auf das Funktionieren des Supports angewiesen. Und _das_ ist meiner Meinung nach auch einer der großen Vorteile von OSS, ich kann im Zweifelsfall eben selbst nachsehen.
Auch gekaufte Software steht vor dem gleichen Problem. Ich würde sogar sage, dass dieses Problem für solche Leute noch größer ist, da ja dabei Geld im Spiel ist. Vielleicht macht man sich bei kostenpflichtiger Software über solche Dinge mehr Gedanken und plant mehr für die Zukunft, aber ich denke, dass hat jetzt nichts direkt mit Open Source zu tun.
Wie lustig, Nils. Vor wenigen Tagen hatte ich denselben Gedanken.
Ich stimme dir da in sämtlichen Punkten zu, die Entscheidung etwas als OS zu releasen ist irgendwie eine Art von Gratwanderung. Klar mögen die Einwände, die hier geäußert wurden, wozu es denn Changelogs gibt, berechtigt sein. Doch: Man sieht des doch an PHP selbst.
PHP4 ist einfach nicht totzubekommen, weil sehr viele Programmierer von Opensource scheinbar Wert darauf legen, dass ihre Software abwärtskompatibel ist. Dabei bietet PHP5 mehr Leistung, mehr Funktionen, mehr Sicherheit, besseres OOP und damit auch bessere Wartbarkeit.
Auch wenns jetzt grad an reines OS vorbei geht: Ich finde das, was Rapidshare macht, ganz gut. Die Versionieren ihre API-Funktionen, stellen jeder Funktion ein „_v1“ oder „_v2“ hinten dran. Eine nette Sache, um eine Abwärtskompatibilität sicher zu stellen, ohne dabei auf bessere, überarbeitete Funktionen verzichten zu müsse. Ob sich ein ähnliches Konzept auch auf Opensource anwenden ließe?
So nach ’nem ganzen Tag Meetings mal wieder kurz Zeit mich zu äußern. Ich hatte gar nicht Open Source oder Closed Source veröffenlichen gemeint. War mein Fehler! Ich meinte Veröffentlichen oder nicht Veröffentlichen.
Ich bin aber immer noch der Meinung, dass je mehr Leute eine Software nutzen, umso schwieriger wird es die Schnittstellen zu ändern. Wenn ich es intern in 1-2 Projekte anfassen muss, isses egal. Wenn es mehrere Leute da draußen nutzen habe ich ein Problem. Ich glaube wenn ich das öfters mache, dass die Leute sich ziemlich schnell von meinem OS-Projekt abwenden.
Stichwort Versionspolitik. Und wer hindert Dich, „intern“ auf einem Branch weiterzuarbeiten? Ansonsten dürfte eine anständige Planung dafür sorgen, dass das nicht sooo schnell passiert.
Dann geht Deine Theorie m.E. etwas an der Praxis vorbei, denn SO früh wird man wohl kaum entscheiden, dass es ein Open Source-Produkt werden soll. Wenn es zu einem späteren Zeitpunkt geschieht, kannst Du vermutlich/wahrscheinlich selbst gar nicht mehr die „Wilde-Schnittstellen-Sau“ machen 😉
Insofern, wenn man was Kleines veröffentlichen will, um der Welt etwas zurückzugeben (find ich total klasse dieses Credo!), kann man das ja auch über den eigenen Blog machen, als Codebeispiel und damit halt Deine kleine Klasse veröffentlichen mit nem Hinweis, dass es sich vielleicht später mal ändert. Auf diese Weise hat es eher Kochbuchcharakter und verpflichtet Dich nicht gleich zur Schnittstellentreue. Und für den Konsumenten „fühlt“ es sich wahrscheinlich dann auch nicht so an.
Es hängt zum großen Teil einfach von der Zielgruppe ab. Wenn ich in einem Entwicklungsteam PHP5 erwarten kann ist es was anderes als die Software an einen Endbenutzer geht, der vielleicht höchstens das Hintergrundbild im CSS auswechseln kann und dem die PHP- oder MySQL-Version egal ist.
Versionierung ist eine feine Sache, solange keine Updates anstehen, die in allen Versionen angepasst werden müssen (Sicherheitsupdates, Anpassung an neue Umgebungen).