Open Source verstehen, leben

Die Zeiten ändern sich.

Dieser Beitrag scheint älter als 8 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet.

Aktuell konzentrieren sich viele Menschen in meinem Umfeld eher auf geschlossene Pakete, keine Transparenz und möglichst wenig Mitarbeiter. Weihnachten ? steht vor der Tür und genießt den „Sommer“.

Trotzdem mal wieder Raum und Zeit für einige Zeilen dich mich persönlich umtreiben. Open Source, egal ob nur die Sicht auf Code oder andere offene Quellen, die zu Produkten führen können. Ich möchte ein paar Gedankenanstöße los werden und vielleicht zum Nachdenken anregen.

Ich bin seit vielen Jahren im Zirkus unterwegs, lebe ihn aus unterschiedlichen Richtungen und bin ebenso Nutznießer aus verschiedenen Welten und mit verschiedenen Sichten. Diese Punkte bewegen mich dazu, die folgenden Worte nieder zu schreiben und diese Sicht, das Gefühl bzgl. Open Source zu haben.

Ich schreibe diese Zeilen mit dem Bild, dass Open Source und dessen Mitarbeit vorrangig in Freizeit entsteht. Ich weiß, dass es diverse Projekte gibt, die mit Hilfe von Arbeitszeit im Sinne „man wird entlohnt“ entstehen. Ein großes Bild der Themen, die ich ansprechen möchte, trifft aber eher auf die Ressource nach dem Job zu und ringt mir daher um so mehr das Lob, die Huldigung ab.

Natürlich musst du nicht die gleiche Sichtweise haben, sie schildert mein Bild. Ich will auch nicht diskutieren, ich möchte darstellen und anregen.

Warum Open Source?

Jeder für sich sollte sich diese Frage beantworten. Warum stellt man seine Idee und Lösung öffentlich bereit. Will man dies tatsächlich, soll es anderen nutzen und ist Mitarbeit gewollt. Sucht man nur freien Speicherplatz oder Sichtbarkeit. Will man neue Ideen, Diskussionen zulassen. Mit einem Open Source Projekt öffnet man seinen Geist zu diesem einzelnen Thema, Produkt und oft auch zu vielen anderen Themen. Parallel sind Fehler sichtbar, angreifbar. Auch dies sollte in dem Umfeld nicht vergessen werden. Gleiches gilt für das Einbringen von Änderungen, will man das? Hier muss jeder für sich die Regeln fest legen, sollte dies auch sichtbar dokumentieren um potenzielle Mitarbeiter nicht abzuschrecken.

Open Source Projekte sind mehr als das Abliefern von Code

Die Mitarbeit, das Einbringen in Open Source Projekten kann sehr verschieden sein. Oft wird in erster Linie auf Code runter gebrochen, aber die Arbeit an solchen Projekten erfordert weit mehr. Es ist ebenso Dokumentation, Community Arbeit, Übersetzungen, Sichtbarkeit, Projektmanagement und vieles mehr notwendig. Hier kann jeder seine favorisierte Aufgabe wieder finden. Entscheidend ist, dass es nachhaltig geschieht. Das pure Abgeben von einigen Zeilen Code oder einem Issue ist in der Regel kaum hilfreich. Das Projekt lebt und stirbt mit den Leuten, die daran arbeiten.

Recruiting

Als Projektinhaber gilt es daher möglichst stabile Mitstreiter zu haben, die sich engagieren, die sich einbringen. Parallel gilt es stetig neue Leute zu rekrutieren, zur Mitarbeit zu bewegen. Populäre Projekte im Web beispielsweise sind hier sehr stark. Sie dominieren nicht wegen ihrer Qualität an Code oder einer Führungspersönlichkeit. Die Community, die Mitstreiter machen sehr oft den Wert aus. Neue Bewerber sollten mit wenig Hürden in das Projekt gelassen werden. Eine schnelle Lernkurve um ein entsprechendes Niveau zu haben hilft sehr. Hindernisse auf jedem Wege der Beteiligung stoßen ab, schrecken neue Mitarbeiter ab.

Die Akzeptanz von Requests beispielsweise sollte nicht zu hohe Hürden enthalten. Lieber einmal mehr korrigieren, auf das gewünschte Level bringen und zurück mappen, was fehlt, was man besser machen kann. Nur so steigt die Lernkurve auf der anderen Seite und die Zufriedenheit, die zur Mitarbeit benötigt wird.

Balance

Gleichzeitig gilt es eine Balance der Mitarbeit zu finden, so dass Mitstreiter nicht verbrannt werden. Die Meinung, die Arbeit jedes einzelnen zählt, vor allem wenn sie in ihrer Form mit der Gruppe abgestimmt ist. Daher helfen Contributor-Regeln um hier schnell klare Linien zu erkennen. Parallel ist Kommunikation über die Issue-liste hinaus wichtig, Austausch auf menschlicher Ebene kann ein Projekt beflügeln. Wir haben heute eine ganze Reihe toller Tools um sich gut aus dem Wege zu gehen und trotzdem einen Austusch zu leben, trotzdem halte ich einen Austausch um das Problem und darüber hinaus für sehr hilfreich. Zufriedenheit kommt sicher aus verschiedenen Motivationen heraus, aber auf lange Sicht ist ein gutes Familienleben sicher sehr hilfreich.

Vergiss in diesem Zusammenhang die unterschiedlichen Altersstrukturen nicht. Während die einen mit dem Austausch per Tastatur aufgewachsen sind, brauchen die anderen mehr Worte zum korrekten „Sagen“ und nicht nur eine Emoticon. Die Welt ist bunt, ihrer Bewohner erst recht und das macht auch in einem Projekt die Mischung und dessen Wert aus. Ein breit aufgestelltes Projektteam kann sehr wertvoll sein.

Gleiches gilt für unterschiedliche Kenntnisse. Was dem einen als Selbstverständlichkeit im Alltag begegnet ist dem anderen neu. Antworten, Fragen sind einfacher wenn man sie versteht und man nicht nur it kurzen Worten abgefertigt wird. Ob Issue oder Pull Request, ein paar erläuternde Antworten machen es leichter. Ich wurde neulig bei einem Pull Request um ein interactives Rebasing gebeten. Die Hinweise, das Feedback kamen nicht vom Repo-Projekt-Inhaber, sondern von einem Außenstehenden, der sich lediglich für meinen Code interessiert hat. Zu Nachfragen erhielt ich immer sachliche Rückmeldungen und ein Mail-Austausch ist parallel entstanden. Ich habe neues gelernt und meine Arbeitsweise der „schmalen“ Commits muss weiter überdacht werden, oder wie hier im Nachgang überarbeitet werden. Es entsteht Mehrarbeit, die aber Wertvoll ist. Im ersten Schritt baute ich nur eine kleine Erweiterung, im zweiten entschloss ich mich zum Pull Request und nun waren die zu kurzen Commit-Messages nachteilig. Darum ist der Hinweis wertvoll. In diesem speziellen Fall wurde mir dies sogar abgenommen, in dem der Reviewende dies übernahm und positive Beispiele aufzeigte.
Ich denke, dass solche Beispiele aufzeigen, wie man miteinander umgehen kann, soll. Es hilft beiden Seiten und mein nächster Request ist sicher gepflegter und der interaktive Rebase ist nun auch erlernt. Parallel steht dem Repo-Inhaber nun ein Pull-Request an, der zu durchschauen ist und neue Mitstreiter sind gefunden, abgeholt.

Kurz: Der Mensch macht`s.

Sichtbarkeit, Feedback

Wie erreicht man es, dass Projekte sichtbar werden? Viele von uns haben offene Projekte, suchen hier und da Mitarbeit. Nicht alle erstellen Open Source aus dem Gedanken heraus freie Lösungen bereit zu stellen. Oft entstehen sie auch aus dem Beweggrund der Sichtbarkeit bzgl. Recruiting heraus, eventuell auch weil die freie sichtbare Lösung keine Kosten verursacht und die Vorteile eines Repositories im www mit sich bringt.
Andere wiederum hoffen auf mehr Sichtbarkeit und neue Mitarbeiter. Ich für meinen Teil habe einige offene Projekte laufen, jeder Pull Request ist wie ein innerliches Weihnachten. Die Freude darüber ist unglaublich. Ich bekomme Korrekturen, Erweiterungen – im besten Fall lerne ich etwas. Darum verstehe ich nicht, warum an anderer Stelle Request ewig liegen oder gar unangetastet bleiben. Um das Projekt ist es Schade und um den Menschen der sich einbringt.
Daher die Bitte, solltet ihr Pull Requests oder andere Formen der Mitarbeit haben, holt die Leute ab, gebt ihnen ein Zeichen.

Open Door 😉

Weihnachten steht vor der Tür und auch ich werde es rein lassen müssen. Insofern schließe ich die heutigen Gedanken, vielleicht entstehen weitere bei dir. In jedem Fall wünsche ich schöne Weihnachten und eine friedliche Zeit, Zeit zum Nachdenken und mit Anderen in Austausch zu treten, zum Weihnachtsessen oder zum direkten Austausch, ohne Tastatur vielleicht und hoffentlich vielfältig. Bis bald …

Von Frank Bültge

bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.