Also herzlich willkommen zu meinem Vortrag. Open Source ist just about the source, isn't it? Open Source ist also nur über den Quellcode. Das wissen wir ja alle. Nicht wundern, dass hier so ein kleiner Zwerg neben mir steht. Mein Mann hat sich heute ausgesperrt.

Schlüsseldienst war schon da, Mann ist durchgefroren, Kind ist jetzt bei mir, schön warm und mollig. Warum erzähle ich euch heute was zum Thema Open Source? Ich bin Software Engineer bei Elasticsearch. Wer von euch kennt Elastic? Fast alle? Drei Viertel? Okay.

Heute Nachmittag gibt es noch in dem anderen Vortragsraum ein Thema zum Thema, wie wir testen bei Elasticsearch. Vielleicht ganz spannend für die, die das Projekt kennen. Ich bin eine ganze Weile schon bei der Apache Software Foundation dabei. Erst als Nutzer, hauptsächlich von Nudge und Lucin. Später dann als Projektgründer von Apache Mahout.

Inzwischen als Direktor der Apache Software Foundation, als einer von den neun. Gründer von Apache Mahout, Gründer der Berlin Buzzwords. Wer kennt die Buzzwords? Eine, zwei, drei.

Alle anderen, wenn ihr eine Ausrede braucht, um euren Chef dazu zu bringen, die Reisekosten nach Berlin im Juni zu bezahlen. Hint, Hint, im Juni ist Berlin total cool und sonnig. Berlin Buzzwords könnte so eine Ausrede sein. Okay, wer von euch hat ein eigenes Open Source Projekt? Drittel ungefähr, okay.

Wer von euch hat schon mal was getributed zu irgendeinem Open Source Projekt? Ein paar mehr, fast alle, okay. Wer hat schon mal was über ein Open Source Projekt geschrieben? Blogartikel, Rant auf Twitter, whatever. Kommt. Fast alle.

Wer hat schon mal Nutzern geholfen, die Probleme mit ihrem Open Source Projekt hatten? Die Eltern zu Hause, das Kind vielleicht, sonstige Familienmitglieder, Freunde, Kumpels, fast alle, gut. Super. Wer nutzt Open Source im Day Job? Auf Arbeit. Pretty much everything.

Freizeit vermutlich entsprechend. Gut, brauche ich nicht mehr Fragen. So, warum solltet ihr euch alle fragen, ob Open Source wirklich nur die Quelle ist, also ob es da wirklich nur darum geht, um die Softwarequellen, um den Source Code, oder ob es noch um mehr geht?

Gehen wir mal ein paar Fragen durch. Wer von euch hat schon mal Familienmitglieder zu Open Source konvertiert? Wer von euch hat dann geflucht, als beim nächsten Major Update das Nutzerinterface komplett anders aussah?

Also meine Story dazu, ich habe jemanden zu Ubuntu konvertiert, als sie noch Unity, und zwar die uralte, allererste Version hatten. Nächstes Update Released, UI sah komplett anders aus. Super, danke. Wer von euch hat schon mal die Daten der Bekannten konvertieren müssen,

weil sich das Datenschema komplett geändert hat? Ich habe zum Glück einen Mann zu Hause, der sich die Shotware-Version komplett geändert hat,

sich dann hingesetzt, ein Wochenende, hat SQL-Tabellen von Format 1 zu Format 2 konvertiert, mit allen Texten, mit allen Drum und Dran, sodass unsere Verwandtschaft wieder glücklich war. Nehmen wir mal an, ihr habt euer Business, eure Firma auf Open Source aufgebaut. Warum sollte euch interessieren, um was es bei Open Source außer Technik noch geht?

Was ist, wenn das Projekt aufhört, Security-Updates rauszugeben? Was passiert, wenn das Projekt in sich entscheidet, den Weg in Richtung Close Source zu gehen? Was passiert, wenn das Projekt entscheidende Änderungen blockiert, die ihr aber braucht?

Insgesamt heißt das für mich, wenn ich Open Source auf Arbeit einsetze, wie es ja viele von euch tun, hilft es zu verstehen, wie das Projekt funktioniert. Und zwar nicht nur in dem Moment, wo ihr euch dafür entscheidet, sondern kontinuierlich über die Zeit. Kleine Story aus der RPG Software Foundation, wir haben viele Projekte,

die fangen als Community-Projekte an, irgendwann baut sich ein Start-up da drum herum auf, irgendwann ändern sich die Incentives, warum die Leute dort mitmachen. Sowas sollte man im Auge haben, gegebenenfalls beeinflussen können, mindestens aber die Implikationen für das eigene Unternehmen verstehen.

Okay, wenn wir selber ein Open Source-Projekt haben, warum ist das irgendwie sinnig zu verstehen, worum es um mehr geht als um Technik? Wir wollen, hoffe ich jedenfalls, nicht in alle Ewigkeit dieses Projekt ganz alleine betreuen, weil irgendwann gibt es da vielleicht so ein Zwerg, vielleicht wird man irgendwann mal krank.

Wir haben bei den Projekten, die vor 10, 20 Jahren gegründet wurden, die ersten Fälle, wo die Gründer nicht mehr lebendig sind. Das heißt, das Ziel sollte eigentlich sein, wenn das Projekt lange leben soll, diverse Set an Leuten reinzuziehen, selber in der Lage zu sein, die Idee, die hinter dem eigenen Projekt ist, weiter zu kommunizieren,

andere Projekte zu assimilieren oder zumindest zu co-existieren. Auf der anderen Seite sollte man natürlich in der Lage sein, seine eigenen Nutzer vor potenziellen Gefahren, die aus Richtung Gesetzgebung kommen,

Gefahren, die aus Richtung Trademarking kommen, Gefahren, die aus Richtung Patentgesetzen kommen, abzuwehren und zu schützen. Okay, bevor wir uns also damit auseinandersetzen, ein paar Ziele, die man haben könnte. Man kann, wenn man jetzt ein eigenes Projekt gründet, ein Ziel kann sein,

man baut sein Geschäft um Open Source auf, um in einen existierenden Markt einzudringen und die ökonomischen Verhältnisse zu verändern. Man kann das Ziel haben, mit anderen zu kollaborieren, die das gleiche Ziel haben,

wie man selbst und auf diese Art stärker zu werden, als wenn man das Ganze selber machen würde. Man kann aber auch einfach das Ziel haben, einfach nur den eigenen Lebenslauf, die eigene Reputation zu vergrößern. Je nachdem, welches Ziel man hat, ändert sich die Art und Weise, wie man die Community aufbauen möchte.

Die Frage, die man sich entsprechend stellen sollte, ist, wie viel Kontrolle möchte ich über dieses Projekt selbst ausüben? Versus, wie robust sollte das Projekt sein gegenüber Änderungen? Als Beispiel, wie viel Kontrolle möchte ich haben? Wenn ich Benevolent Diktator bin, habe ich die volle Kontrolle über alles. Ich kann alles ändern, ich kann selbst die Lizenz ändern.

Aber in dem Moment, wo es mir oder meiner Firma nicht mehr gut geht, dann ist das Projekt auch am Arsch. Auf der anderen Seite kann ich eine Gruppe von Peers haben, die nach Konsens suchen. Das Ganze ist langsamer. Man ist dann in einer guten Position, wenn Leute das Projekt verlassen

und andere Prioritäten haben. Was außer Quellcode sind Themen, mit denen man sich auseinandersetzen muss, wenn man in Richtung Open Source denkt? Es gibt da den Dreiklang Copyright, Patente, Trademark Recht.

Das sind die einfachen Sachen. Copyright, gucken wir uns das mal an. Wir haben ein Projekt, wir wollen uns darum kümmern, dass alle Nutzer, inklusive aller Derivate, die von unserer Software entstehen, die gleichen Rechte bekommen, wie die, die wir unseren Nutzern geben. Sprich, für Copyleft, GPL, MPL, what have you.

LGPL für Bibliotheken, insbesondere wenn es schon ähnliche Bibliotheken gibt. AGPL für Serversoftware, GPL für alles andere. Wir wollen nur sicherstellen, dass die direkte Nutzer unserer Projekte sind, diese Freiheiten haben. Dann können wir Non-Copyleft Open Source Lizenzen nehmen.

Wenn es klein genug ist, sodass uns das vollkommen egal ist, können wir es auch gleich in die Public Domain geben. Wenn es Bibliotheken sind, die Standards vorwärts drücken wollen, dann wollen wir ebenfalls Non-Copyleft ESL. ESL ist eine gute Variante an der Stelle, weil wir da eine Patentklausel mit drin haben.

Oder wenn wir einfach den Markt ändern wollen, die Ökonomie ändern wollen, sind Non-Copyleft Lizenzen ebenfalls total cool, weil die werden auch von Unternehmen total gerne eingesetzt. Okay, um welches Thema müssen wir uns noch einen Kopf machen? Patentrecht. Sorry, here we dragons.

Es gibt andere, die darüber besser referieren können als ich. Sucht euch die entsprechenden Vorträge raus. Ich werde hier bestimmt nicht in Details gehen. Ein Thema, das bei der ESF immer ganz beliebt ist, ist das Thema Trademarks. Davon gibt es zwei Seiten. Einmal, wenn ich mein Projekt anfange, möchte ich nicht das Projekt anfangen

und Wochen später, Monate später, insbesondere nicht dann, wenn es erfolgreich ist, von einem anderen Projekt oder einer anderen Firma angeschrieben werden, eh Hallo, Trademark Violation. Das heißt, ich muss überlegen, welchen Namen wähle ich aus, sodass der keine Trademarks verletzt.

Kleine Anekdote aus der Hadut Natural. So eine kleine Mäuse sind total cool, Non-Trademark Namen zu erfinden. Nehmt einfach das erste Wort, was die Mäuse sagen und nehmt das als euer Projektnamen. Kein Witz, Hadoub kommt daher, dass Duck Cuttings Kind seinen kleinen Spielzeugelefanten Hadoub genannt hat.

Nutsch kommt daher, dass Duck Cuttings Kind das erste Wort Nutsch war. Garantiert nicht Trademark. Total super. Warum sollten wir uns darum kümmern, wenn Leute unser Trademark infringen? Wir haben nur solange ein Recht auf dieses Trademark, wie wir das auch tatsächlich schützen, dieses Trademark. Was passiert, wenn wir das nicht mehr schützen?

Geht mal auf die Seite ebay.com.de, was auch immer ihr bevorzugt, und sucht nach OpenOffice. OpenOffice ist Open Source, es ist ein Apache-Projekt. Trademark ist bei Apache. Trotzdem könnt ihr da hingehen und OpenOffice-Versionen kaufen. Nicht von Apache. Es gibt andere Geschichten, wie zum Beispiel die Umbenennung

von Firefox in Eiswiesel bei Debian. Es gibt die Geschichte von Gnome ganz unten links. Da musste man sich dann überlegen, ist das jetzt infringing oder nicht. Wenn ein Fußpediküre-Anbieter ein Logo verwendet,

was ganz schön ähnlich ist zu Gnome, stellt es sich heraus, dass es nicht infringing ist. Es ist total okay, das zu tun. Aber so eine Frage werdet ihr euch dann stellen dürfen. Dann stellt sich natürlich die Frage, sollte ich das Geld in die Hand nehmen, das Trademark zu registrieren? Unten. Haps und da.

Wie gehe ich um den Projektnamen zu schützen? Ich finde heraus, wer das sonst nutzt. Google Alerts macht sich dafür total super. Ich treffe die Entscheidung, ist das jetzt infringing oder nicht. Und dann muss ich aktiv gegen dieses Infringement vorgehen. Das muss nicht heißen, dass ich zu meinem Anwalt gehe und denjenigen verklage.

Im einfachsten Fall kann das einfach nur heißen, dass ich hergehe, denjenigen anschreibe, sage, hey, hallo, ich habe das Trademark schon, mach mal bitte was, das können wir uns irgendwo einigen, gibt es da eine Lizenz, die du haben möchtest, kannst du das bitte ändern. Üblicherweise kann man solche Fragen auf nichtgerichtlichen Wegen klären.

Okay, soviel zum den einfachen Themen, die nicht Kot sind. Kommen wir mal zu den etwas schwierigeren Themen, die Leute beinhalten. Wer von euch glaubt noch an den Mythos, dass gute Software von einem einzelnen Hacker

in seinen kleinen stillen Kämmerischen in Übernacht geschrieben wird? Meiner Meinung nach kann sein, ich glaube nicht dran. Großartige Software wird üblicherweise von mehr als einer Person entwickelt.

Es ist üblicherweise geboren aus einer diversen Community, wo die Ideen reinkommen. Es wird üblicherweise, wenn ähnliche Ideen, die schon existieren, weiterentwickelt und oft die Artwork-Software immer weiterentwickelt. Bei Apache heißt das ganze Community Overcode,

bei SerialMQ heißt das People Before Code. Im Grunde heißt das einfach nur ein Projekt, das tut, wenn es keine Leute gibt, die das nutzen und weiterentwickeln. Basierend auf der Erkenntnis, welche Leute geht es denn hier? Für mich geht es auch. Hauptsächlich, in erster Instanz geht es erst mal darum,

wo finde ich Nutzer? Weil damit steht und fällt das Projekt. Wo finde ich die? Wie konvertiere ich die tatsächlich dahin, dass das Nutzer sind? Und wenn die einmal konvertiert sind, wie bringe ich die dazu, bei mir zu bleiben? Übersetzen wir das mal in bekannte Terme,

solche Terme heißen Marketing. Heißen Pressolations. Wie sieht das aus? Na ja, wir gehen auf Twitter, publizieren da ein bisschen was. Wir gehen auf Mailinglisten. Wir gehen zu Hause publizieren da was, wenn es sich um ein IT-Projekt handelt. Wir kreieren Hashtags. Wir kreieren einen Blog.

Ich habe selbst ein Open-Source-Projekt gegründet, netten sich Apache Mahout. Wie habe ich die meisten Leute gefunden, die sind nicht auf meine Mailinglisten gekommen? Die sind auch kaum öffentlich damit rausgerückt, was sie denn machen. Wir hatten eine Powered-by-Seite, kaum einer ist da gekommen und hat die aktiv editiert.

Wir haben sie gefunden, indem Leute rausgegangen sind, Vorträge gehalten haben und hinterher mit den Leuten gequatscht haben, wo dann die entsprechenden Entwickler gesagt haben, hey, hallo, wir nutzen das, aber wir dürfen nicht drüber sprechen. Hat man sich dann unterhalten, hat hinterher festgestellt, okay, wir dürfen nicht drüber sprechen, was genau wir damit machen, aber ihr dürft wenigstens sagen, man nutzt Mahout.

Was sich gut macht, ist, so eine Information zentral zu sammeln, so dass das jeder sehen kann, weil dann haben andere Leute, die das auch einsetzen wollen, einen Grund, das auch einzusetzen. Ich kann hergehen, meine eigenen Konferenz gründen, ich kann aber auch hergehen und bei existierenden Konferenzen sprechen und die Leute dort abholen.

Ich kann hergehen und Presseartikel schreiben, ich kann Bücher schreiben, Bücher revieren. Ich kann hergehen und Trainings aufsetzen, es gibt Konferenzen, da sind Trainings schon mit enthalten, da kann ich einfach hingehen und sagen, ich würde gerne ein Training halten. Es gibt sowas in Berlin, Deutschland, wie das Linux Hotel,

könnt ihr hingehen, könnt sagen, ich wäre gerne Trainer, wenn ihr einen entsprechenden Nachweis bringen könnt, dass ihr das Thema auch wirklich versteht, könnt ihr dort den Leuten beibringen, wie eure Software genutzt wird. Klar, Konferenzvorträge, wichtiger als der Vortrag, üblicherweise ist der Hallway-Track, das heißt einfach noch da bleiben,

auf den Fluren mit den Leuten quatschen. Bei manchen Konferenzen gibt es die Möglichkeit, Stände zu sponsoren, das ist eine super Variante, um mit Leuten ins Gespräch zu kommen, einfach da stehen bleiben, mit denen quatschen, die dahin gucken.

Wie finden wir potenzielle Kontributoren zu einem Projekt? Weil irgendwann wollen wir nicht mehr nur selber schreiben und selber Bugreports fixen, irgendwann wollen wir die Leute dazu bringen, die Patches selber einzureichen. Sorry, Ihre Babybodies,

helft den Kindern oder helft den Anfängern, schnell abzuspeed zu kommen. Ich weiß nicht, wer von euch das selber kennt, wenn man Software auf Arbeit einsetzt, hat man meistens nicht viel mehr als 15, 20 Minuten, maximal einen halben Tag, um zu evaluieren, ob das,

was man sich da anguckt, tatsächlich das ist, was man braucht. Maximal hat man pro Projekt vielleicht einen Tag. Das heißt, je schneller der Nutzer tatsächlich Ergebnisse sieht, umso schneller habt ihr den. Zweitens, es gibt keine dummen Fragen, es gibt nur dumme Antworten. Einfach auf der Mailing-Liste antworten. Es gibt von Christian Köhntorpp

einen schönen Vortrag zum Thema Flame Wars, der auf der Frostconfor ein paar Jahren gelaufen ist. Macht euch eine FAQ, sodass ihr Fragen, die immer wieder kommen, die einfach nur Anfängerfragen sind, ganz schnell mit ORS beantworten könnt und aus den ORS die entsprechenden Textbausteine rauskopieren können, damit den Leuten erstmal geholfen ist. Andere, die dieses Verhalten beobachten,

stellen fest, es ist ganz einfach, Anfängerfragen zu beantworten, weil es gibt eine FAQ. Die blinkt rein, nicht einfach nur Read the Fine Manual. Die blinkt in das Manual, da steht die Antwort. Potentiell suchen die Leute dort nach den Antworten weiter. Wer von euch studiert denn noch? Kennt ihr den Google Summer of Code?

Hände hoch, wenn dann können. Okay, wo ist ein Mikrofon? Irgendjemand von denen, die die Hand gerade gehoben haben, erklärt bitte den G-Sock. Ich glaube, du hattest die Hand selber oben. Sorry.

Was ist der Witz am G-Sock? Am Google Summer of Code? Freiwillige vor. Für mich ist der Witz am Google Summer of Code,

dass ihr euch bei den Projekten bewerbt. Die Entscheidung, ob ihr teilnehmt, liegt bei den Projekten selbst. Am Ende des Google Summer of Code bekommt ihr aber das Geld von Google in vierstelliger Höhe. Das ist weniger als das, was ihr üblicherweise bei einem Praktikum, bei einem IT-Anbieter bekommt.

Aber ihr habt die Reputation und die öffentliche Sichtbarkeit. Okay, Nutzer zu unterstützen, heißt auch, sie da abzuholen, wo sie sind. Also nicht sie dazu zu bringen, auf eure Mailing-Listen zu kommen. Stack Overflow ist eine Variante. Wenn sie auf den Mailing-Listen sind, total super.

Als kleine Randnotiz bei Malhaut hatten wir durchaus Leute, die einfach nur auf der Mailing-Liste geholfen haben. Potenziell vom Arbeitgeber keinen Code kontributen durften, whatever. Trotzdem haben die das Commit-Bit bekommen einfach als, hier ihr macht eine tolle Arbeit. Das ist eine super Art, die Leute zu motivieren.

Screenshot von Open Office. Nicht alle sprechen die gleiche Sprache. Es kann durchaus sein, wenn das Projekt erfolgreich genug ist. Sprachspezifische Dokumentation, sprachspezifische Foren anzubieten und auf die Art und Weise Leute in das Projekt reinzuholen, die vielleicht keine Experten sind, die aber durchaus in der Lage sind, Dokus zu übersetzen.

Nicht jeder ist, nicht für jeden ist ein Mailing-Listen das richtige Kommunikationsmedium. Ich selber mag eigentlich so Webforen nicht so total gerne. Das CAS fand ich super. Also funktioniert. Kann man sich angucken, auch wenn man gigi ist.

Eins, was sehr wichtig ist, wenn ihr anfängt, Leute reinzuholen als Kontributoren, ist das Thema Priorisierung. Die erste Frage, die bei uns bei Mahut immer kam, wie kann ich anfangen, wo braucht ihr Hilfe? Die nächste häufige Frage,

wann werdet ihr Feature X shippen? Macht deutlich, wo eure Priorisierung ist. Macht deutlich, wo ihr tatsächlich Hilfe braucht. Wir haben irgendwann sehr explizit gesagt, okay, liebe Studenten, wenn ihr jetzt noch in den Machine Learning Algorithmus kommt und sagt, ihr könnt den innerhalb von drei Monaten implementieren, dann schicken wir euch weg, weil das ist erstens unrealistisch

und zweitens brauchen wir den nicht. Das, was wir brauchen, sind Tests, Dokumentation, Kommunikation, Hilfe, etc. So eine Geschichte. Macht deutlich und sichtbar öffentlich, was ihr braucht und priorisiert das durch.

Als kleine Randnotiz für die, die Software nutzen. Wenn Feature-Requests kommen, ist die übliche Antwort, Patches welcome. Das klingt so wie ein, zieh ab, ich will nix von dir wissen. Das, was es mindestens bei der Patchy Software Foundation üblicherweise heißt, ist, hey, sorry, wir haben gerade nicht die Bandbreite. Wenn du daran arbeiten möchtest,

wir helfen dir total gerne, aber wir schaffen es nicht. Es ist im Grunde ein Hilfeschrei. Also bitte nicht falsch lesen. Es ist wirklich ein, kommt bitte zu uns und macht mit. Genauso auf der anderen Seite.

Auf der anderen Seite heißt es natürlich auch, Erwartungen zu managen, den Leuten zu sagen, kommt zu uns, sie einzuladen und denen auch zu sagen, was ihr braucht. Das, was es bei der Patchy Software Foundation gibt, ist einen sogenannten Attic. Alle Projekte, die nicht mehr genügend Leute haben,

die sich darum kümmern, entwicklungstechnisch, landen im Attic. Was wir beobachtet haben, ist, dass kurz bevor die Leute in den Attic gehen, gibt es eine Mail an die Projekt-Mailing-Liste. Wo drin steht, das passiert demnächst. Ganz häufig passiert es, dass dann auf einmal die Entwickler kommen und sagen, hey, hallo, ich habe doch noch Zeit euch zu helfen,

geht bitte noch nicht dahin. In dem Moment, wo ihr sichtbar macht, was ihr braucht, bekommt ihr wahrscheinlich auch das Feedback und die Unterstützung, die ihr benötigt. Ähnliches ist bei Mahout passiert, wo ich eine Mail geschrieben habe, Call to Action, Mahout needs your help, wo einfach explizit aufgelistet wurde, wo wir Hilfe brauchen, bei Dokumentation, bei Webseite,

bei Übersetzungen, bei mehr Testing bitte, bei Testcoverage, bei Performance Benchmarks, also quer durch die Bank, war bisher einer der beliebtesten Sreds beim Projekt. Es gibt andere Publikationen,

auch in anderen Communities, das müsste vom Linuxkernel sein, eine ähnliche Publikation, wo es darum geht, zu erklären, wie man anfängt, wo man anfängt. Es sollte sich von selbst verstehen, dass das Ganze natürlich öffentlich passieren sollte,

Feature-Diskussionen öffentlich sein, es sollte öffentlich sein, wer woran arbeitet. Als kleine Anekdote zum Thema Issue Tracker. Ich habe mal Hadoop Hackathon vor ein paar Jahren in Berlin gemacht. Es waren alles gestandene Entwickler, die teilgenommen haben, die aber keine Open Source Erfahrung haben. Das Thema, was den Leuten, den Teilnehmern am wichtigsten war,

was am Ende gewonnen hat, war, zeigt uns doch mal bitte, wie das funktioniert mit den Patches. Die Lesson Learned für mich war, damals hatte Hadoop schon so einen Tech Getting Started für ganz, ganz triviale Geschichten. Typos in der Dokumentation, Typos im variablen Namen, ähnliches,

wo man wirklich nicht viel kaputt machen kann. Das hilft aber denen, die gerade erst anfangen, gerade erst die Füße nass bekommen, erstmal durch den Prozess durchzulaufen, ohne ein großes technisches Feature implementieren zu müssen. Einfach erstmal zu sehen, wie funktioniert das. Ich check das aus. Was nehmt ihr für eine Versionskontrolle? Giz, Subversion,

what have you. Ich bau das Ganze, wenn es Java ist, vermutlich Maven, Gradle, Arndt, was auch immer. Ich mach eine Änderung. Wie komme ich zu dem Patch? Wo schick ich den Patch hin? Ist bei jedem Projekt ein bisschen anders. Es hilft, wenn man durch diesen Prozess einfach einmal durchgelaufen ist, festzustellen, hey, so schwer ist das gar nicht.

Okay, wie belohne ich die Typen, die da zu mir kommen? Meistens sind die Patches scratch your own itch. Wenn so ein Patch reinkommt, was ist das Wichtigste? In dem Moment, wo der Patch reinkommt, fängt die Uhr an zu ticken. Je schneller das Feedback kommt,

umso schneller habt ihr den Typen noch in einem Status, wo das komplette Change Set noch im Kopf ist, wo das komplette Design noch im Kopf ist. Je schneller das Feedback und das Review kommt, umso wahrscheinlicher ist es, dass die Entwicklerin, die den Patch eingerichtet hat,

eingereicht hat, noch vom Arbeitgeber, die Zeit hat, Änderungen zu machen, noch nicht auf ein anderes Projekt gesetzt wurde, noch nicht auf ein anderes Kundenprojekt gesetzt wurde, sondern noch Änderungen machen kann. Das heißt, da zählt dann tatsächlich Zeit. Was bei Hadoop zum Beispiel hilft,

was auch bei Elasticsearch langsam hilft, ist, automatische Checker zu haben, die so einfache Sachen wie Checkstyle, wie gibt es zusätzliche Schlagentests fehl, schon mal automatisiert durchtesten zu können, sodass ich dafür nicht draufgucken muss. In dem Moment, wo der Patch reinkommt, keine Ahnung, irgendein Committer sagt,

ja, sieht gut aus, ist jetzt nicht irgendwie ein Angriff auf unsere Server, lasst mal bitte durch sie einlaufen, entsprechende Reports kommen an den entsprechenden Zett ran. Dann aber auch die eigenen Leute dazu anzuhalten, zügig, auch tiefer gehende Reviews zu machen.

Was auch hilft, ist klare Regeln und klar dargestellte Regeln zu haben, was ein acceptabler Patch ist. Ich sollte mir nicht erst in dem Moment, wo der erste Patch kommt, überlegen, ja, eigentlich sollte jeder Patch einen neuen Test haben. Kommt nicht so gut. Ich sollte mir auch nicht in dem Moment, wo der erste Patch kommt,

überlegen, ja, eigentlich will ich das Feature gar nicht. Je länger die Leute Zeit damit verbringen, den Patch vorher schick zu machen, umso frustrierter sind sie, wenn sie hinterher feststellen, das war gar nicht das, was das Projekt wollte. Das heißt auch, wenn ihr früh sagen könnt, das wollen wir nicht,

dieses Feature ist nichts für uns. Sagt es möglichst frühzeitig, je länger der Entwickler Zeit damit verbringt, das Ding zu entwickeln, umso mehr Frust entsteht, wenn dann am Ende ein Nein kommt. Wie kann man noch Dankeschön sagen? Man kann Schokolade schippen. Vor langer, langer Zeit habe ich mir an Jules

etwas entwickelt, lange bevor es bei Red Hat war. Der entsprechende Reviewer saß in Australien, hat mir ganz schnell geantwortet, war total super, hat mir iTunes-Vouchers angeboten, damit der Patch dann auch tatsächlich in seinem Projekt landet und ich auch eine Motivation habe, zu meinem Manager zu gehen und das Okay zu holen.

iTunes-Vouchers? Nee, wollte ich nicht. Ich hatte in der gleichen Zeit der Patch immer haut schon auf dem Weg. Was ich wollte, war einfach nur einen Blogpost auf seinem Blog, um mein Projekt ein bisschen herauszustreichen, für mehr Publicity zu sorgen. So einen einfachen Austausch, die überhaupt kein Geld kostet, kann durchaus hilfreich sein.

Was aber sehr viel wichtiger ist, ist Dankeschön zu sagen. Das, was bei dem Jules-Patch mir geholfen hat, war mein Name stand im Jira, mein Name stand in der Commit-Message, mein Name stand in den Release Notes. Es war total easy, zu meinem Manager hinzugehen und zu sagen, hey, guck mal da.

Ist gut. So ein Dankeschön zu sagen und das überall mit reinzuschreiben, den Namen überall mit reinzuschreiben, ist total billig. Also wirklich kostetechnisch billig. Deswegen solltet ihr es auch nutzen. Wenn ihr richtig gut seid, sagt er nicht nur Danke, sondern er gibt ein qualifiziertes Dankeschön, in dem er sagt,

Dankeschön für XYZ, weil das hat mir bei ABC weiter geholfen. Dann hat man den Vorteil, dass die Leute tatsächlich wissen, dass der Patch tatsächlich durchgelesen wurde. Dankeschön bringt euch aber nur

ein gewisses Stück des Weges. Irgendwann müssen die Leute auch ihre Miete bezahlen, irgendwann müssen sie auch ihren Einkauf bezahlen. Das heißt, über kurz oder lang sollte ein finanzieller Benefit kommen. Das heißt nicht, dass ihr die Leute dafür bezahlen müsst. Aber dadurch, dass ihr an zentraler Stelle

in dem Projekt sitzt, in einer guten Position umgegeben, jemand kommt zu euch, diejenigen mit Freelance-Aufträgen zu versorgen, diejenigen mit einem neuen Job zu versorgen. In dem Moment, wo ihr seht, dass da jemand Probleme hat, in dem Moment, wo ihr seht, dass da jemand Unterstützung gebrauchen könnte, nutzt einfach dieses Netzwerk aus.

Ich will mir schon über Geld sprechen. Über kurz oder lang werdet ihr mehr als einen Hut tragen. Das ist der Projekthut, das Potenzial der Hut von der Firma, für die ihr arbeitet.

Das Potenzial der Hut für den Auftraggeber, für den ihr arbeitet. Ihr werdet also über kurz oder lang euch entscheiden müssen, wie ihr diese Hüte, wann ihr welchen Hut tragt. Wir hatten bei der Berlin BuzzFeeds eine Keynote von einem total super Speaker, der zum Thema Open Source gesprochen hat. Die Keynote kam,

naja, so la la an. Wir haben hinterher versucht, herauszufinden, woran das lag. Er hat über die Community gesprochen und über die Community-Probleme. Er hat ausschließlich aus Community-Perspektive gesprochen. Das Dumme an dem Ganzen war, dass er als Slide Deck, weil das nun mal dummerweise sein default Slide Deck war,

das Slide Deck von seinem Start-up genommen hat, was ein nahezukommender Konkurrenzprodukt entwickelt hat zu diesem Projekt. Das heißt, von Slide 1 an war die Idee in den Köpfen der Zuhörer, naja, der macht jetzt einfach nur Bashing. Nee, war es nicht. Ab dem Moment hat er angefangen, immer dann,

wenn er auf die Bühne gegangen ist, eine entsprechende Mütze zu tragen, für seinen Start-up, in dem Moment, wo er nicht mehr für seinen Start-up gesprochen hat, Mütze runter, das Ganze sehr sichtbar gemacht für die anderen Leute. Einfach am Anfang der Vorträge in Kontext gesetzt, unter dem er gerade spricht. So, das heißt,

wenn wir über Geld sprechen, sprechen wir über Funding. Wofür brauchen wir den Funding? Wir brauchen Funding für Infrastruktur. Was ist Infrastruktur? Versionskontrolle, Continuous Integration, etc. Wir können uns für Canned-Hosting entscheiden, das heißt, so was wie GitHub.

Früher hieß das Ganze SourceFudge. Wir können uns aber auch entscheiden, das Ganze selbst zu hosten, hat alles seine Vor- und Nachteile. Wer schon ein bisschen länger dabei ist, weiß, dass die Canned-Hosting-Seiten potenziell irgendwann weggehen, potenziell irgendwann Geld kosten. Das heißt, man sollte sich dann überlegen, mindestens einen Backup zu haben. Wir brauchen Zeit,

um die Infrastruktur zu konfigurieren. Weil GitHub ist schön, aber irgendwann muss ich auch Labels und Texts aufsetzen, irgendwann muss ich auch die Leute hinzufügen, dafür brauche ich Zeit. Ich brauche jetzt potenziell, wenn ich mich für die selbst gehostete oder mindestens gebackupte Variante entscheide, tatsächlich Metall, auf dem das Ganze läuft.

Wir haben schon über Zeit zur Konfiguration gesprochen. Wir brauchen Zeit, um die Infrastruktur zu konfigurieren. Wir brauchen aber auch Zeit, um das entsprechende Coding zu machen. Wir brauchen Zeit, um die Non-Coding-Arbeit zu machen. Das heißt, wir brauchen irgendwoher Sponsorgeld.

Bei der ESF gibt es dafür eine entsprechende Dankeschön-Seite. Sponsoren bei der ESF spenden nur an die Foundation, nicht an Projekte. Geht da hauptsächlich in die Infrastruktur und in einige wenige Bezahlte. Direktorenposition ist nicht bezahlt. Keiner der Entwickler ist bezahlt.

Die sind, wenn, maximal gesponsert von ihrem Arbeitgeber. Trotzdem braucht auch so etwas wie die Apache Software Foundation Geld für Maschinen und für die Leute, die die administrieren. Anderes Thema. Kommunikation. Wie kommuniziere ich in diesem Open-Source-Projekt?

Das erste, was ich brauche, ist ein Mission Statement. Ich möchte den Leuten erzählen, was ich mache. Klar. Ich will den Leuten aber auch erzählen, was ich nicht mache. Damit da nicht 3000 Leute zu mir kommen und sagen, ihr wisst ja nicht das Feature. Nein, das will ich nicht, weil da ist das Mission Statement. Ich möchte auch klar kommunizieren, wo meine Prioritäten liegen.

Damit ganz klar ist, warum ich den Patch nehme und nicht den. Und warum ich den Patch jetzt angucke und nicht den später. Willst du trinken? Komm her. Wie kommuniziere ich in so einem Open-Source-Projekt?

Es gibt die Variante Messmedia. Jeder kommuniziert mit jedem. Funktioniert mit zwei Leuten, mit drei Leuten, mit vier Leuten. Irgendwann wird es einfach zu viele. Das, was bei Apache ganz bevorzugt wird, ist der zentrale Hub. Das heißt, ich habe einen Issue-Tracker, ich habe eine Mailing-Liste,

ich habe eine Quelle für die Wahrheit. Eine einzige. Wenn ich die Mailing-Liste subscribt habe, dann lese ich da alles. Ich kann weiterhin kommunizieren auf synchronen Channels. Das heißt, ich kann so was wie einen Zoom-Chat machen, ich kann so was wie einen Google Hangout machen, ich kann auf Slack, auf IRC kommunizieren. Aber alle Entscheidungen,

die ich da treffe, ziehe ich bitte auf die Mailing-Liste zurück, sodass die, die nur auf der Mailing-Liste sitzen, wirklich eine Möglichkeit haben, dem kompletten Projekt zu folgen. Muss jetzt nicht eine Mailing-Liste sein, es kann doch irgendein anderes Medium sein. Ok, welche Kommunikationskanäle habe ich? Wozu brauche ich die?

Wir reden über Menschen, das heißt, wir werden Konflikte lösen müssen. Wir reden über Menschen, das heißt, wir werden die irgendwie motivieren müssen, wir müssen Konsensus finden, wir müssen Feedback zurückgeben, wir müssen den neuen Nutzern, aber auch existierenden Sachen beibringen und wir müssen Ziele und die Richtung des Projekts vorgeben.

Das, was wir hier machen, ist Face-to-Face-Kommunikation, hohe Bandbreite. Es ist total einfach, Sachen rüber zu bringen. Dummerweise aber etwas teuer aufzusetzen, weil wir müssen alle hierher kommen, wir müssen alle die Reise bezahlen, wir müssen alle die Zeit haben, hierher zu kommen.

Und glücklicherweise bei dem Vortrag haben wir da hinten eine Kamera, üblicherweise ist die Kommunikation, die wir hier haben, flüchtig. Das heißt, wir müssen das immer und immer wiederholen. Videochat. Wir brauchen nicht mehr Reisen, wir haben eine virtuelle Kommunikation, das ist also schon mal billiger. Es ist immer noch relativ teuer aufzusetzen, weil es ist immer noch

synchron in der Zeit. Das heißt, wenn wir unterschiedliche Zeitzonen haben, wir haben bei Elasticsearch Leute unten in Australien sitzen, wir haben Leute in Japan sitzen, wir haben Leute in Europa, wir haben Leute in Südamerika und in Nordamerika. Zeitzone technisch ist ein Alptraum. Zeitzonen an sich sind schon ein Alptraum, aber wenn man das wirklich nur synchron machen will,

wird es ein Alptraum. Und es ist, naja, so ein bisschen ist es nicht mehr so flüchtig, weil man kann das Ganze natürlich aufnehmen. Jetzt stellt euch aber mal vor, ihr müsst einem Projekt wie dem Apache HDDP beitreten. Ihr habt die Kommunikation von über einer Dekade,

nur in synchroner Kommunikation, ohne Digest. Viel Spaß beim Gucken. Gehen wir weiter, machen wir einen Online-Group-Chat. Noch weniger Bandbreite, noch mehr Missverständnisse, aber relativ billig aufzusetzen, ist aber dummerweise immer noch synchron, aber es ist schon mal nicht mehr ganz so flüchtig.

Ich kann immerhin über die Logs suchen. Schritt weiter. Webforum. Gleiche niedrige Bandbreite, relativ billig aufzusetzen, auf einmal sind wir auch synchron, haben das Zeitzonenproblem nicht mehr, wir können es auch durchsuchen. Maining-Listen mit einem

relativ okayischen Client, der wenigstens Threading unterstützt. Wir können suchen, wir haben die Diskussionen gesrattet, das heißt, wir können uns entscheiden, bestimmten Unterästen nicht mehr zu folgen in der Diskussion, die einfach wegzukappen. Issue Tracker. Immer noch niedrige Bandbreite, ziemlich gut strukturiert,

feinkranular, sehr gut, um eine strukturierte Diskussionssache an. Wikis, naja, strukturiert halt, je nachdem, wie gut wir da drin sind, das Ding aufzuräumen. Wikis eignen sich gut, um von einem sehr hohen Standpunkt aus einen Überblick

über das Projekt zu geben. Wenn wir Webseiten kreieren, haben die da noch den Vorteil, dass sie üblicherweise ziemlich gut strukturiert sind, weil die Leute sich tatsächlich einen Kopf drüber machen. Das heißt, wir brauchen, je nachdem, welches Problem wir haben, potenziell ein anderes Kommunikationsmedium, um das Problem zu lösen. Wenn wir persönliche

Konflikte lösen wollen, hilft es, die Leute in einen Raum zu bringen. Wenn wir das nicht hinkriegen, hilft es, die Leute wenigstens in einen Video-Chat-Raum zu bringen. Das heißt, hohe Bandbreite hilft dort an der Stelle. Wenn wir dafür sorgen wollen, dass das Design, was wir gemacht haben, überlebt, hilft es, ein strukturiertes Medium zu haben, was sich durchsuchen lässt und was gut strukturiert ist,

wo man sich einfach durchklicken kann. Das, was wir trotzdem wollen, ist einen kanonischen Platz für aktuellen Status und das möglichst in Selbstbedienungsmethodik, wo wir die Dokumentation aufheben, sodass wir uns nicht nochmal wiederholen müssen und wo wir

vorangegangene Diskussionen trecken können, sodass Leute, die einen längerfristigen Background zu dem Projekt haben, neu hinzukommen, die Leute einfach auf die Diskussion aufmerksam machen können, um nochmal durch die komplette Diskussion durchlaufen zu müssen. Um was müssen wir uns

noch einen Kopf machen? Wir müssen irgendwie dafür sorgen, dass mindestens wir, am liebsten aber eigentlich alle Kontributoren, geistig gesund bleiben, sich nicht überarbeiten, nicht zu viel annehmen an Arbeit,

die sie am Ende gar nicht machen. Ein Thema in dem Zusammenhang ist der sogenannte Le-Cookie-Effekt. Bekannt? Le-Cookie-Effekt heißt einfach, ich habe da ein Issue, jemand hat eine Frage, mein liebster Kometo sagt, ja, mache ich. Stille. Nichts. Kein anderer kümmert sich drum,

weil einer hat ja gesagt, ich mache es. Kein anderer traut sich, da rein zu grätschen. Wirklich nur das annehmen, wovon man wirklich überzeugt ist, dass man das hinkriegt oder nachdem man so ein Issue angenommen hat, festgestellt hat, nee, geht nicht, das Issue hinterher aktiv wieder freigeben.

Es gibt entsprechende Mählichsreds bei Nail-Patchy-Software-Foundation auch zum Thema Voluntirikis. Nicht zu viel auf euren Teller packen. Es hilft, wenn das Projekt nicht perfekt ist. Nicht perfekte Dokumentation,

wo Teipos sind, sind der beste Getting Started-Point für Anfänger. Einfach mal drin lassen und gucken, wer sich drum kümmert. Das haben wir beim HAUD ganz am Anfang gemacht, um rauszukriegen, wie viel Interesse tatsächlich da ist. Der Projektplan war in groben Teilen fertig, aber streckenweise fehlte noch was. Es war nicht so, dass der Gründer das Ding komplett fertig gemacht hat,

sondern er hat einfach mal eine Weile gewartet, um zu gucken, ob jemand diesen Ball aufnimmt und weiterspielt. Einfach um zu gucken, wie viel Interesse da ist. Das heißt jetzt nicht, dass ihr das Ding komplett broken lassen sollt und alle Check-Side-Warnings an sein sollen. Das ist nicht der Sinn und Zweck. Nächstes Thema,

wenn wir Tag und Nacht hier vorsitzen. Ganz ehrlich, mir fällt es leichter, die kleinen ganzen Tage durch die Gegend zu tragen, als einen Tag lang an dem Laptop zu koden. Bei einem Laptop sagt mein Nacken irgendwann Aua. Das heißt, wir müssen uns darum kümmern, dass wir gesund bleiben und uns mit so unglaublich langweiligen Themen

wie Ergonomie auseinandersetzen. Für wen das ein Problem oder für wen das ein interessantes Thema ist, es gibt bei der Berlin-Buswards von Eric Evans eine Keynote dazu. Der ist durch das Problem Carpal Tunnel Syndrome durch mit allem, was dazugehört, OPs und Schmerzen. Einfach mal angucken und hinterher sagen,

nee, interessiert mich nicht. Aber dann ist es wenigstens eine informierte Entscheidung. Wenn euer Projekt wächst, müsst ihr auf einmal balancieren zwischen, es gibt Leute, die da dran Fulltime arbeiten, die in der Lage sind, dem kompletten Projekt extrem zu folgen und es gibt Leute,

die machen das in ihrer Freizeit. Die können also nicht aus diesem Feuerwehrschlauch an Informationen trinken. Es gibt also die Frage, wollt ihr beide Gruppen integrieren und wenn ja, wie macht ihr das am besten? Wie kriegt ihr das hin? Nächstes wichtiges Thema,

wie gehe ich mit giftigen Leuten um, poisonous people. Es gibt Leute, die ziehen Energie aus dem Projekt raus, indem sie Kommunikationszeit von den Kommentern einfach binden, indem sie mit komischen Vorschlägen kommen, indem sie sagen, wir müssen doch in die und die Richtung gehen. Es gibt komplette Bücher, es gibt ein komplettes Video

von Ben Collins-Sassmann und Brian Fitzpatrick zum Thema Dealing des poisonous people. Wem deutsche Sprache lieber ist, der geht auf die Seite der Frostkorn und sucht nach Christian Köhntopf zum Thema Flame Wars, Kommunikationszusammenbrüche im Netz. Das sind ein paar Strategien, wie man mit solchen Leuten umgehen kann.

Last but not least, Change Management. Es kann sein, dass der Tag kommt, wo ihr das Projekt nicht mehr betreuen wollt. Es gibt den Tag, wo man in Rente geht. Es gibt den Tag, wo man vielleicht mehr für drei Wochen in Urlaub geht. Es gibt den Tag, wo man längere Zeit offline ist.

Was hilft, ist dieses Handover vom Anfang an, um das Projekt einzubauen. Ich habe die Berlin Bus in Berlin gegründet in der Annahme, es gibt nur eine Edition dieser Konferenz. Danach habe ich drei, vier Jahre verbracht, die Konferenz wieder loszuwerden, ohne dass ich stirb.

Einfach sämtliche Kommunikation, sämtliche Herangehensweisen, sämtliche Prinzipien, sämtliche Ideen, die Speaker-Auswahl, die Keynote-Auswahl, muss da alles an einen Provider übergeben werden, der das dann hinterher übernommen hat. Wenn ihr so etwas von vornherein einbaut, macht ihr es für euch vermutlich einfacher. Okay, mit dieser langen Liste

bin ich, nachdem ich auf die nur noch verbleibenden fünf Minuten schon hingewiesen wurde, offen für Fragen und bedanke mich für die Geduld. Bei allen inklusive dir.

Vielen Dank, Isabelle.

Genau. Als nächstes dürfen wir uns, glaube ich, auf den Dany-Freund. Gab es eine Meldung? Ich habe gerade nicht genau. Hast du eigentlich jemanden gesehen? Bitte? Hast du jemanden gesehen, der noch eine Frage hatte? Ich habe jetzt noch niemanden gesehen. Kommt schon an eine Frage. Mindestens eine. Tut uns leid. Dann nicht.

Dann sehen wir uns heute nach Mittag. Hast du alles erklärt? Oder so schlecht erklärt, dass wir alle eingeschlafen sind. Aber ich sehe da noch wache Augen. Also zur Not, ich bin da noch auf dem Flur. Dann kann man die Fragen, die jetzt peinlich sind, doch draußen stellen. Aber es gibt eigentlich keine peinlichen Fragen. Gut, danke schön.