„Hey, wenn dich was an dem Projekt stört, dann reich doch Pull Requests ein!“ LOL, nein!

Jeder halbwegs gute Programmierer schaut sich, bevor er so manche Open-Source-Software nutzt, den Code kurz mal an. Also jetzt nicht extrem intensiv, aber man erkennt recht schnell die Code-Qualität. Ist die Qualität nicht gut, wird die Software nicht benutzt.

Erschwerend hinzu kommt, dass ich jemand bin, der anderen Leuten dann auch davon abrät, die Software zu verwenden. Die Leute fragen ja schließlich auch, was man von „irgendwas“ hält. Manchmal rennen sie aber auch einer Software hinterher und propagieren die Nutzung. Wenn ich dann schon weiß, dass die Software Müll, manchmal pflege ich das Wort „Jauchegrube“ zu verwenden, ist, rate ich den Leuten auch proaktiv von der Nutzung ab.

Gerade die Menschen, die aber die Idee und die Software von der Nutzung toll finden, lassen sich natürlich davon triggern.
Da kommen dann immer so lustige Argumente. Hier ein paar davon mit Erklärung:

• „Mach’s doch besser, wenn du so viel Ahnung hast!“ - LOL, eines der häufigsten Argumente, das man hört. Natürlich hätte ich gerne einen 96-Stunden-Tag, um alles, was schlecht ist, selbst neu zu bauen. Den haben wir aber nicht. Dein Stück Software bleibt aber schlecht!
• „Reich’ Pull Requests ein und korrigier es!“ - LOL, na klar. Irgendwie fehlt mir wie schon bei Punkt 1 die Zeit, aber natürlich hab’ ich noch ein paar Stunden mehr, um alles zu korrigieren und mir komplexe Unterstrukturen zu merken und um alle Konsequenzen der Änderungen durchzutesten.
  Um diese nämlich alle zu kennen, muss ich nicht nur grob drüberschauen, sondern im besten Fall die gesamte Code-Basis verstehen und kennen, hinzu kommen da dann auch noch die Frameworks in manchen Sprachen, die man sehr gut kennen muss.
• „Du machst immer nur alles madig“ - LOL, „alles“. Nö, ich mache nicht alles madig. Ich bewerte Code. Warum? Weil ich es kann. Klar, ich bin erst seit Kurzem in der Programmierung. 31 Jahre sind quasi nix, bin quasi noch Junior und denke, ich kann sowieso alles besser und in einer Nacht neu schreiben. Und ja, an dem Punkt war ich mal.
  Heute weiß ich, dass es mit einer Nacht nicht getan ist.
  Heute weiß ich, dass gute Software nicht komplex sein muss und dass gute Teile der Software klein sind. Da sind meist die anderen Programmierer noch nicht. Trotzdem bleibt ihre Software schlecht, aber ich kann sie nicht alle belehren.
• „Wie reagiert der Programmierer denn auf Verbesserungen?“ - Äääähm, bin ich dein Google? Schau doch selbst nach! Das hättest du in der Zeit, in der du die Frage gestellt hast, längst erledigen können.
• „Aber es ist doch beeindruckend, dass das Projekt existiert und was da bisher geschafft wurde!“ - Wenn jemand einen Kernreaktor in seiner Garage baut und dieser Kernreakor seine Umgebung negativ beeinflusst, gibt es immer Menschen, die sagen, dass das beeindruckend ist. Das ist wie bei AI: solange die Leute es nicht selbst verstehen, sind sie beeindruckt. Aber nichtsdestotrotz ist der Reaktor in der Garage keine gute Idee.
  Genauso ist das bei Software. Du findest das toll. Lern es zu verstehen, dann findest du es nicht mehr toll.
• „Aber es läuft doch!“ - Ja, siehe vorheriger Punkt. Der Kernreaktor funktioniert auch. Aber eher so semi. Bei Software hakt es dann meist in der Performance und der Skalierung. Es ist immer wieder dasselbe. Dann dürfen meist andere (aka Admins) dafür bluten, dass es jemand aus deiner Umgebung toll findet, diese Software unbedingt nutzen zu müssen.

Ehrlich Leute, ich arbeite in diesem Job und habe keine Zeit, eure Lieblingsprojekte zu verbessern. Diese Projekte bezahlen nicht meine Miete und ihr macht das auch nicht. Also nervt mich nicht mit euren Rosa-Brille-Argumenten zugunsten irgendeines Projekts.