Kategorien
Socken und Open-Source
Am Mittwoch hat sich ja jemand beschwert, dass ich zu viel über mein Privatleben schreiben würde (so zumindest meine Interpretation). Da ich ja alle Wünsche immer befolge, will ich heute ein wenig über Socken reden, ganz wichtig: NICHT meine Socken. Die meisten tragen ja schwarze. Denkpause.
Nein mal ehrlich, ich will meinen Stil nicht ändern, weil es mir leichtfällt so zu schreiben und aus dem Grund mache ich auch so weiter. Außerdem ist es mein Blog und meine Arbeit, die ich mir mache und damit wird es auch immer mein Stil bleiben.
So jetzt wieder zum Informatikeralltag. Ich habe mich heute mal gefragt, warum es so wenig kleine und gute Open-Source-Tools gibt. Nehmen wir zum Beispiel LiveTest, das Tool hatte ich ja erfunden und dann zusammen mit Mike umgesetzt. Nehmen wir mal an, das Tools als ganzes wäre kein Open-Source, dann könnte man sich trotzdem mal die einzelnen Bestandteile anschauen. LiveTest war zwar das Hauptprojekt, da wir aber versucht haben in Komponenten zu denken und auch Separation of Concerns sehr groß geschrieben war bei den zwei Entwicklern, konnte man da noch zwei weitere offene Projekte draus zaubern.
Zum einen war da ein wunderbarer Event-Dispatcher, den man sich übrigens mal anschauen sollte, zum anderen hab dich die Named-Parameter-Komponente auch noch rausgezogen. Beide findet man übrigens auf GitHub. Beide Bestandteile haben eigentlich nichts mit LiveTest zu tun und wenn es ein Closed-Source-Projekt gewesen wäre, so wäre es trotzdem möglich gewesen diese zu veröffentlichen, ohne den Projekterfolg von LiveTest damit zu gefährden.
Jetzt wundere ich mich, warum nicht mehr Projekte ihre nicht business-relevante Komponenten veröffentlichen. Liegt es daran, dass der Code zu schlecht ist? Haben die Leute Angst, dass Ideen geklaut werden? Oder hat man sich vielleicht noch nie darüber Gedanken gemacht und dieser Artikel war jetzt ein Augenöffner? Ja ich weiß, so motivierend im Schakka-Sinn war es nicht, trotzdem. Vielleicht wissen die Leute auch gar nicht, wie man Separation of Concerns überhaupt sauber umsetzt, wobei man da ja hier weiterhelfen könnte, wenn man mal eine Reihe über Clean-Code macht. Naja viele Vermutungen, aber eigentlich wollte ich euch mal fragen, warum ihr keine Sub-Projekte veröffentlicht?
Passend dazu wäre als Hörempfehlung „Pentacast #4“ http://www.c3d2.de/news/pentacast-4-oss.html – hier wird ebenfalls erwähnt, mehr Code zu publizieren. Und gerade sogar auch dann, wenn man glaubt, der Code sei schlecht geschrieben, unsauber, was-auch-immer. Es gibt vielleicht immer mal jemanden, der genau das braucht und dann unter anderem auch eine Refaktorierung vornimmt.
Übrigens: es gibt schon die eine oder andere Firma, die Komponenten/Teilanwendungen/Tools veröffentlichen, die sie selbst nutzen, aber eben nicht zum Business gehören. Also so schlimm sehe ich die Angelegenheit nicht. (Aber vielleicht ist das ja wieder etwas eher PHP-Typisches. :D)
Die Frage habe ich mir auch schon gestellt. Und bisher war es immer so, dass die Entwickler den Code gerne rausgegeben hätten. Businessrelevante Teile auszuklammern sollte ja kein Problem sein und wenn doch schreit es vielleicht nach Refactoring. Aber der Entwickler ist nunmal nicht derjenige, der entscheiden kann ob und welcher Code bei github (oder etwas anderes) eingestellt werden darf.
Hier kommt dann immer das Managment ins Spiel. Hier kenne ich bisher 2 Typen. Die einen sind leicht paranoid und haben Angst die Konkurrenz könnte aus dem Code Vorteile ziehen. Und die Black-Box-Denker, die die gesamte Software als Blackbox sehen und da kann man ja nicht einfach eine Ecke rausbrechen.
Da man neben dem Alltagsgeschäft dann nicht die Motivation hat auch noch lange Diskussionrunden zu führen ob und wie, wer die Verantwortung hat etc. bleibt der Code einfach closed source und man spart sich Nerven und bekommt weniger graue Haare.
„Die Kritik ist eine Steuer, die der Neid dem Talent auferlegt.“
Zum Thema:
Ich denke jeder kennt die Zwänge in der Softwareentwicklung zwischen Qualität, Kosten, Dauer und Entwicklungsproduktivität. Harry Sneed hat das Problem sehr treffend mit seinem Teufelsquadrat visualisiert.
Jeder Entwickler weiss in kommerziellen Projekten, dass es mit mehr Aufwand und Zeit eine bessere, schönere, coolere Lösung gegeben hätte. Und genauso ungern wie jemand mit einem fleckigen Hemd auf die Straße geht, so veröffentlicht jemand Dinge die ein Ergebniss von Zwängen und Kompromissen darstellt.
Nicht kommerzielle Projekte tun sich naturgemäß mit solchen Zwängen einfacher und wo Idealismus regiert, gelten andere Gesetze.
Die Vorteile von Open-Source sind Entscheidern dann auch selten bekannt, so stößt man dort oft auf Vorbehalte.
Außerdem öffnet es natürlich eine weitere Dimension in der Softwareentwicklung, es macht die Sache sicher nicht unkomplizierter (Stichwort: was darf ich in existierenden OpenSource Komponenten öffentlich ändern und was intern?).
Aus meiner Sicht schon einige Hürden und Con’s auf dem Zettel, ohne bestreiten zu wollen, dass es Pro’s gibt die in vielen Projekten vermutlich überwiegen würden. Und ja, dein Vorschlag könnte Bedenken verringern, löst aber nicht das generelle Aktzeptanzproblem.
@Martin: Schön gesagt. Zu dem Contra-Teil hatte ich auch mal einen Artikel geschrieben: http://www.phphatesme.com/blog/webentwicklung/open-source-macht-das-leben-schwerer/