Die Situation kennen sicherlich viele: Man steht vor einem Problem, welches zwar lösbar ist, jedoch zeitlich aufwendig. Da könnte doch ein kleines BASH-Skript, eine Erweiterung, oder gar ein Programm helfen - und schon sitzt man Stunden, vielleicht sogar Tage an einer technischen Lösung für eine Aufgabe, welche manuell längst erledigt wäre. Warum auch nicht - denn was einem viel Zeit gespart hätte, kann oft auch anderen helfen, und was einem wie eine Nischenlösung wirkt, kann vielleicht doch auch anderen einen Nutzen bringen. Ein Appell an die Wurzeln von freier Software.
Heutzutage entsteht Software meist auf kommerziellem Wege - ein Unternehmen sieht eine Marktlücke und entwickelt ein Programm, das aus dieser den meisten finanziellen Gewinn zieht. Durch Anwendungspakete, SaaS (Software as a Service) und sonstige Modelle aus der modernen IT entfernt sich diese immer weiter vom ursprünglichen Zweck - das Leben des Menschen zu erleichtern - hin zu rein ökonomischem Daseinszweck. Etwas abseits davon entsteht moderne Open-Source-Software - mal als unabhängiges Projekt aus der Gemeinschaft, mal als "Geste des guten Willens" von kommerziellen Giganten. Insbesondere im ersten Fall stecken noch die Grundzüge dessen drin, was ich als Ursprung der Software-Entwicklung in ihrer heutigen Form sehe - Lösungsorientiertheit, Zusammenarbeit, Gemeinschaft und ja, auch Spaß.
Je größer freie Softwareprojekte werden, desto mehr haben diese mit Problemen zu kämpfen. Immer mehr Nutzer finden mehr Bugs, wollen neue Features und am liebsten das Projekt in eine ganz andere Richtung lenken, während das Team oder gar ein Einzelentwickler immer mehr Zeit investieren muss. Und mit jedem neuen Feature Request steigt die Wahrscheinlichkeit, dass die persönlichen Ressourcen nicht reichen.
Hier kommt wieder ins Spiel, was ich am Anfang angesprochen habe - die kleinen Basteleien, die man hin und wieder für sich erstellt, die Nischenerweiterungen einer Software, welche seit Ewigkeiten nicht das eine gewünschte Feature erhält, die Programme, welche seit dem einen Zeitpunkt im 10. Unterordner auf der Festplatte verweilen. Einige veröffentlichen alles, was sie machen, andere jedoch verzichten komplett darauf - sei es wegen schlechter Codequalität, dem Zweifel an der Nützlichkeit oder ganz einfach, weil sie keine Gelegenheit dafür finden.
So ähnlich ging es eine lange Zeit lang mir - und zwar mit allen angeführten Begründungen. Irgendwann wagte ich einen Pull Request - es war ein kleiner, gerade erst entstandener Fork, und ich sah eine Chance, hier eventuell die Features, die mir fehlten, direkt zu ergänzen. Dann kam noch eins, und noch eins - je tiefer es mich in die Codebasis verschlug, desto mehr erkannte ich, dass auch bei größeren Projekten der Code keine Raketenwissenschaft ist. Rückmeldungen, Tipps, Hilfestellungen - all das veränderte meine Denkweise - ein Feature muss nicht perfekt sein, ein Skript nicht alle Fälle abdecken - es ist wichtig anzufangen und sich zu trauen, und etwas hinterher verbessern kann man immer. Schnell erkannte ich, dass mein Code besser wurde und sich jemand für die Ideen interessierte.
Was will ich mit diesem Erfahrungsbericht sagen? Macht mit, wenn ihr die Chance habt. Jedes BASH-Skript, jedes ach so kleine Feature, jedes Codeschnipsel, jedes Mini-Programm kann anderen Menschen helfen. Reicht Features bei größeren Projekten ein, wenn ihr euch schon an das Modifizieren macht. Was euch nach Nischenbedürfnis aussieht, kann das versteckte Highlight sein. Sprecht über Lösungen von Problemen, wenn ihr welche gefunden habt. Was ein mal auftritt, kann auch noch einmal auftreten, und was ein mal hilft, kann auch abermals helfen.
Das Grundideal hinter Open Source ist die Freiheit - die Freiheit zu nutzen, zu entscheiden, zu forschen. Was jedoch auch dahintersteckt ist die Freiheit ganz nach Pippi Langstrumpf - "Ich mach’ mir die Welt, wie sie mir gefällt." Doch vielleicht gefällt sie nicht nur mir? Und wie schon Linux Torvalds sagte, muss das nicht nur aus reinem Nutzen-Gedanken passieren - sondern vielleicht auch "Just for Fun".
Bildquelle: https://unsplash.com/de/fotos/DNkoNXQti3c
Sei es wegen schlechter Codequalität, dem Zweifel an der Nützlichkeit oder ganz einfach, weil sie keine Gelegenheit dafür finden - beschreibt sehr schön mein Dilemma. Ich habe mir eine kleine YAD-GUI in Bash gebaut, welche komprimierte Images von Datenträgern erstellt / zurückspielt. Ursprünglich hatte ich nur nach einem Oneliner mit dd und zstd gesucht, da ich es satt hatte, dass meine RPI-microSD-Backups immer 8 oder gar 16 GiB groß waren. Anschließend habe ich aus Spaß an der Freude ein Skript darum gebaut, welches am Ende fast 400 Zeilen (inkl. sehr vielen Kommentaren) lang war.
Ich habe eine Weile mit dem Gedanken gespielt, es zu veröffentlichen, mich dann aber aus so ziemlich den hier geschilderten Gründen dagegen entschieden. Ich gehe davon aus, dass es vergeichbare Tools bereits in deutlich besser gibt, ich habe diverse bash best practices nicht umgesetzt / ignoriert (die meisten davon kenne ich vermutlich nichtmal) und zu guter letzt habe ich keine Ahnung, wo / wie ich es veröffentlichen sollte. Ich habe keinerlei Erfahrung mit git und co. und keine Ahnung, welche Lizenz sich dazu am ehesten eignen würde.
Tldr; Für den wohl eher geringen Nutzen einer Veröffentlichung war mir der Aufwand zu hoch.
Den Ganken, mit den selbstgebauten bash Werkzeuge die Menschheit zur beglücken, habe ich auch immer wieder. Schnell öffnen sich dann Dimensionen, die in ein Lebenswerk münden. Interessant wäre ein Pool, wo das alles reingeworfen werden kann, und dann mit ML als quelle genutzt, aufbereitet und zur Verfügung gestellt werden kann. Hat sich ms bei der übernahme von github vermutlich in etwa so überlegt.
Ein weiterer Punkt wo es bei mir klemmt ist der Ort:
Ich würde vermutlich das Internet wählen... Danke für den Gedankenanstoss