Vieles von dem, was ich gleich erzählen werde, kommt aus dem Open-Source-Projekt Taskwarrior, das es mittlerweile seit 2006 gibt, also seit elf Jahren. Einiges von dem, was ich erzählen werde, ist mit Augenzwinkern gemeint,

ihr werdet das merken, es hat alles einen ironischen Unterton. Ich bitte, das alles nicht zu ernst zu nehmen. Ich habe den Talk schon mal gehalten vor Leuten, die professionell Linux nutzen, die fanden das alles gar nicht so lustig, ich hoffe, ihr findet es ein bisschen lustiger, weil ihr vielleicht auch als Hobby Linux habt, oder ein anderes Open-Source-Projekt.

Ich selber bin nicht seit elf Jahren bei Taskwarrior, sondern erst seit sieben. Von daher kann ich nichts für die ganzen zehn Jahre sagen, sondern auch nur für die Zeit, die ich mit dabei bin. Und weil es so viele interessante Erlebnisse gab und so viele Sachen, die sich auch einigermaßen kategorisieren lassen, gibt es halt diesen Talk, um das mal so ein bisschen zusammenzukehren.

Zum Projekt Taskwarrior vielleicht, gibt es hier irgendwen, der das nutzt, doch ein paar. Für die anderen, Taskwarrior ist eine Aufgabenverwaltung für die Kommandozeile, was sich vor allem dadurch auszeichnet, dass es sehr, sehr gut mit Dringlichkeiten umgeht und sich dazu eignet, Aufgaben nach Dringlichkeit zu sortieren,

sodass man immer weiß, was man als nächstes zu tun hat. Das ist so die Basisinformation. Taskwarrior hat so ein paar Ansätze, ein paar Punkte, die in der Philosophie drinstehen, was es sein möchte und ich glaube, was es auch erfüllt. Es soll open sein, es ist open source, unter MIT-License, es steht nicht im Weg,

hat sehr schnelle Ausführungszeiten, auch wenn man große Anzahl von Aufgaben hat. Es ist völlig unabhängig, mit welcher Mythologie, also, nee, Mythologie ist falsch, mit welcher Methodik man seine Zeit managt.

Taskwarrior kann das alles, es ist mehr oder weniger ein Werkzeugkasten von Möglichkeiten, mit denen man seine Aufgaben verwalten kann. Das soll es dazu auch sein. Wisdom ist vielleicht ein kleines bisschen hochgegriffen, deswegen auch kursiv. Es ist einfach eine Sache der Erfahrungen, die wir in den letzten elf Jahren,

bzw. ich in den letzten sieben Jahren gesammelt haben. In dem Talk wird das rewarding und enjoyable ein bisschen zu kurz kommen, es wird oft über das frustrating gesprochen werden. Vielleicht weil es auch am besten hängen bleibt, wenn Leute Sachen nicht so toll finden, als wenn Leute wirklich toll finden.

Wir haben eine Menge gelernt, vor allem über Erwartungen, aber auch über das, was es heißt, ein Projekt öffentlich zu machen. Nur ein. Sachen öffentlich zu machen und als Open Source zu veröffentlichen.

Ich stelle mir das so vor, dass ich euch ein bisschen was erzählen werde und würde gerne direkt, wenn ihr was habt, Feedback von euch erwarten. Einfach durch ein Handzeichen, dann bauen wir das mit ein. Ich hoffe, ich denke jederzeit daran, dass sich das, was ihr sagt, wiederholt, damit es auch auf dem Video zu hören sein wird. Auf dem Video zu hören sein wird, naja.

Also wichtig ist, dass ihr so ein bisschen vom Mitmachen lebt, so stelle ich mir das zumindest vor. Wer von euch macht bei einem Open Source Projekt mit? Das ist eine deutlich bessere Quote als beim letzten Mal. Was beschreibt eure Rollen am besten? Irgendwas davon?

Ja, ich finde mich auch in verschiedenen Projekten, in verschiedenen Rollen wieder. Ja, genau. Wer von euch möchte ein Open Source Projekt starten?

Oder hat vor, ein Projekt, das er selber hat, als Open Source zu veröffentlichen? Ich will dich nicht abschrecken, aber du wirst einige erschreckende... Ich wollte diesen Talk abwarten. Das ist eine kluge Entscheidung, diesen Talk abzuwarten,

bevor man was Eigenes startet. Genau. Warum? Warum willst du ein Open Source Projekt machen? Weil du was zurückgeben möchtest, weil du denkst, dass es für andere vernutzen ist. Ich arbeite auch mit profitieren nicht doppelt.

Genau. Also Oleg sagt gerade, dass er eine Arbeit gemacht hat und dass er gerne möchte, dass andere von dem, was er gemacht hat, auch profitieren werden. Ich denke, das ist das, was wir am meisten Open Source Projekte anfangen. Dass man irgendwas macht, so eigene Stellen kratzen und dass es dann veröffentlicht und für andere verfügbar macht.

Habe ich tatsächlich auch schon gehört, von Leuten, die Puppet-Module geschrieben hatten, auf die sie keinen Bock mehr hatten, die sie dann veröffentlicht haben und gesagt haben, dann ist es erstmal weg. Da können andere sich drum kümmern. Genau. Also es ist schön, wenn man sich, wenn man ein Open Source Projekt starten wollt, das seht ihr da,

könnte alles lernen, Technik und hoffen, dass man anderen Leuten geholfen hat. Da gehört ein kleines bisschen mehr dazu. Man kann auch Development lernen, wie man mit anderen Leuten zusammen programmiert, wie man mit vielen Leuten zusammen arbeitet. Das hat viel mit Leuten zu tun, sehr viel.

Und man hofft am Ende, dass es das, was du gesagt hast, dass das, was man selber gemacht hat, für andere auch hilfreich ist. Aber es gibt ein Aber. Startet das Open Source Projekt bitte nicht, wenn ihr wollt, wenn ihr in den Arm genommen werden wollt.

Das haben Systemadministratoren auch. Wenn alles läuft, ist super. Dann sagt keiner Danke. Wenn nichts läuft, sagen alle, was macht ihr für einen Scheiß. So ähnlich kann es auch in größeren Projekten vorkommen.

Wenn ihr euch vorstellt in einem Open Source Projekt, wenn ihr eine Grenze ziehen wollt zwischen dem, was schon supportet ist und was noch supportet werden will, werdet ihr vielleicht rausfinden, dass es gar keine Linie gibt. Und dass es genau an dieser Stelle, genau an dieser Stelle, wo es Gutes schon gibt oder nicht gibt oder wo es Erweiterungen geben soll oder nicht geben soll, dass fast alle Diskussionen,

die ihr führt, genau anhand dieser Linie sind. Das, was lange im Projekt ist, wird nicht diskutiert. Das, was gar nicht im Projekt ist, wird auch nicht diskutiert. Aber das, was eventuell sein könnte, wird diskutiert. Es werden wenige Leute sagen, sie finden toll, was ihr tut. War das ja schon lange da. Das ist ja schon immer das, was Gott gegeben hat. Es werden wenige sehr weit in die Zukunft gucken.

Es werden alle genau an dieser Kante gucken, von dem, was passieren könnte. Und Request, die von außen kommen, sind immer nur ganz am Rande von dem, was ihr tut. Das, was wirklich Veränderungen bringt, das, was wirklich passiert, das kommt selten von außen. Das wird meist von innen getrieben.

Algorithmen wechseln, Programmiersprache wechseln, wechseln, wie Sachen gemanagt werden. Das passiert nicht von außen. Das kommt meistens von innen. Oder von ganz anderen Leuten.

Leute werden sehr, sehr, sehr, sehr aufgeregt über Sachen sein, die sie noch nicht tun können, von denen sie denken, dass sie sie tun können, können, sollen. Wenn ihr das Feature raus habt, dann suchen Sie sich das nächste, was Sie gerne haben wollen.

Für das, was ihr da gemacht habt, werdet ihr nie wieder was hören. Ihr werdet nur wieder was über das nächste hören, was noch nicht drin ist. Also Produktmanager? Projektmanager sind eigentlich Politiker. Genau, die sind ähnlich. Die treiben immer nach vorne ab. Ich habe eine eigene Meinung zu Projektmanagern.

Die sorgen dafür, dass Meeting-Räume gebucht sind und Kaffee gekocht wird. Und treiben Leute an, das ist halt deren Job. Genau, das ist das, was ich gerade gesagt habe. Wenn ihr ein Feature implementiert habt, werdet ihr nie wieder davon hören.

Und das wirklich Wichtigste ist, es gibt eine feine Linie zwischen vielen Features und Überladen. Und es ist wichtig in seinem Projekt darauf zu achten, dass man diese Linie nicht überschreitet. Dass man guckt, was man im Projekt haben will

und was man nicht im Projekt drin haben möchte. Menschen sind sehr visuell orientiert. Wenn ihr irgendwas vorführt, sei es als Video oder als Screencast oder als Ascii-Cinema,

Leute werden sich daran erinnern, was sie sehen und nicht an das erinnern, was sie sagen. Sie werden sich im schlimmsten Fall noch nicht mal an das erinnern, was sie gelesen haben. Das komme ich gleich noch zu. Visuelle Vorführungen oder Videos erzeugen einen viel stärkeren Eindruck,

als das, was gesagt oder geschrieben wird. Jede Änderung, die ihr in eurem Projekt macht, wird irgendwen ärgern. Es wird immer einen geben, wenn ihr ein größeres Projekt habt. Es wird immer einen geben,

der nicht damit einverstanden ist, dass sich Sachen ändern. Dass sie sich zum Guten ändern. Sie haben Workarounds gebaut, sie sind total zufrieden mit dem, was drin ist. Aber es wird sie ärgern, wenn dieser Workaround nicht mehr funktioniert, wenn es dann auf einmal richtig ist. Der gleiche Wechsel, der gleiche Change wird für einen eurer User

die Erfüllung sein. Die Frage ist, auf wen ihr euch stürzt. Negative Erlebnisse bleiben besser hängen als positive. Ich würde versuchen, auf das Positive zu gucken. Es ist nicht immer einfach.

Wenn Leute unbedingt ein Feature in der Software haben wollen, dann werden sie häufig sagen, oder manche werden sagen, das hat doch schon mal funktioniert. Ich mache jetzt einen Bug Report auf und sage, das hat schon mal funktioniert, ich möchte, dass es wieder funktioniert. Meistens gab es das Feature vorher noch gar nicht

und keiner hat sich darum gekümmert, ob es jemals existiert hat. Vielleicht denken Sie, dass das, was Sie als Feature haben wollen, man als defekt kategorisiert soll, weil es unbedingt in die Software gehört und es noch nicht drin ist, damit es ein Fehler ist, der behoben werden muss. Oder Sie hoffen,

dass die Kategorisierung als Bug dazu führt, dass es schneller implementiert wird. Sie könnten auch einfach im Bug Tracker sagen, das ist ein Enhancement, also eine Erweiterung. Machen Sie aber in der Regel nicht. Leider. Auf der anderen Seite gibt es Leute,

die haben sehr große Schwierigkeiten zu erklären, was sie eigentlich wollen und wie sie das in den Kontext eures Projektes stellen wollen. Es lohnt sich, diesen Leuten zuzuhören. Ihr macht das ja als Open Source nicht nur für euch, sondern eben für User. Und es ist sehr, sehr schwer, zwischen diesem User

und diesem User zu unterscheiden. Da hilft es, ein Team zu haben, mit dem man über sowas diskutieren kann. Hallo erstmal. Das ist das, was ich gerade gesagt habe. Das, was ihr aus dem Projekt raushaltet,

kann genauso wichtig sein, wie das, was ihr in einem Projekt erlaubt. Für Task Warrior haben wir gesagt, dass alles, was der Aufgabenverwaltung dienlich ist, in das Projekt reingehört. Und alles, was darüber hinaus ist, gehört nicht in das Projekt rein. Deswegen haben wir gesagt, man kann mit einem Export sich die Daten innerhalb von Task Warrior

als JSON ausgeben und wenn man irgendwas reinstricken möchte, was nicht direkt mit Aufgabenverwaltung zu tun hat, kann man diesen Export nehmen und mit diesem Export machen, was man möchte. Aber es ist ganz, ganz wichtig, diesen Kern, um den es in eurer Software geht, Unix-Philosophie, One Task, One Tool, diesen Kern möglichst klein zu halten und immer zu wissen, was ihr eigentlich machen wollt.

Gilt auch für andere Projekte, nicht gerade, nicht nur für Softwareprojekte. Es gibt Leute, die denken, dass sie schlau sind oder die sich gerne an dem Projekt beteiligen wollen und sagen, eigentlich könnte ja noch Feature A oder

Feature B oder Feature C in das Projekt, obwohl sie es gar nicht brauchen. Sie wollen sich damit einfach nur am Prozess beteiligen und sagen, dass ihnen die Software wichtig ist. Sie möchten die Features gar nicht drin haben. Sie wollen sie einfach nur zu Wort melden. Sie möchten einfach dabei sein.

Seid vorsichtig bei Feature Request von Leuten, die euer Programm gerade mal einen Tag oder zwei benutzt haben. Sie kennen vielleicht euer Programm oder euer Projekt noch gar nicht. Aber seid auch genauso vorsichtig bei Leuten, die euer Programm schon seit 20 Jahren benutzen. Sie kennen es vielleicht zu gut.

Ihr merkt an jeder Stelle, das ist immer eine Balance. Ich gehe mal davon aus, dass alle das gut meinen. Es ist immer eine Balance, festzustellen, was brauche ich wirklich? Was muss ich in meinem Projekt drin haben und was nicht? Kennt ihr das?

Wenn Leute auf euch zukommen und sagen, dass sie irgendwas wollen und gar nicht genau wissen, was sie wollen oder irgendwas machen wollen, weil sie denken, dass es sinnvoll wäre oder beispielsweise in Task Warrior einen Report wollen, der genau in einer bestimmten Form aus Task Warrior rausläuft, was genau dieser Report ist, den sie ihrem Arbeitgeber geben müssen. Für alle anderen User hat das keinen

Zweck. Für diesen einen User wäre das die Welt. Aber, ja, genau. Du sagst, es gibt alles Mögliche. Es gibt Leute,

die wissen nicht, wie sie es sagen sollen. Es gibt Leute, die viel sagen und einfach nichts weitergeben. Genau. Es ist schwierig. Nicht so einfach. Viele Leute sagen,

ich benutze keine Open Source Software, weil da irgendein Feature fehlt. Denken aber nicht darüber nach, dass sie keine zahlende Kunden sind, sondern dass sie Nutzer einer freien Software sind. Interessanterweise würden die gleichen Leute für Software zahlen und wenn das Feature fehlt, machen sie auch nichts.

Beschweren. Tun sie sich nur da oben, weil sie können. Ich kenne keinen, der bei Microsoft ein Feature Request eingereicht hat. Du? Nein, nein. Der Marc hat sich hinter dir gemeldet. Also bin ich nicht erfolgreich. Natürlich nicht. Dann bleibt es bei einem Versuch in der Regel. Genau.

Ja, also hier steckt so ein bisschen dahinter die Machensweise können. Weil wir hören. Weil wir auch User haben wollen. Das ist das, worum sich das Ganze schon dreht. Manche Leute denken,

dass ein Change ganz klein ist und dass er in das Projekt gehört. Denken gar nicht darüber nach, ob es Sinn macht, dass er in das Projekt gehört. Denken nur, weil er so klein ist, kann er ja irgendwie reinkommen. Das sind ja nur zwei Zeilen Quot, macht das doch eben. Dass das dann hinter maintained werden muss und über die Jahre hinaus auch gepflegt werden muss, getestet werden muss und eventuell beispielsweise dieser eine Report

für den einen User, für den einen Arbeitgeber, dass das dann weiterhin getestet werden muss, auch mit allen zukünftigen Versionen, das sehen Sie gar nicht.

Auch eine Sache, unsere Dokumentation ist ziemlich ausführlich. Leute kommen in den ERC Channel, der bei uns womit das wichtigste ist, und fragen Fragen, die sie einfach auf der Homepage finden könnten. Oder mit der Benutzung von Google. Das kennen Sie vielleicht auch aus dem persönlichen Leben.

In eurem Büro, wenn ihr im Büro sitzt, dass Leute lieber zu euch kommen, als irgendwie Dokumentation durchgucken. Und das ist so das übertragende Bild davon. ERC ist das Fragen im Büro, wenn man so will. Es ist nicht nur online. Also es war sogar so, dass ein User nicht mal versucht,

versucht das anzurufen. Okay. Ich sollte meine Buchnummer glaube ich auch aus dem Internet nehmen.

Du hast gerade gesagt, dass es für viele Leute in deutschen Unternehmen auch ein Problem ist, wenn sie Dokumentation vorgeworfen bekommen, die in Englisch ist. Ja, und selbst wenn Sie in der Stellenbeschreibung stehen hatten,

dass die Sachen in Englisch sind, dann wehren sie sich dagegen, Englische Dokumentation zu lesen. Ich hatte auch schon Leute, die hatten ein Problem mit einer Fehlermeldung auf dem Bildschirm, wo Printout auf Paper stand und nicht wussten, was zu tun ist. Das gibt es auch.

Ich wiederhole das mal eben. Also Dokumentation kann auch viel zu ausführlich sein. Wenn es mehrere 100 Seiten hat, dann guckt auch da keiner mehr rein. Das haben wir auch festgestellt, wenn es nur 2, 3, 4 Seiten sind. Und keine Dokumentation ist doof, was im Moment die Regel

ist, aber zu viel Dokumentation ist eben genauso doof. Also ich

wiederhole das fürs Video. Du sagst, dass es eher ein soziales Problem ist, dass Leute eher soziale Interaktionen wollen, als dass sie Sachen bei Google finden wollen. Ja, das glaube ich auch. Es ist auch kein Problem. Nur glaube ich nicht, dass es schwieriger ist,

soziale Interaktionen zu machen, sondern es ist leichter. Es ist leichter zu fragen, als selber nachzugucken. Das ist auch ein Aktivierungsproblem, wenn man so will. Du hattest? Ja.

Ja. Genau. Es ist eine gute Idee, da komme ich auch gleich noch drauf zu sprechen, es ist eine gute Idee, Tutorials zu haben, dass Leute schnell zum Erfolg kommen, weil Leute erfolgsorientiert sind.

Das ist richtig vieler gegeben, oder? Und dass die tiefer gehende Dokumentation an anderer Stelle darauf verweist und dann auch in der Tutorial gesagt wird, wenn man weitere Informationen möchte, kann man sie an dieser und jener Stelle finden. Dann kommt man auch an dieses 3000 Seiten Problem vorbei. Ich habe heute morgen Vortrag gehört von einer PostgreSQL Entwicklerin, die sagte, sie haben versucht,

die Akte des Handbuchs zu übersetzen und haben da 3000 Seiten aufgegeben. Ja, wenn es zu viel wird, wird es zu viel. Muss man mal ganz klar sagen. So viele Seiten Dokumentation haben wir nicht. Noch nicht. Etwas, was sich bewegt,

wird angeguckt und sofort verstanden. Ein Textabschnitt wird einfach ignoriert. Das ist eigentlich genau die Zusammenfassung dessen, was wir gerade gesagt haben. Wir haben gemerkt, dass auch gerade Manpages, die schon länger Unix machen, einfach gewohnt sind, dass wir da Informationen raussuchen, dass es für viele

heutzutage, dass es ein Aufmerksamkeitsproblem ist, zu schwierig ist, längere Texte aufzunehmen und durchzulesen. Das merken wir immer wieder. Das Beste, was man machen kann, um Zeitverspender zu identifizieren, ist zu fragen, was hast du denn schon ausprobiert?

Wie bist du mit diesem Problem bis jetzt umgegangen? Und da wird es sehr, sehr schnell und sehr, sehr still. Wir haben gemerkt, dass viele Leute, die also ich muss vielleicht ein bisschen weiter ausholen. Taskwary hat sehr viel

Atlassian Software benutzt. Jira als Bug-Tracker immer noch. Das Question Ansatz, ich weiß gar nicht, wie das genauer heißt. Und so weiter. Viele Leute haben sich darüber aufgeregt, dass wir diese Software benutzen. Haben sich um das Drumme rum gekümmert und

nicht um die Software selber gekümmert. Interessiert. Ich weiß gar nicht, wie ich das sagen soll. Ich weiß gar nicht, warum es da Diskussionen darüber gibt. Wenn man sich darüber unterhält, dann ist es doch okay. Wenn man sich darüber unterhält,

dann gibt es mir als User ein paar Garantien. Das heißt, wenn da die Minor Version sich ändert, dann kommen gleich die Features dazu, aber das Ding bleibt im Großen und Ganzen das Gleiche. Ich erinnere,

dass ich irgendwo die Patch Version geändert habe und das Ding war, naja, für mich kaputt. Ja, genau. Also ich hätte nochmal den Hinweis, bei Versions damals ist es vielleicht wichtig, dass sich die Projekte an Semantic Versioning halten. Das heißt, dass sie einen Major New Releases an der Version vor dem Punkt festmachen. Feature Releases an der Version nach dem Punkt und Hotfixes

und, na, also Fixes an der dritten Stelle, ja, finde ich auch. Aber wann es eine neue Version gibt, das ist immer noch die große Frage, genau. Das kann ich mir sehr gut... Also wer Distributionspakete baut, streitet sich sehr, sehr häufig über Versionsnummern, was ich sehr gut nachvollziehen kann.

Da hinten war gerade noch eine Hand.

... ... ... ... ... Ja, genau. Also der Kommentar gerade war, dass das sowas in sehr vielen Projekten passiert und dass man auch Schwierigkeiten hat

zu erklären, warum es zur Entscheidung gekommen ist und dass manche Sachen einfach historisch bedingt sind und da aus der Historie heraus auch begründet werden können. Ist ungefähr so richtig? ...

... Mark, hast du mal nachgefragt, warum die Versionsnummern bei Microsoft so sind, wie sie sind? Als Experte was Anfragen bei Microsoft angeht.

der Kommentar war und da muss ich Recht geben, dass bei Open-Source-Projekten viele Leute denken, dass alles offen ist und damit man auch alles in Frage stellen kann und alles diskutieren kann. Und weil es halt offen ist, kann jeder an allen Entscheidungen mitmachen. und bei Closed-Source-Projekten traut sich keiner nachzufragen, plus minus.

Gut, wir haben vor Jahren auf die MIT-Lizenz umgestellt, die zu den zwei offensten Lizenzen im Free- und Open-Source-Bereich ist.

Keine Copy-Left-Lizenz und Leute haben sich darüber aufgeregt. Das sollte doch eine Copy-Left-Lizenz sein. Aber ich denke, das sollte man dem Projekt überlassen. Es ist Open-Source-Software und Free-Software, die man benutzen kann, und jeder kann damit machen, was er möchte. Zur GPL habe ich eine eigene Meinung. Dann können wir mal beim Kaffee oder beim Bier diskutieren.

Je nachdem, von welchem Blickpunkt man auf die GPL draufguckt, kann die GPL auch eine Einschränkung sein in der Nutzung. Das widerspricht ein bisschen von Free-Software,

aber da können wir gerne diskutieren. Das ist glaube ich ein länger Diskurs. Das ist eine philosophische Frage letzten Endes. Ich kann mir beiden gut lesen. Was wir auch gelernt haben, ist, dass SEO-Consultants nicht so gut darin sind, das Web zu durchsuchen. Sonst würden sie nämlich merken, dass die Anfragen, die sie stellen, an Open-Source-Projekte gehen und es keine Company dahinter steckt.

Da sieht man einfach nur, dass sie ihr eigenes Business nicht verstanden haben. Kleine Anekdote dazu. Ich habe in meinem Xing- und in meinem LinkedIn-Profil drinstehen, dass ich keinen neuen Job suche.

Ja, ich habe da einen Account. Hab dann den Satz drunter geschrieben. Liebe Leute, liebe Hetterhunter, ich weiß, dass das mittlerweile ein Massengeschäft ist, aber ganz ehrlich, dass ihr mein Profil lest, erhöht mein Vertrauen in euch,

dass ihr den passenden Job für mich findet. Die meisten suchen nur Buzzwords, finden dann irgendwelche Profilideen, die darauf passen und gucken nicht weiter. Ja, genau. Aber meistens hat es auch nur einen Kommentar gebrautet, habe ich in meinem Profil die Zusammenfassung gelesen und dann habe ich eine Entschuldigung.

Nein, habe ich nicht. Marc sagt gerade, dass er Netzwerker ist und mit Cisco IOS arbeitet, was unglücklicherweise genauso heißt

wie das Betriebssystem eines angebissenen Apfels. Man kann sich noch nicht mal darüber streiten, was vorher war. Cisco hat Apple die Erlaubnis gegeben, ein eigenes Betriebssystem so zu nennen. Das ist vielleicht der Fehler,

genau, vielleicht muss man es so sagen. Oder ich weiß nicht, wie viel Geld da geflossen ist. No one ever stimmt, stand heute immer noch. Hat sich jeder darüber beschwert, welcher Algorithmus benutzt wird?

Ja.

Das war zu schwer zu verstehen. Eher die zentrale Nukleär. Und dann hat man sehr viel Zeit diskutiert über welch Farbe das wie sagt man Fahrrad?

Ja. Die Fahrradvertrohung ist auch wie genannt. Welche Farbe das haben sollte. Ja, genau. Ich gebe es mal wieder. Es ist einfach so, weil das schwer ist und weil Leute dazu indizieren, sich nur bei leichten Sachen zu Wort zu melden. Zum Beispiel hat man bei Nukleäranlagen dazu, als es große Diskussionen über die Sicherheit

von Nukleäranlagen gab, hat man mehr darüber diskutiert, welche Farbe das Fahrrad haben soll, als darüber, wie Nukleäranlagen sicher gemacht werden sollen. Es gibt einen Gesetzabwumpf dafür, das heißt Parkinsonches Gesetz. Das könnt ihr gerne mal googeln. Das sagt so viel wie, dass in Meetings die Sachen am meisten bestrochen werden, wovon die meisten Leute Ahnung haben. Das ist meistens Farbe von Fahrrädern und nicht über das, was eigentlich

Thema des Meetings sein sollte. Das ist in dem Moment unsere Fahrradfarbe. Task Warrior ist

in C++ geschrieben unter Taps to Spaces und Spaces to Taps, da wurde mehr darüber diskutiert als darüber. Das geht ja gar nicht. Es wurde nicht über den Code diskutiert, sondern über die Lücken zwischen dem Code, wenn man so will.

Viele Leute wollen sich zu Wort melden, auch wenn sie keine Ahnung haben, die Leute, die Code verstehen, es ist eigentlich egal, Hauptsache, dass es einigermaßen strukturell vernünftig ist.

Wolltest du noch was sagen? Donning Kruger Effekt, das geht genau in die Richtung. Auch ein sehr, sehr guter. Das könnte ich hinterher noch in die Folien hängen. Parken in sonstiges Gesetz, Donning Kruger Effekt. Für uns ist natürlich wie für jedes andere Projekt wichtig,

das zu priorisieren, was ist wirklich wichtig, worüber diskutieren wir wirklich. Es gab einen üblen Hack, der Codepages angeht. Dieser üble Hack läuft noch immer und keiner hat sich darüber beschwert. Das hat noch nicht mal irgendwer wahrgenommen.

Und manchmal ist genau so was, das in dem Moment richtig ist. Also Provisorien, das heißt, es ist nicht ohne Grund. Jetzt kommen wir zu dem Tutorial, über das wir gerade gesprochen haben.

Wir haben ein sehr langes Tutorial gehabt, was wirklich in vernünftige Abschnitte geteilt war, wo man sehr schnell zum Erfolg kam. Wir hatten ein 3-Minute-Tutorial und ein 10-Minute-Tutorial, dass man mit dem 3-Minute-Tutorial die ersten Aufgaben machen oder lösen kann, dass man das Ganze benutzen kann. Und ein 10-Minute-Tutorial oder ein 30-Minute-Tutorial, wo man tiefer einsteigen konnte. Das 30-Minute-Tutorial,

das ließ man aber, ist gut geschenkt. Aber es gibt... Wir hatten einen kleinen Gimmick eingebaut am Ende, nämlich eine mexikanische Band, die Furzgeräusche mit den Händen gemacht haben und darüber ein Lied gespielt haben. Das hat nie jemand gesehen.

Wir haben in der allerletzten Zeile der Seite ein Codewort versteckt und haben gesagt, wenn jemand das Codewort sagt, dann wird er priorisiert behandelt. Von 100 Anfragen haben es zwei benutzt. Botschaft, kurze Tutorials.

Je kürzer, je besser. Ja, hier. Also auf Events zu sein ist wichtig, um das Projekt sichtbar zu machen. Das merken wir hier. Mit euch im Dialog zu sein ist wichtig. Ihr gebt Feedback und das bauen wir wieder ein. Ihr lernt uns kennen, wisst, dass wir auch hoffentlich normale Menschen sind.

Du nicht, genau. Genauso ist es wichtig, dass man ab und zu mal so einen Vortrag einreicht und über das Projekt spricht, damit das andere Leute wissen. Direkt vor mir war ein Vortrag über Wuthof. Das ist ein Open-Source-Business-Netzwerk. Das lohnt auf jeden Fall einen Blick. Das könnt ihr euch mal angucken. Und es ist wichtig,

dass so etwas als Open-Source-Events besprochen wird. Wir haben uns im Februar zum allerersten Mal im Real Life getroffen auf der FOSDEM in Brüssel. Wir haben vorher noch nie alle zusammen an einem Tisch gesessen. Es ist eine ganz interessante Erfahrung,

die Leute hinter den Mails zu sehen. Paul, der Gründer des Projektes, sagte, dass er einige Mails besser versteht, die ich geschrieben habe. Weil auch meine Art von Humor oder Ironie besser versteht.

Es fehlt einfach Sprachkommunikation, weil man in Sprache viel mehr transportiert, auch Emotionen zum Beispiel, als man in Mailingnistenposts schreibt. Das sehe ich ganz genau. Selbst wenn das nicht die eigene Muttersprache ist, funktioniert das in der Sprache deutlich besser.

Entschuldigung. Also Bier löst viele IT-Probleme. Da muss ich sagen, das ist eine Literfrage.

Ich muss den Satz wiederholen, damit er für die Ewigkeit erhalten bleibt. Frikadellen und Bier machen die beste Software. Das würde ich so unterschreiben.

Genau. Frikadellen und Bier müssen auf dem Tisch sitzen. Wer mag auch gerne eine Flasche Wein. Das geht dann schneller, da muss man nicht so viele Liter trinken. Wir haben gemerkt, dass es schon interessant ist, dass sich da die gleichen komischen Menschen getroffen haben

im gleichen Projekt. Wenn man allerdings merkt, dass man nicht so den gleichen Sinn für Humor hat, sollte man sehr, sehr vorsichtig mit ironischen Mails mit ironischem Unterton sein. Das geht für jede E-Mail-Kommunikation, nicht nur im Open-Source-Projekt. Also wenn ihr beruflich E-Mails schreiben müsst, spart euch Ironie, bitte.

Also Ironie funktioniert in Schriftform definitiv nicht. Also Spiegel Online und Peter Lustig funktioniert nicht, gebe ich dir völlig recht. Das funktioniert gar nicht. Da kann man auch so gut in Deutschland sein, wie man will. Das funktioniert wirklich nicht. Oder nur in Ausnahmefällen.

Also die Frage war, ob es in Open-Source-Projekten, damit sind hier alle Teilnehmer gefragt, Sprachkommunikation

Einzug gehalten hat, oder nur Mailing-Listen. Der Kommentar hier

war, dass im CMS-Garden bemerkt wurde, dass Mailing-Listen die jetzt hier gar nichts bringen, sondern dass man sich besser an einen Tisch setzt und sagt, in 5 Minuten durchspricht, die sonst Tage dauernd per Mail. Gilt übrigens auch für die Arbeit. Lieber mal telefonieren als nur Mail schicken, ganz am Rande. Also das Kommunikationsmittel zur richtigen Zeit wählen. Hier vorne war noch eine Wortmeldung von dir.

Also hier gibt es einen T-Shirt-Sprung, da steht drauf Never Code Alone und die Aussage

ist, dass man in Sprints sehr, sehr schnell merkt, dass wenn man zusammen codet, dass man eine Menge mehr zusammenbekommt. Deswegen machen auch viele Projekte Hackathon, wo sie sich einfach treffen und an einem Thema arbeiten, um das schnell vom Tisch zu bekommen.

Gebe dir völlig recht, aber das ist beim Hobbyprojekt was anderes, als wenn ich 8 Stunden am Arbeitsplatz erreichbar bin. Also der Einwand war, dass man vor dem Hintergrund dessen, dass direkte Kommunikation einfacher ist, gerade per Sprache, dass der Anruf vielleicht dann doch besser ist, als der Eintrag im E-Shirt-Tracker.

Erklärt man dir die 28.

Mal diese bestimmte Arbeitsgänge zu machen, wenn man sowas bei T-Mails abbehalten kann? Man braucht eine halbe Stunde, wegen einer kurzen Antwort zu bringen. Das ist schon auch was. Ja, ich wiederhole kurz. Im Büro ist es zum Teil so, dass

sehr viele Anrufe kommen und sehr viele Sachen kommen und wenn man das nur mit Telefonieren abarbeiten würde, würde man aus dem Telefonieren nicht mehr rauskommen. Deswegen macht es da auch Sinn, Arbeit durch Tickets zu strukturieren und auch Tickets abzuarbeiten. Ich finde es immer gut, wenn es einen Ansprechpartner gibt, der per Telefon erreichbar ist. Aus dem Team, nicht das gesamte Team.

Ein ganz großer Punkt ist, wenn man

in einem internationalen Projekt ist, dann haben die Leute, die als Muttersprache Englisch haben, einen großen Vorteil gegenüber denen, die das nicht als Muttersprache haben. Und es ist für viele Leute leichter, sich in Englisch schriftlich auszudrücken, als sich in Englisch per Sprache auszudrücken. Da gebe ich dir völlig recht, da muss man aufpassen. Ich mache mal weiter, das sind nur ein paar Sachen.

Das, was jeder merken sollte, was wir natürlich auch gemerkt haben, dass unsere eigene Maschine nicht ein Maß dafür ist, was die User benutzen. Das ist eigentlich eine Binsenweisheit, muss man sich aber immer mal wieder vor Augen führen. Der hat sowieso nur einen Desktop und keinen Server. Gerade was Abhängigkeiten angeht, merken wir doch sehr, sehr stark, dass

viele Leute sehr weit von den Abhängigkeiten im Fernsehen, die wir gerne nutzen würden. Aber das ist glaube ich auch normal so. Es ist wertvoll, sich auf jede Kommunikation einzulassen, weil es kommt aus jedem immer was Vernünftiges raus. Also selten irgendwie was Unvernünftiges. Das konterkariert ein bisschen

das, was ich vorher gesagt habe. Aber man kann mit Leuten ins Gespräch kommen, man kann auch, indem man sinnvoll auf Leute eingeht, die dazu bewegen, dass sie auch sinnvolles Feedback geben. Das geht. Es ist nur sehr aufwendig. Es ist schön, wenn man ein Logo hat, das wiedererkennbar ist.

Wir können nur raten, dass jeder sein Logo, wenn man kein Designer ist, das Logo nicht selber macht, aber wenn man nicht das Geld hat und keinen Designer an der Hand hat, sollte man sich einen Designer suchen, der das zumindest beurteilt, was man gemacht hat. So als Idee. Das hat einen Grund, dass das ein eigenständiger Beruf ist. Wirklich.

Und auch den Hobby Admin-Size gesagt, das hat einen Grund, warum es professionelle Admin-Size gibt. Aber das ist auch ein guter Job. Es ist toll, wenn man Sticker hat. Also wenn die Task Warrior Sticker wollte, ich habe welche da. Es ist noch schöner, wenn man noch mehr hat. Also sowas wie T-Shirts. Es gibt in

Osteuropa eine Firma, die heißt Hello Tux, die macht auch T-Shirts mit Task Warrior Aufdruck. Also wenn ihr das wollt, wir kriegen was von denen zurück, wenn ihr dann ein T-Shirt bestellt. Müsst ihr natürlich nicht, aber es ist schön, dass wir das im Angebot haben können.

Viele Leute wollen Veränderung, aber keiner will daran mitarbeiten. Ich weiß nicht, ob dir diese Karikatur geht. Wer möchte Change haben? Alle Hände gehen hoch. Wer möchte den Wechsel durchführen? Wer möchte die Veränderung durchführen? Alle Hände bleiben unten. Das ist genau in dem Tonus gemeint. Was wir

sehr wichtig erachten, ist, dass man in seinem Projekt eine Seite hat, wo drin steht, was man mit dem Projekt eigentlich vorhat. Und auf die kann man die Leute verweisen und sagen, das passt nicht in unsere Philosophie. Das, was du da hast, ist ein schöner Feature Request, aber baue das als Extension oder so, das passt in das eigentliche Projekt nicht rein. Das sollte meiner Meinung nach jedes Projekt haben.

Wir haben auch sehr viele Projekte. Und wenn es mal richtig scheiße läuft, tief Luft holen und zurückgucken, was schon erreicht wurde, und nicht auf das gucken, was schlecht läuft. Es lohnt sich einfach auch mal zu gucken, dass es Sachen gibt, die gut laufen.

Auch für die eigene Hygiene. Also es lohnt sich schon zu sagen, man hat ein erfolgreiches Open Source Projekt, oder man startet ein hoffentlich erfolgreiches Open Source Projekt und man findet darin auch so ein bisschen Hobby, ein bisschen Bestätigung, kann auch ein bisschen bei abspannen. Und manchmal ist es wichtig, zurück zu gucken und nicht auf das zu gucken, was schief läuft. Weil gerade von innen sieht

man eigentlich nur das, was schief läuft, weil man schlechte Sachen viel, viel leichter sieht als gut laufende Sachen. So wie das Hamsterrad, genau, man sieht nur die Leiter vor sich. Genau. Natürlich keine Leiter. Ja, habt ihr noch Fragen? Sie haben gesagt,

dass wenn jemand eine Handflutreffnung hat, war das wieder. Eine Verbesserung fragt, dass das immer etwas neu benützt wird, um sehen zu lassen.

Und das haben Sie die Technik? Man merkt das sehr, sehr schnell, wenn man Leute fragt, die eine Verbesserung

wollten, und wenn man die implementiert hat, und sie hinterfragt, wie sie denn mit der Implementierung zurechtkommen, und sie sagen, ich habe es mir noch gar nicht angeguckt. Dann merkt man sehr, sehr schnell, dass sie das eigentlich gar nicht wollten. Ich finde es immer gut, bei Feature-Requests, also wir haben so einen Bug-Tracker, wo auch Enhancement-Requests reinkommen, ich finde es immer gut, nochmal nachzufragen, ob es so ist, wie es sein sollte.

Aber es ist tatsächlich mittlerweile so, ich möchte nicht sagen, dass wir Feature-Complit sind, aber es ist so, dass wir sehr, sehr viel schon drin haben, und dass wir über diese Philosophie-Seite sehr viele Leute tatsächlich dazu bringen können, um nochmal darüber nachzudenken.

Das ist sehr, sehr schwierig mit Feature-Requests, wenn kein Reaktionsprojekt kommt, das kann ich unterstützen, wir sind ein relativ kleines

Projekt mit wenig Leuten, und wir machen das alles in unserer Freizeit, da bleibt halt manchmal, ich gebe aber völlig recht, das ist schwierig, ja natürlich. Derjenige, der ein Feature-Request hatte, möchte eigentlich sofort eine Rückmeldung haben. Ja, das ist richtig. Sonst noch Fragen? Ja, Dankeschön.

Ich wünsche euch einen schönen Tag.