6.3 KiB
| title | date | draft | author | description | keywords | categories | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Better when open | 2019-01-05T22:00:00+02:00 | false | robert-kaussow | Open Source ist keine Einbahnstraße. Doch die Mitarbeit an Projekten gleicht manchmal einem Minenfeld wieder, welches gar nicht so leicht zu durchqueren ist. |
|
|
Eigentlich habe ich bisher Software nur genutzt und hin und wieder mal einen Fehler gemeldet. Ich muss mir aber eingestehen, dass ich so gut wie nie etwas dazu beigetragen habe. Nicht weil ich es nicht könnte und wenn ich ehrlich bin auch nicht, weil ich keine Zeit dazu habe. Ich denke es lag eher daran, dass es einfach bequemer ist zu nehmen, als zu geben. Aber das wollte ich ändern und begann mich tiefer mit der einen oder anderen Software zu beschäftigen. Ich versuchte die Zusammenhänge zu verstehen, um selbst ein paar kleinere Probleme zu lösen, anstatt immer nur stumpf um Hilfe zu schreien. Doch aller Anfang ist bekanntlich schwer und so fand ich mich schnell auf einem Minenfeld wieder, welches gar nicht so leicht zu durchqueren ist...
Wenn die Rede von Open Source ist denken die meisten von euch sicher in erster Linie an freie und offene Software, für mich gehört dazu eigentlich noch ein bisschen mehr. Ich bin kein besonders großer Freund von diesen typischen Nerd T-Shirts mit den üblichen blöden Admin-Sprüchen drauf die jedes noch so alte Klischee bedienen. Auf dem letzten Red Hat Summit bin ich aber an einem Shirt, mit einer wie ich finde schönen Botschaft, hängen geblieben: Better when open... und abgebildet waren in kleinen gezeichneten Piktogrammen all die Dinge die für mich die Grundpfeiler des Open Source Gedanken bilden. Nämlich nicht nur open code, sondern auch open minds, open doors oder open hearts.
Das Internet ist voll von kleinen und großen Open Source Projekten die fast alle ein wenig wie ein Staat funktionieren. Es gibt einen oder mehrere Oberhäupter, die entweder selbstbestimmt sind oder gewählt wurden. Diese müssen Änderungen absegnen bevor sie übernommen werden und sie legen auch die Spielregeln für die Mitarbeit an der freien Software fest. Fast immer gibt es Issue Templates, einen Code of Conduct, der definiert wie was gemacht wird, wie miteinander umgegangen wird und seit 2018 endlich auch politisch total korrekte Begriffe, die man benutzen soll um einen technischen Zusammenhang herzustellen. Wenn man Glück hat, ist das alles noch an ein CICD-System gekoppelt, welches alle Regeln gnadenlos prüft und jeden Fehler mit einem großen roten Kreuz hinter dem Commit abstraft.
So sieht die Entwicklung von Open Source heute aus. An dieser Stelle sei eines ganz klar gesagt. Ich finde es richtig und wichtig, dass es solche Strukturen gibt! Sie sorgen dafür, dass Verantwortlichkeiten geklärt sind und eine gewisse Qualität des Endproduktes sichergestellt werden kann. Doch was passiert, wenn jetzt ein Nutzer einen Fehler findet oder nach einem Feature fragt oder einfach gerne mitarbeiten möchte das aber noch nie gemacht hat? Nun, das kommt immer etwas auf das Projekt an, aber im Grunde gibt es erfahrungsgemäß drei Möglichkeiten:
- Die Anfrage wird freundlich entgegengenommen, eventuell werden ein paar fehlende Informationen eingefordert, ein Entwickler kann den Fehler reproduzieren und taktet den Fix für ein kommendes Release ein oder der Nutzer wird bei seinem ersten Pull Request unterstützt und ein wenig geführt.
- Man wird angeblafft, warum nicht alle Felder des Issue Templates ausgefüllt wurden, das man nicht beabsichtigt irgendwas in die Richtung zu tun und das man ja auch selber eine Pull Request erstellen kann, wenn man die Änderung jetzt unbedingt braucht. Eine Minute später ist der Issue dann bereits geschlossen.
- Man bekommt gar keine Reaktion und stellt fest, dass die letzte Aktivität in dem Repository drei Jahre her ist.
Fall 3 passiert mir persönlich recht selten, bereits bei der Evaluierung einer neuen Software wandert mein Blick mittlerweile zuerst auf die Commithistorie und den Issue Tracker. Hat sich da seit Jahren nichts mehr gerührt, ziehe ich in den meisten Fällen weiter.
Der zweite Fall ist mir leider schon öfter begegnet und widerspricht für mich den Grundlagen von Open Source. Oft wird in diesen Fällen damit argumentiert, dass es nur begrenzte Entwicklungsressourcen gibt und man Prioritäten setzen muss und nicht alles umgesetzt werden kann. Auch dem stimme ich grundlegend zu, man darf aber nicht vergessen das nicht jeder der Anwender auch ein Hacker oder Entwickler ist, der das Problem schon im Vorfeld durch debugged und analysiert hat und gleich mit einem fertigen Pull Request um die Ecke kommt. Viele Nutzer sind eben nur Nutzer, denen ein Fehler aufgefallen ist und die eventuell noch das Error-Log kopieren können. Selbst wenn man nicht der absolute Programmieranfänger ist und den Fehler auf eigene Faust beheben konnte und einen Pull Request erstellt hat, erntet man dafür nicht immer nette Worte. Manche werden kommentarlos abgelehnt oder erst gar nicht beachtet.
Letztendlich ist Open Source natürlich keine Einbahnstraße, man kann sich auch als Nutzer nicht immer mit
"Ich bin ja kein Entwickler"
herausreden, denn viele Projekte brauchen nicht nur Programmierer, sondern auch Leute die Dokumentationen schreiben, Artwork bereitstellen, Webauftritte betreuen und und und. So gut wie jeder kann in irgend einer Art und Weise mitarbeiten, wenn er das denn wirklich will. Auf der anderen Seite brauchen sich manche Projekte aber auch nicht über mangelnde Beteiligung beschweren, wenn jedem gleich an den Karren gefahren wird, der sich mal kritisch äußert oder vielleicht noch nicht so richtig weiß wie er was machen sollte, wenn er an dem Projekt mitarbeiten möchte. Ich denke das es beiden Seiten ab und an ganz guttun würde sich etwas verständnisvoller gegenüberzutreten und sich auf die Werte der Open Source Kultur zu besinnen.
Zum Abschluss noch ein schönes Zitat eines Github Users, an dem auch ich versuchen werde mich in Zukunft mehr zu orientieren:
"I really believe committing every day on an open source project is the best practice."