#04 Lohnt der Einstieg in Open Source?

Für Andy ist Open Source und die Open Source Community ist bereits ein langer und essentieller Begleiter. In dieser Episode interviewed Wolfgang Andy genau zu dieseme Thema: Wie war sein Einsteig? Wieso es wichtig ist, sich Zeit zu nehmen um ein Bug-Ticket zu schreiben und was Snowboarden mit Open Source zu tun hat.

Bonus: Wie man Andy dazu bringt, nackig durch die Wohnung zu flitzen.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Andy (https://twitter.com/andygrunwald) und Wolfgang (https://twitter.com/schafele) sprechen im Detail über:

Sprungmarken

(2:04) Wann hast du mit Open Source begonnen und warum?

(03:27) Wie würdest du denn Open Source definieren?

(05:08) Warum bist du in der Open Source Szene geblieben?

(06:45) Hattest du mal schlechte Erlebnisse bei oder mit Open Source? als Maintainer?

(07:33) ... und als Contributor?

(08:15) Welche Tips kannst du Contributoren geben, um die Erfolgschancen für Pull Requests zu erhöhen?

(10:04) Hast du Best Practices aus Maintainer-Seite, wie man mit Contributoren umgeht?

(12:12) Wie geht man mit eigenen Open Source Projekten um, die man selbst nicht mehr nutzt?

(15:31) Wie gehst du mit Feature Requests um?

(17:56) Hat dir bereits jemand ein Feature gesponsored?

(19:14) Open Source wird als Free work verstanden

(20:45) Tipps für einen Feature Request bei einem Projekt

(21:49) Kommunikation ist sehr wichtig

(22:36) Wie siehst du den Stellenwert von Open Source im professionellem Umfeld?

(24:35) Open Source als Mittel fürs Recruiting

(25:40) Wie kann sich eine kleine Firma im Open Source Bereich engagieren?

(28:09) Was hälst du von dem Open Source First Konzept?

(29:29) Was ist Inner Source?

(30:40) Passwörter und Secrets im Code

(32:12) Möglichkeiten um ein Repository zu Open Sourcen

(32:38) Negative Punkte für den Einsatz von Open Source

(36:55) Welche Open Source Lizenz würdest du empfehlen, wenn jemand mit einem neuen Projekt starten möchte?

(39:29) Projekte auf GitHub ohne Lizenz

(40:35) Beer- und Pizza-Lizenz

(41:02) Kleine Sponsoring-Beiträge und Danke-Nachrichten können viel bewirken

(45:13) Andy flitzt nackig durch die Wohnung

(48:15) Was deine Open Source Contribution mit deinem professionellen Werdegang zu tun hat

Erwähnte Artikel

"Choose an open source license" von GitHub: https://choosealicense.com/
"Scaling from 2,000 to 25,000 engineers on GitHub at Microsoft" von Jeff Wilcox: https://www.jeff.wilcox.name/2019/06/scaling-25k/
"Für 50 Prozent der Entwickler ist Open Source ein 9-to-5-Job": https://www.techrepublic.com/article/for-50-percent-of-developers-open-source-is-a-9-to-5-job/
"BMW *are* complying with the GPL" von Terence Eden: https://shkspr.mobi/blog/2016/03/bmw-are-complying-with-the-gpl/

Engineering Kiosk Podcast

Anfragen an stehtisch@engineeringkiosk.dev

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:02 - 00:01:06)

Willkommen im Engineering Kiosk. Heute haben wir im Angebot eine neue Episode zum Thema Open Source. Und Andi ist ja der absolute Open Source Profi und darum werde ich ihn ausquetschen, warum Firmen unbedingt auf Open Source setzen sollen. Und ganz spannend, wir werden auch lernen, warum Andi auf einer Hochzeit nackt durch die Wohnung rennt, nur wegen Open Source. Also starten wir los. Eine neue Episode im Engineering Kiosk. Aktuell scheint die Sonne, es ist noch relativ früh, wir können noch kein Bier trinken, aber immerhin Biomate, ah, Miomate. Miomate steht vor uns, hat der Andi gesponsert. Und heute wollen wir mal sprechen über Open Source. Genau. Der Andi kennt sich da sehr gut aus. Der ist meiner Meinung nach in meinem Bekanntenkreis der, der am meisten Open Source macht und am tiefsten drin ist. Er hat auch ein großes Side Project. Wir haben letztes Mal über Side Projects gesprochen. Was machst du in deinem Side Project? In zwei Sätzen erklärt.

Andy Grunwald (00:01:06 - 00:01:31)

Das Projekt heißt Source Control und es geht um generell Software Repository Mining. Das ist die Analyse von Metadaten, die während eines Software-Erstellungsprozesses entstehen. Ganz praktisch Git-Logs, Git-Clone-Traffic etc. Mit dem Ziel, mehr aus deinem Open-Source-Projekt herauszuholen und das ungenutzte Potenzial zu nutzen, es aber auch Contributor-freundlicher zu machen und Co.

Wolfi Gassler (00:01:31 - 00:01:39)

Bingo, würde ich sagen. Gehen wir mal ein bisschen zurück in der Zeit. Wann hast du denn mit Open Source begonnen überhaupt und warum?

Andy Grunwald (00:01:39 - 00:02:38)

Warum? Warum ist gerecht einfach. Und zwar habe ich eine Ausbildung gemacht, Fachinformatiker, Fachrichtung Anwendungsentwicklung in einer Webagentur. Diese Webagentur war spezialisiert auf Umsetzung von Extranetz und Intranetz mit dem Content Management System TYPO3, TYPO3. PHP Content Management System, Achtung PHP Enterprise. Content Management System, das wollen wir nicht unterschlagen. Und die Firma WMDB war sehr stark mit der Community verwurzelt, war einer der Early Adopter in der Typo3 Community. Und weil wir das System viel eingesetzt haben, bin ich irgendwann auch durch meine Arbeit da reingerutscht. Auch wir mussten mal ein Bug da fixen, hab dann mal ein Pull Request gemacht. Heißt nicht Pull Request da, sondern Change Set und Patch Set, weil das mit Gerrit arbeitet und nicht mit GitHub. Und so ist man da reingerutscht und irgendwann bin ich mit zur Typo 3 Snowboard Tour gefahren, das ist ein jährliches Event wo sich die Typo 3 Community entweder in Deutschland, Frankreich, Österreich, Schweiz trifft, eine Woche snowboarden, 100 Nerds zusammen.

Wolfi Gassler (00:02:38 - 00:02:39)

Ich hoffe das war in Österreich.

Andy Grunwald (00:02:39 - 00:02:42)

Das war auch mal in Österreich, das ist richtig.

Wolfi Gassler (00:02:42 - 00:02:43)

Das war das beste wahrscheinlich.

Andy Grunwald (00:02:43 - 00:02:45)

War auf jeden Fall günstiger als die Schweizer Touren.

Wolfi Gassler (00:02:46 - 00:02:47)

Verständlich.

Andy Grunwald (00:02:47 - 00:02:53)

Und so lernt man dann das Core-Team kennen und dann geht man mit auf die Konferenzen und so weiter und so bin ich dann in den ganzen Sumpf da gerutscht.

Wolfi Gassler (00:02:53 - 00:02:55)

Und das war von Anfang an Open Source Typo 3.

Andy Grunwald (00:02:55 - 00:02:58)

Typo 3 war meines Wissens nach von Anfang an Open Source.

Wolfi Gassler (00:02:58 - 00:03:01)

Wie würdest du den Open Source definieren, ganz abgesehen davon?

Andy Grunwald (00:03:01 - 00:03:05)

Ich glaube, es gibt von der Open Source Foundation, ich glaube, es gibt eine offizielle Definition.

Wolfi Gassler (00:03:05 - 00:03:08)

Wir sind super vorbereitet, ja.

Andy Grunwald (00:03:08 - 00:03:55)

Wie ich es, Open Source, Quelloffener Source Code, Quelloffener Text. Das heißt nicht, dass es umsonst ist. Das heißt, dass du den Quelltext von Programmen erstmal einsehen kannst. Wenn wir über Software reden, es gibt auch Open-Source-Rezepte, es gibt auch Open-Source-Bier, Open-Source-Cola, Open-Source-Pizza, es gibt Open-Source-Hardware, es gibt sogar Open-Source-Server-Racks. Also wenn wir uns jetzt auf Software beschränken, würde ich sagen, quelloffen, dass du den Quelltext nachverfolgen kannst und unter einer sogenannten Open-Source-Lizenz steht, also es gibt eine Liste von Approved Open-Source-Lizenzen, sehr populär im JavaScript-Bereich, die MIT-Lizenz, Apache-Lizenz, BSD-Lizenz, Copy-Left, Copy-Right.

Wolfi Gassler (00:03:55 - 00:04:08)

Etc. Für mich jetzt als, wenn man nicht genau auf die Lizenzen einen Blick wirft, dann ist für mich eigentlich immer Open Source oder das Key Element von Open Source ist, dass du dich beteiligen kannst an dem Ganzen.

Andy Grunwald (00:04:08 - 00:04:41)

Das würde ich nicht so ganz unterschreiben. Es gibt Projekte, bei den meisten Projekten kannst du dich beteiligen. Beteiligen, ein Issue aufmachen ist auch Beteiligung, ein Issue beantworten ist auch Beteiligung. Oder halt wirklich eine Code-Contribution, eine Design-Contribution. Es gibt aber auch Open-Source-Projekte, die werden aktiv so betrieben, dass der Code rausgepusht wird, dass jeder ihn lesen und nutzen kann. Es werden aber keine Pull-Requests akzeptiert und keine Isch. Das ist auch Open-Source. Hat natürlich verschiedene Gründe, warum das so gemacht wird. Kommen wir vielleicht später zu.

Wolfi Gassler (00:04:41 - 00:05:02)

Jetzt wenn du, wie du damals mit Typo 3 angefangen hast, warum bist du dann in der Open Source Szene geblieben oder was war das coole an Open Source oder auch heute noch? Siehst du da irgendwie irgendwas Sinnvolles dahinter? Du hättest ja auch sagen können, oh Gott, ein schreckliches Erlebnis da mit Typo 3 in der Open Source Szene zu arbeiten und nie wieder Open Source.

Andy Grunwald (00:05:02 - 00:06:22)

Wie bin ich da reingerutscht? Ich habe, glaube ich, damals irgendwann einen Bug gefixt in dem Content-Management-System und es war einfach ein mega Gefühl, dass irgendwann in den Release-Notes zur nächsten Version dein Name steht. Du hast einen Fehler behoben in einer Software, die von Millionen von Benutzern und von Anwendern und von Entwicklern genutzt wird und da steht Danke an Andi Grunwald für den Fix für das Input-Formular zur Datumseingabe oder ähnliches. Wahnsinn. Das gibt natürlich einen Motivationsschub. Wenn man da mal weitermacht und kontinuierlich zu einem Projekt kontributet, dann fällt dein Name halt öfters mal auf und du wirst kontaktiert von den Core-Maintainern, von Leuten in der Community, die aktiver sind. Und so rutscht man da rein und auf einmal lernt man Leute kennen, man quatscht mit den Leuten und die helfen dir auch mal, vielleicht einen größeren Bug zu fixen oder mal ein gutes Feature zu implementieren. Aber das sind sehr, sehr nette Menschen und dann merkt man auf einmal, hier kann ich eine ganze Menge lernen. Und das war so mein Hauptantrieb. Ich habe unglaublich talentierte, unglaublich nette, lernende Menschen kennengelernt und ich habe unglaublich viel gelernt. Und das war so mein Einstieg. Und ich muss zugeben, nach weit über zehn Jahren in der Open-Source-Szene, und Open-Source-Szene meine ich nicht einmal im Jahr ein Pull-Request senden, ich bin wirklich aktiv, das hat bisher nicht aufgehört. Und das fasziniert mich immer noch.

Wolfi Gassler (00:06:23 - 00:06:26)

Hattest du mal schlechte Erlebnisse?

Andy Grunwald (00:06:26 - 00:07:04)

Ja, eindeutig. Und zwar, wenn ein Open-Source-Projekt von dir etwas populärer wird und du sehr viele Bug-Tickets bekommst oder Feature-Requests, dann findest du das am Anfang toll. Du investierst sehr viel Freizeit da rein, fixst diese Bugs, enablest die Features. Und irgendwann fragst du dich, warum machst du das denn hier alles? Weil irgendwie kontribuierst du zwar zu Open Source, aber du fixst Sachen für andere Leute for free. Und andere Leute machen damit sehr wahrscheinlich mehrere tausend Euro, Millionen, was weiß ich nicht. Und umso mehr Issues reinkommen, umso größer wird auch der Druck, dass du dem gerecht werden möchtest.

Wolfi Gassler (00:07:05 - 00:07:11)

Aber du sprichst jetzt davon, wenn ein Projekt, das du maintainst und wo du wirklich der Besitzer bist.

Andy Grunwald (00:07:11 - 00:07:14)

Das ist jetzt eine Erfahrung, die ich gemacht habe.

Wolfi Gassler (00:07:14 - 00:07:29)

Ja, als Contributor, wenn du auf der anderen Seite sitzt oder wenn du auch an den jüngeren Andi zurückdenkst, hat es da irgendwann mal gegeben, wo du irgendwie contributen wolltest und es gab Probleme oder wo du irgendwie, das dann eher demotivierend war am Ende des Tages?

Andy Grunwald (00:07:30 - 00:07:56)

Ja, natürlich. Wenn ich einen Pull-Request gemacht habe, eine Änderung vorgeschlagen habe, die einfach nicht akzeptiert wurde, die entweder gar nicht erst angeguckt wurde, gereviewt wurde, weil die Maintainer vielleicht keine Zeit hatten oder aus welchen Gründen auch immer. Sie war da und ist verstaubt. Das ist sehr demotivierend, weil du hast ja schon Arbeit reingesteckt. Oder wenn sich dir jemand deinen Change angenommen hat und ihn abgelehnt hat, weil er aus irgendwelchen Gründen nicht passt, nicht zur Strategie passt oder einfach nur falsch implementiert wurde.

Wolfi Gassler (00:07:57 - 00:08:16)

Also wenn du jetzt von der Contributor-Seite kommst, hättest du irgendwelche Tipps oder wie gehst du dann an solche Probleme dran, damit eben das möglichst wenig passiert am Ende, dass es abgelehnt wird oder dass du Probleme hast, wenn du dann irgendwas contributest? Gibt es da irgendwelche Möglichkeiten, um das zu verhindern?

Andy Grunwald (00:08:16 - 00:09:48)

Ja, es kommt immer ganz drauf an, in welchem Stadium du als Configurator bist. Nehmen wir folgendes Szenario an, du hast ein neues Projekt, du weißt, wie du programmierst, du kennst das Projekt aber noch nicht und du willst entweder einen Bug fixen oder ein Feature reinbringen. Das erste, was ich wirklich jedem empfehlen würde, ist ein Issue aufmachen, deinen Use Case beschreiben, dann dein Expected Behavior, wenn das jetzt zum Beispiel ein Bug ist, oder das Feature, was du haben möchtest, und dann einfach mal beschreiben, wie du das implementieren würdest. Einfach in menschlichen Worten, ohne viel Code. Und darunter einfach die Frage stellen, hey, ich würde gerne mal ein bisschen Feedback haben, bevor ich hier Apple reinstecke, würdet ihr sowas annehmen und wäre das der richtige Weg, das zu implementieren. Und dann einfach mal das Issue, das ist das Ticket, im Bug-Tracker absenden und einfach mal auf Feedback warten, bevor man Tage, Wochen in das Feature einstellt. Wenn man kein Feedback kriegt, dann weiß man entweder, okay, da ist gar nicht so viel Traction drauf auf dem Projekt, der Maintainer hat vielleicht gerade keine Zeit. Das sagt einem aber auch, dass dein Pull-Request mit hoher Wahrscheinlichkeit auch nicht gereviewt werden würde, weil die Zeit einfach nicht da ist. Kriegst du Feedback, dann leitet der Maintainer dich entweder in die richtige Richtung, so nach dem Motto, hey, super Idee, aber was hältst du davon, diese Logik da hinten in die Klasse zu packen? Da passt sie, glaube ich, besser hin. Gibt dir also Tipps zur Architektur des Programms und vermeidet dann natürlich konstant das Back-and-Forth, was du bei einem Pull-Request hast. Und somit führt das schneller zum Mergen, weil du dann halt schon eher das Agreement vom Maintainer kriegst. Und er weiß auch Bescheid, hey, da arbeitet jemand dran, cool.

Wolfi Gassler (00:09:49 - 00:10:02)

Wenn du jetzt auf die andere Seite gehst, also auf die Owner-Seite, du hast eh schon erwähnt, was dann der Owner machen sollte oder vielleicht macht, dass er dich darauf hinweist. Gibt es da irgendwelche Best Practices auf Owner-Seite, wie man mit Contributoren umgeht?

Andy Grunwald (00:10:02 - 00:11:08)

Als Maintainer hat man einen schmalen Grat oder man hat ein bisschen zu kämpfen, weil man kriegt sehr viele Nachrichten von sehr vielen Contributoren, die wollen was ändern und du steckst halt auch als Maintainer recht viel Arbeit da rein, diese neuen Contributor on zu boarden. Du machst dir mit den Architektur vertraut, mit deinen Regeln, vielleicht hast du gewisse Commit-Messages, die gemacht werden müssen, Tests ausgeführt werden müssen, etc. Jedes Projekt hat seine eigene Struktur. Du steckst also relativ viel Arbeit da rein, diese Leute onzuboarden, in der Hoffnung, dass sie natürlich für einen längeren Zeitraum zum Projekt kontribuieren. Die Realität ist anders. Die Realität ist, du onboardest Leute, die machen einen Change und siehst du nie wieder. Oder du onboardest Leute und die machen nie einen Change. Das kann sehr frustrierend sein für einen Maintainer. Was ich als Maintainer oft mache ist, auch wenn ich keine Zeit habe, irgendwas zu reviewen, ist, ich schnappe mir kurz das Issue, schreibe, hey, vielen Dank, ich habe gerade keine Zeit, ich schaue später, kann aber ein bisschen was dauern und dann absenden. So gibst du dem Contributor, dem möglichen Contributor, kurzes Feedback, ich habe das gesehen, meine private Lage lässt es aber gerade nicht zu, dass ich hier Zeit drauf committe, ich melde mich später.

Wolfi Gassler (00:11:08 - 00:11:19)

Aber man erwartet sich ja dann trotzdem, dass du innerhalb eines sinnvollen Zeitrahmens irgendwie antwortest. Also wenn du dann ein Jahr später darauf antwortest, ist es, man erwartet sich ja wahrscheinlich irgendwann eine schnellere Reaktion.

Andy Grunwald (00:11:19 - 00:11:59)

Ja, ist es schade. Auf der anderen Seite müssen alle Contributor meines Erachtens nach auch lernen. There is no free lunch. Open source heißt nicht immer, dass etwas maintained ist. Open Source kann auch sein, ich habe einen kleinen Prototypen geschrieben und habe den einfach raus in die Welt gepusht. Und das heißt nicht, dass das eine Applikation ist, die man wirklich nutzen kann. Das kann aber als Quelle für Inspiration für ganz viele andere Sachen genutzt werden, wie zum Beispiel ich benutze ein Framework. Leute finden mein Projekt und können dann sehen, wie ich die spezifische Funktionalität des Frameworks nutze in meinem Code, welche Requirements ich erfüllen muss, welche Variablen ich initialisieren muss, damit diese Methode funktioniert etc. Das ist ja auch Open Source. Wie machen das andere Leute?

Wolfi Gassler (00:11:59 - 00:12:40)

Ein ganz konkretes Beispiel. Ich bin jetzt nicht so erfahren in der ganzen Open-Source-Szene, aber ein Open-Source-Projekt, mein erfolgreichstes Open-Source-Projekt ist Plug-in für Doku-Wiki und ich verwende seit Jahren kein Doku-Wiki mehr. Das heißt, meine Motivation natürlich daran, weiterzuarbeiten, ist minimal, würde ich mal sagen. Wie gehst du mit diesen Klassischerweise kommt man genau in diese, ganz oft meiner Meinung nach, in diese Position. Man hat irgendwas gemacht, verwendet, aber das eigentlich selber nicht mehr. Was macht man dann? Soll man das weiter maintainen? Was gibt's für Möglichkeiten? Was würdest du empfehlen? Oder was hast du mit deinen Projekten gemacht?

Andy Grunwald (00:12:40 - 00:14:20)

Du bist in einer ganz klassischen Situation. Ich habe glaube ich neun oder zehn Open-Source-Projekte, die genau in diese Kategorie fallen. Ich habe das vor mehreren Jahren gemacht, wurde genutzt. Inzwischen bin ich woanders unterwegs, nutze es nicht mehr und was mache ich jetzt mit diesem Projekt? Es gibt mehrere Möglichkeiten und die sind alle völlig legitim. Du kannst sagen, hey, dieses Projekt ist unmaintained, ich nutze das nicht mehr, akzeptiere keine Pull-Requests und kannst sagen, gut, du lässt es einfach in dem Status, in dem es da ist. Ist schade, aber völlig okay. Open Source bedeutet auch, du kannst den Code kopieren, forken und weiterführen. Eine andere Möglichkeit ist, du suchst dir aktive Community-Mitglieder, Leute, die ziemlich viele Issues schreiben, Leute, die vielleicht schon mal ein paar Pull-Requests gemacht haben, wenn du in der glücklichen Lage warst, diese Contribution zu kriegen, und schreibst ihnen einfach mal eine E-Mail. Hey, pass mal auf, ich bin nicht mehr in dem Space unterwegs, ich nutze kein Doku-Wiki mehr, hast du nicht Lust, Maintainer zu sein? Und dann sei einfach so mutig, schnapp dir den GitHub-Username und mach diese Person zum neuen Maintainer, zum neuen Contributor, weil natürlich Es hat auch ein paar Risiken, aber die meisten Leute haben sehr sehr ein gutes Mindset und fühlen sich, hey toll, ich nutze Doku-Vecchi noch, ich nutze dieses Plugin sogar noch, ich kann das jetzt weiter mit hin. Das ist eine Methode, die sehr vielen Entwicklern eigentlich widerspricht. Weil was man da tut ist, man gibt die Ownership für ein Baby ab, was man gemacht hat. Und das bedeutet auch, das Plugin DokuWiki jetzt zum Beispiel, kann sich gegebenenfalls in Zukunft dann in eine andere Richtung entwickeln, als du es eigentlich wolltest. Aber jemand führt es weiter, entwickelt es weiter. Es birgt aber auch Risiken. Nehmen wir mal so an zum Beispiel, jemand kann sagen, angenommen dein DokuWiki Plugin hat 100.000 Nutzer.

Wolfi Gassler (00:14:22 - 00:14:22)

Schön wärs.

Andy Grunwald (00:14:22 - 00:14:31)

Und das Doku-Wiki hat eine Auto-Update-Funktionalität. Du gibst die Maintainership ab, die Ownership ab. Und jemand editet da einen Bitcoin-Mining-Prozess rein.

Wolfi Gassler (00:14:31 - 00:14:32)

Gute Idee eigentlich.

Andy Grunwald (00:14:33 - 00:14:54)

Das kann dann natürlich, je nachdem wie das Projekt aufgebaut wird, auch deine persönliche Reputation zerstören. Angenommen, das Ding ist auf GitHub, github.com slash wolfgang slash doku-wiki-plugin. Und du gibst das Ownership von dem Repository ab. Es bleibt aber in deinem Namespace. Und jeder denkt, das doku-wiki-plugin ist dann immer noch vom Wolfgang. Obwohl du es ja gar nicht mehr mittehnt. Du hast ja die Ownership abgegeben, richtig?

Wolfi Gassler (00:14:55 - 00:15:00)

Das heißt, besser wäre es, es wird weggeforkt und wird dann irgendwo anders weiterentwickelt.

Andy Grunwald (00:15:00 - 00:15:15)

Es wird entweder weggeforkt in anderen Usernamespaces, das kann aber zur Gefahr führen, dass dieses Plugin in mehreren Versionen geforkt wird. Und das ist relativ schwierig dann für die Enduser zu wissen, was ist denn jetzt die aktuellste Version hier, wenn vier Leute das machen. Ja.

Wolfi Gassler (00:15:16 - 00:15:17)

Aber du kannst es ja auch dementsprechend.

Andy Grunwald (00:15:17 - 00:15:23)

Verlinken und Genau, du kannst sagen, das ist der Hauptfork, das ist die Hauptweiterentwicklung, bitte geht darüber, genau.

Wolfi Gassler (00:15:23 - 00:15:36)

Was mir auch sehr oft passiert sind, die klassischen Issues, die aufgemacht werden. Ich brauche Feature XY und es wäre extrem cool, wenn das und das gemacht wird. Wie gehst du damit um?

Andy Grunwald (00:15:37 - 00:16:17)

Ist erstmal eine valide Sache, wenn jemand ein Feature-Request hat. Ich frage immer sehr, sehr viele Informationen ab. Ich bin immer ein großer Freund davon, dass Leute sich 5-10 Minuten Zeit nehmen, um ein ordentliches Ticket zu schreiben. Ein ordentliches Ticket bedeutet im Falle eines Feature-Requests, was ist mein Use-Case, wie sieht mein Setup aus, wie stelle ich mir das Feature vor und warum wäre das sinnvoll, nicht nur für mich, sondern für alle. Für alle Nutzer. Das ändert ein bisschen Kontext, man hat so ein bisschen Background-Informationen, warum man das braucht und so weiter und so fort. Dann stellt man das ein und dann hat der Ticketersteller natürlich schon irgendeine Art Erwartung. Ähnlich wie ein Hund, wenn du den die ganze Zeit mit Leckerlien trainierst.

Wolfi Gassler (00:16:17 - 00:16:18)

Schöner Vergleich.

Andy Grunwald (00:16:18 - 00:17:49)

Dann schickst du ihn immer auf die Decke und immer wenn er auf die Decke geht, kriegt er ein Leckerli. Nächstes Mal, wenn du ihn auf die Decke schickst, das Erste, was er versucht, er hat eine Erwartungshaltung, er will ein Eckerli. Ein Ticket-Ersteller ist natürlich kein Hund, aber der Ticket-Ersteller hat die Erwartung, dass seine Antwort zurückkommt oder vielleicht sogar, dass das Feature implementiert wird. Der Maintainer hat natürlich die Aufgabe, den Use-Case zu verstehen, zu checken, kann man diesen Use-Case vielleicht schon mit vorhandenen Bordmitteln umsetzen, aber auch, passt das überhaupt zur Strategie? Nehmen wir mal Unix-Tools. Es gibt für jeden Anwendungsfall ein Unix-Tool und ein Unix-Tool hat immer nur einen Anwendungsfall. Du wirst jetzt keine Streaming-Fähigkeiten in dem Befehl cat wiederfinden, weil das gehört einfach nicht zu dem Befehl. Der Cat-Befehl zeigt den Inhalt einer Datei und das war's. Deswegen musst du halt ein bisschen evaluieren, das Feature, passt das überhaupt hier rein? Oder wäre das vielleicht nicht ein neues Tool? So würde ich damit umgehen, ganz klar sagen, hey, passt nicht zur Strategie, ich denke nicht, das sollte implementiert werden. Oder, wenn es doch ein tolles Feature ist, was implementiert werden sollte, Hast du vielleicht Lust daran zu arbeiten? Ich versuche dann immer die, ich will nicht sagen, die Arbeit abzugeben, doch nicht immer alles selbst zu tun, sondern auch andere Leute eher zu enablen und helfen, dass die da selbst kontribuieren können. Vielleicht mal ein bisschen, hey, ich würde es vielleicht so implementieren oder schon mal in die Richtung. Hättest du Zeit und ich geile dich selbst. Man kann natürlich auch die professionelle Route gehen und sagen, hey, ich bin, ich bin open for contract work. Du kannst dieses Feature sponsoren und dann baue ich das.

Wolfi Gassler (00:17:50 - 00:17:55)

Ja, ist natürlich auch eine sehr interessante Variante. Hattest du schon jemals oder hast du es jemals verfolgt?

Andy Grunwald (00:17:55 - 00:18:33)

Ich habe es angefangen zu verfolgen und ich bekomme bei manchen Open-Source-Projekten E-Mails. Hey, ich würde gerne das und das umsetzen, kannst du mir mal helfen? Die Antwort, die schreibt dann immer eine E-Mail-Antwort zurück. Hey, pass mal auf, wäre cool, wenn du dein Anliegen bitte als Issue formulieren könntest. Hier ist der Link, damit die ganze Sache transparent dokumentiert ist, damit die Community vielleicht auch helfen kann. Und andere Leute, die dasselbe Problem haben, würden dann eine Lösung finden und so weiter und so fort. Dann machen die das auch. Und unten drunter heißt es, hey PS, wenn dir das Projekt jetzt schon geholfen hat, vielleicht möchtest du das Projekt ein bisschen unterstützen und hier drei Dollar für einen Kaffee dalassen.

Wolfi Gassler (00:18:33 - 00:18:38)

Aber jetzt, dass jemand wirklich für ein Feature zahlt für die Entwicklung. Hast du das jemals gemacht?

Andy Grunwald (00:18:38 - 00:18:45)

Ich habe es in die Issues gepostet, aber in der Regel bei 99 Prozent hört dann die Konversation auf und man kriegt keine Antwort mehr.

Wolfi Gassler (00:18:45 - 00:19:13)

Ich habe auch schon die Erfahrung gemacht, dass wenn du fragst, ja, Es wäre einfach zu implementieren, kann ich gern helfen, dort und dort, dann kommt sofort, uh, bin eigentlich kein Entwickler, uh, kenne PHP nicht, uh, hab keine Zeit. Das mit der Zeit ist immer dann sehr ärgerlich, finde ich persönlich, weil der schreibt rein, er hätte gern ein Feature und hat selber keine Zeit erwartet, aber dass du vielleicht die Zeit investierst in dieses Feature.

Andy Grunwald (00:19:13 - 00:20:12)

Open Source wird oft missverstanden. Open Source wird immer so verstanden, dass es wirklich Free Work ist. Und auch super viele CEOs von Firmen denken, oh wir benutzen jetzt Open Source und dann haben wir jetzt nicht nur unsere 10 Angestellten Entwickler, sondern die weltweite Community. 10 Millionen Entwickler können auf diesen Source Code zugreifen und den weiterentwickeln und wir kriegen natürlich dann jemand anders entwickelt für uns den Source Code. Die Realität sieht anders aus. Viele Projekte werden nur von einer Person maintained. Bestes Beispiel aus den letzten Jahren ist OpenSSL. OpenSSL, einer der Foundations vom ganzen Internet, wird von zweieinhalb Leuten maintained oder ähnliches. Oder wenn wir über das Tool Curl reden, unglaublich viele Kontributoren. Aber da ist ein Name, Daniel Stenberg, der Curl-Mensch, der Curl-Maintainer. Curl ist meines Erachtens einer der weit verbreitetsten Software weltweit. Kein einziges Auto wird mehr ohne Curl fahren. Waschmaschinen würden keine Wäsche mehr waschen ohne Curl. Ein Maintainer, das ist die Realität.

Wolfi Gassler (00:20:12 - 00:20:19)

Wobei der Fulltime-Maintainer ist, muss man auch dazu sagen, der bekommt ja von seiner Firma gezahlt dafür, dass er wirklich Er.

Andy Grunwald (00:20:19 - 00:21:52)

Ist inzwischen, er macht das Vollzeit, er war vorher bei Mozilla, jetzt ist er bei Wolf SSL, genau. Ist auch ein enorm großes Projekt. Dennoch ist es ein enorm komplexes Projekt für eine Person. Und ich habe höchsten Respekt vor diesem Menschen, weil er macht nicht nur Curl, er macht auch sehr viel DNS über HTTPS, sichere Verbindungen etc. In dem Space ist er auch unterwegs. Hat natürlich auch sehr viel mit Curls zu tun, weil er sehr viel Kommunikationsprotokolle in Curl implementiert, aber auf jeden Fall Respekt. Kommen wir nochmal zurück zu dem Feature. Jemand macht ein Feature-Ticket. Es kann aber auch in die andere Richtung gehen und da bin ich auch ein Freund von. Das mache ich nämlich auch sehr oft. Und zwar immer wenn ich ein Tool sehe, wo ich ein Feature vermisse, was ich selbst nutze, also das Tool nutze ich selber, dann nehme ich mir auch 10-15 Minuten Zeit, mache ein ordentliches Ticket und edite das Feature einfach mal da. Und ich hatte schon oft positive Erfahrungen, dass ich hatte vor das Feature zu selbst zu implementieren, hab es aber einfach mal als Ticket eingestellt und wusste in den nächsten vier Wochen komme ich nicht dazu. Der Maintainer hat aber gesagt, hey, das ist ein cooles Feature, so habe ich noch nie drüber nachgedacht, gib mir mal eine Woche. Nach einer Woche später war eine neue Version draußen und dieses Feature, was ich genau haben wollte, war implementiert. Das fand ich auch super cool und das sollst du mal nicht erwarten, bin ich ganz ehrlich, aber so kann es auch gehen. Deswegen sage ich 10 bis 15 Minuten Zeit nehmen, kurz drüber nachdenken, ein ordentliches Ticket einstellen, weil ein ordentliches Ticket einstellen zeugt auch ein bisschen Respekt gegenüber dem Maintainer und auch gegenüber der Zeit des Maintainers. Weil wenn der Maintainer dann konstant immer nachfragen muss und alle Informationen dir auf seine Nase ziehen muss, das ist es halt auch nicht. Da hat der Maintainer auch keine Lust und auch keine Energie zu.

Wolfi Gassler (00:21:53 - 00:22:05)

Also zusammenfassend, Kommunikation ist sehr, sehr wichtig und als erstes immer Kontakt aufnehmen mit der Community, bevor irgendwas gemacht wird, weil sonst ist es unter Umständen verlorene Zeit, die man investiert hat.

Andy Grunwald (00:22:05 - 00:22:39)

Völlig richtig. Bitte wirklich nochmal nachdenken, das was du in deinem Kopf hast, das weiß der Leser des Tickets nicht. Wo kommst du her? Was hast du denn für ein Background? Was ist dein Use Case? Wie sieht dein Setup aus? Beispiel, eine Web-Software, Immer hinschreiben, welcher Web-Server, welche PHP-Version, einen Applikations-Tool auf deinem Rechner, welches Betriebssystem, Mac OS X, welche Version, Windows 11, etc. Kontext geben, was du erreichen möchtest, damit diese Person auch das Setup kennt, etc. Und wirklich mal Zeit nehmen, vielleicht auch ein bisschen ausschweifender werden, das schadet nicht.

Wolfi Gassler (00:22:40 - 00:22:52)

Wenn wir mal in den professionellen Kontext gehen, wie siehst du denn den Stellenwert von Open Source im professionellen Firmenbereich und die Wichtigkeit von Open Source oder die Unwichtigkeit oder die Chancen auch von Open Source?

Andy Grunwald (00:22:52 - 00:23:04)

Open Source ist unglaublich wichtig im Corporate Umfeld. Es wird aber nicht als unglaublich wichtig anerkannt. Open Source hat, jede Firma heutzutage basiert meines Erachtens nach auf Open Source oder auf Bruchstück von Open Source.

Wolfi Gassler (00:23:05 - 00:23:06)

Hast du ein Beispiel konkretes?

Andy Grunwald (00:23:06 - 00:23:13)

Ja, jede Web-Company, die irgendwas auf PHP macht, nutzt entweder Nginx oder Apache 2, HTTP2-Web-Server.

Wolfi Gassler (00:23:13 - 00:23:14)

Oder PHP.

Andy Grunwald (00:23:15 - 00:23:45)

Oder PHP, genau. Oder PHP selbst sogar, ja. Das bedeutet, und klassische E-Commerce-Shops, Magento, Oxit, Spiker, etc., etc., laufen alle auf PHP. Da könnte kein einziger Shop mitlaufen, und die basieren auf Open Source. Warum ist es unterrepräsentiert? Vielen Leuten ist das nicht bewusst, dass sie ihr Businessmodell auf etwas stellen, was von ganz vielen Leuten in ihrer, oft in ihrer Freizeit, ich sage oft, nicht immer, erstellt wurde und öffentlich zur Verfügung gestellt wurde.

Wolfi Gassler (00:23:45 - 00:23:56)

Wobei ich auch einmal gelesen habe, dass ca. die Hälfte vom Open Source Code durch kommerzielle Firmen bzw. durch bezahlte Entwickler programmiert worden ist. Ich kann schauen, ob ich den Link nochmal finde, kann ich mir gerne in die Show Notes packen.

Andy Grunwald (00:23:57 - 00:24:22)

Die Statistik würde mich interessieren, die kenne ich jetzt so nicht. Ich denke, es ist bei großen Projekten auch oft der Fall, speziell Programmiersprachen, speziell Basisinfrastruktur wie zum Beispiel einen Webserver. Ich will aber auch sagen, dass unglaublich viele Webserver-Plugins individuelle Entwicklungen sind oder ähnliches oder Plugins für Magento oder nimm dir irgendwas. Das sind dann alles wieder, was oft nicht gebackt ist.

Wolfi Gassler (00:24:24 - 00:24:36)

Aber eben sehr oft steht da auch eine Agentur dahinter. Die Agentur hat das mal entwickelt und stellt das dann Open Source zur Verfügung. So Plugins sind ja ganz oft, dass da irgendwie so eine kleine Freelancer dahinter steckt oder eine kleine Agentur oder so.

Andy Grunwald (00:24:36 - 00:25:49)

Genau, sofern der Auftraggeber das dem Vertrag natürlich erlaubt und so weiter und so fort. Open-Source ist aber auch eine ganz interessante Geschichte, weil umso aktiver eine Firma im Open-Source-Bereich ist, sei es im Open-Source-Sponsoring, sei es das Maintainen von eigenen Open-Source-Projekten, sei es den Mitarbeitern erlauben, während der Arbeitszeit zu Open-Source zu contributen, umso positiver ist das auch für die Firma fürs Recruiting. Ich erzähle mal eine kurze Story von Trivago und zwar haben wir bei Trivago Bewerbungen bekommen, noch Leute eingestellt und mit denen habe ich dann irgendwann gesprochen und die sagten, hey einer der Hauptaugenkriterien, warum ich mich bei Trivago beworben habe, ist weil Trivago im Open Source Bereich auch aktiv ist. Ja ihr sponsort ja Webpack und Babel und ihr habt ja auch ein paar Umsource-Projekte und ihr encouraget das ja auch, dass man dann, wenn man mal ein Bug findet, das dann ja auch gefixt wird und so weiter, ja? Ja, das finde ich so stimmt, cool. Danke, dass du mir das sagst. Finde ich cool, dass das auch sichtbar ist. Und dann habe ich mal gefragt, hast du denn schon mal jemals irgendeinem Open-Source-Projekt Contributed mal ein Issue erstellt, obwohl ich sagte, nee. Das bedeutet, auch Leute, die gar nicht so aktiv in der Open-Source-Szene sind, sehen, was Firmen mit diesem Bereich zu tun haben. Und das macht das natürlich wieder attraktiver, dort vielleicht anzufangen oder mal ein bisschen zu recherchieren und ähnliches.

Wolfi Gassler (00:25:50 - 00:26:12)

Als kleine Firma, wenn man das jetzt als Beispiel nennt, kleine Agentur, kleine Firma in Deutschland, was könnte die machen im Open-Source-Bereich? Also du hast gemeint, wenn man sich irgendwie engagiert im Open-Source-Bereich. Was hat diese kleine Firma für Möglichkeiten, sich zu engagieren oder irgendwas zurückzugeben oder dann als guter Employer dazustehen, der sich im Open-Source-Bereich engagiert?

Andy Grunwald (00:26:12 - 00:27:45)

Es gibt unglaublich viele Möglichkeiten. Neben kleinen Firmen, sagen wir mal, gar nicht so ein großer finanzieller Background. Es muss nicht immer 100.000€ sein, die man spendet. Es reicht auch 100€. 100€ an irgendein Projekt, das ist schon eine ganze Menge. Wenn man jetzt 100€ an so ein Projekt wie React spendet, dann geht das unter. Wenn man jetzt 100€ an ein Magento-Plugin spendet, der Maintainer wird sich freuen. Andere Sachen ist, Open-Source-Projekte suchen oft Locations für Hackathons oder ähnliches. Man kann vielleicht einfach mal seinen Meeting-Raum zur Verfügung stellen und dann kommen die Leute an, organisiert einen Hackathon und stellt einfach mal am Wochenende die Firmenräume zur Verfügung. Oder irgendwo in einer, in einer, zum Beispiel Type 3 gibt's Hackathons oder Codesprints und die suchen ab und zu mal Dinner-Sponsoren. Das bedeutet, eine Firma packt ein paar Euro auf den Tisch und sponsert denen eine Pizza oder einen Abendessen beim Italiener. Das reicht. Alternativ, man spricht über das Open-Source-Projekt. Ist auch eine Contribution. Man verbreitet es. Oder man geht in den Issue-Tracker und hilft da ein bisschen mit. Oder man schreibt vielleicht so eine Case-Study als kleine Firma. Hey, wir nutzen dieses Open-Source-Projekt in diesem Kontext für diesen Kunden. Das ist Marketing. Open Source Projekte haben in der Regel kaum Budget, wenn sie nicht Teil einer großen Foundation sind, wie Linux Foundation oder ähnliches, um dieses Marketing zu stemmen. Aber jeder, jede Case Study hilft. Und solche, es muss nicht immer nur finanziell und monetär sein, es kann auch einfach sein, dass man mit kleinen Sachen wie, ich habe Büroräume, die sind eh beheizt, kommt doch einfach vorbei.

Wolfi Gassler (00:27:46 - 00:28:03)

Und wenn es um die Mitarbeiter geht, also wenn Mitarbeiter sich zum Beispiel schon engagiert sind im Open-Source-Bereich, wie würdest du das handhaben dann? Die lassen sich ja auch ungern vereinnahmen vielleicht, wenn sie jetzt für die Firma arbeiten, dass plötzlich ihr privates Engagement in der Open-Source-Szene für die Firma dann verwendet wird.

Andy Grunwald (00:28:03 - 00:28:25)

Was man da noch machen, da kann man natürlich, man kann die Person natürlich eine gewisse Art für die Arbeitszeit auch freistellen und dann im Namen der Firma Open Source kontributen, dass die Mitarbeiter sich immer in der Freizeit machen müssen. Da kann man unterschreiben in den Pull Requests, hey, this Pull Request was sponsored by my company name, ja, und dann während der Arbeitszeit das zu tun. Das geht natürlich auch.

Wolfi Gassler (00:28:25 - 00:28:35)

Was hältst du von dem, fällt mir der Name durch, nimm mal ein, ist das Open Source First oder dass das Firmen intern alles Open Sourcen oder fast alles?

Andy Grunwald (00:28:35 - 00:28:37)

Intern innerhalb der Organisation? Ja.

Wolfi Gassler (00:28:37 - 00:28:48)

Ich glaube Zalando hat da mal so ein Paper oder so veröffentlicht, dass sie halt intern alles, also die meisten internen Tools auch einfach Open Sourcen und standardmäßig Open Source.

Andy Grunwald (00:28:48 - 00:28:52)

Ah, du meinst also nicht innerhalb der Firma opensourcen, sondern wirklich auch?

Wolfi Gassler (00:28:52 - 00:28:54)

Wirklich auch outside, ja.

Andy Grunwald (00:28:54 - 00:29:09)

Finde ich eine super Sache. Unabhängig davon, ob eine Organisation das Projekt wirklich dann final opensource macht, denke ich, die Anwendung von opensource best practices innerhalb der Organisation anzuwenden, ist unglaublich wertvoll. Ich meine, dafür gibt es einen Fachbegriff, der nennt sich Innersource.

Wolfi Gassler (00:29:10 - 00:29:12)

Was sind das für best practices?

Andy Grunwald (00:29:12 - 00:30:01)

Man bereitet das Repository so vor, dass es contributor-freundlich ist. Man hat eine Dokumentation, wie man die Tests ausführt. Man hat eine Problembeschreibung. Man hat Issue-Templates, Pull-Request-Templates. Man hat eine offene und transparente Kommunikation zu dem Projekt. Alle Meeting-Notes, die zu dem Projekt abgehalten werden, sind vielleicht in der Readme oder Ähnliches verlinkt, et cetera, et cetera. Man encouraget also auch innerhalb der Firma Leute, die vielleicht mit dem Projekt nichts zu tun haben, trotzdem mal zu joinen, mal drauf zu gucken und ähnliche. Die Grundidee bei InnerSource ist die Anwendung von Open Source Best Practices innerhalb einer geschlossenen Organisation. Und der einzige Unterschied ist, wenn man dann ein InnerSource-Projekt open sourcen möchte, dann drückt man einfach nur auf, ich mache das jetzt von private auf public und dann sollte sich eigentlich nichts geändert haben.

Wolfi Gassler (00:30:01 - 00:30:24)

Genau und das ist, was Zalando damals mit Open Source First vorgeschlagen hat, also wir werden wahrscheinlich nicht die Ersten gewesen sein, aber dieses automatische, mehr oder weniger automatische Public Setzen von Projekten und da hast du natürlich zusätzlich diesen Druck von außen dann, dass das wirklich sauber sein muss, weil so Klassiker ist, du fängst irgendwie mit dem Projekt an und am Anfang committest du mal das Passwort mit von irgendeinem kleinen Tool.

Andy Grunwald (00:30:24 - 00:30:24)

Klassiker.

Wolfi Gassler (00:30:25 - 00:30:55)

Und erstens kann es zum großen Sicherheitsproblem werden und wenn du auch von Anfang an public bist, dann hast du diesen Druck, dass du weißt, auch als Entwickler, das ist wirklich public, da muss ich aufpassen. Und sonst sagst du halt, ah, ist ja eh nur intern oder die Readme braucht jetzt nicht so gut schreiben, weil das ist eh nur intern, das sieht ja eh nur das andere Team. Und wenn du aber public bist, dann bist du halt wirklich gezwungen, das zu machen. Muss natürlich auch irgendwie überprüft werden intern, dass das alles sauber läuft. Aber das etwas Public ist, baut sicher einen großen Druck auf ein Team.

Andy Grunwald (00:30:55 - 00:32:08)

Für solche Cases gibt es natürlich automatisiertes Tooling, die das natürlich erkennen. Das bedeutet, Falls man mal irgendwann ein Passwort, ein Secret, ein Token oder was auch immer in den Code committed hat und es wird open-sourced, dann hat GitHub selbst verschiedene Security-Scanner sogar laufen, die dich dann informieren. Hey, pass mal auf, du hast da ein AWS-Key oder ähnliches drin. Da muss man aber auch aufpassen. Die GitHub-Repositories werden inzwischen enorm gut gecrawled, auch von Angreifern. Das bedeutet, hast du eine Codebase, wo mal ein Passwort, ein AWS-Key oder ähnliches drin ist, dann kann es innerhalb von drei Minuten sein, dass dieser Key genommen wird und dort Infrastruktur zum Beispiel in einem Amazon-Account gelauncht wird. Das ist enorm schnell inzwischen. Open Source First legt natürlich enorm hohe Qualitätsstandards an den Tag. Was natürlich super ist ja weil wir kennen es alle im klassischen projektgeschäft vielleicht eine taffe deadline muss man eben schnell gehen klack klack klack ich habe jetzt gerade keine zeit das passwort in der environment variabel zu packen in den konfigurationspfeil und mein deployment anzupassen sondern ich committe das ach das ändere ich nächste woche und nächste woche ist man dann krank und dann vergisst man es wieder etc.

Wolfi Gassler (00:32:08 - 00:32:30)

Etc. Und was natürlich auch gefährlich ist, ist das wenn du das später löscht, du hast halt trotzdem noch die History. Also da muss man aufpassen bevor man irgendwas Public setzt. Wenn du die History natürlich auch Public setzt, dann kannst du immer wieder zurück und da musst du die History umschreiben. Gibt einen netten GitHub Artikel, den habe ich leider schon sehr oft gebraucht, aber der beschreibt das sehr schnell, wie man die History sauber löscht, das wirklich alle Daten.

Andy Grunwald (00:32:30 - 00:32:56)

Es gibt natürlich verschiedene Möglichkeiten, wie du ein Projekt opensource, speziell mit der History. Du kannst die History umschreiben. Finde ich immer so ein bisschen dirty, muss ich zugeben. Ich würde dann eher vorschlagen, je nachdem, wie wichtig die History ist und wie sauber und wie qualitativ wertvoll auch, ob man da nicht sowieso mit einer leeren History startet. Kommt ganz auf deinen Projektkontext an, aber da gibt es verschiedene Möglichkeiten.

Wolfi Gassler (00:32:57 - 00:33:19)

Jetzt sieht man schon eindeutig, du bist extrem positiv eingestellt gegenüber Open Source. Siehst du irgendwo für eine Firma jetzt auch einen negativen Punkt? Oder gibt's irgendwas, wo dich jemand überzeugen könnte, das macht keinen Sinn der Open Source in irgendeiner Form einzusetzen oder das Public zu setzen? Oder würdest du sagen eigentlich fast immer beides einzusetzen oder Public?

Andy Grunwald (00:33:19 - 00:33:22)

Das kommt immer auf den Anwendungsfall der Open-Source-Tooling an.

Wolfi Gassler (00:33:22 - 00:33:27)

Es ist eine unfaire Antwort, es kommt drauf an. Das ist die Standard-Informatiker-Antwort. Die lassen wir hier nicht gelten.

Andy Grunwald (00:33:27 - 00:35:06)

Nehmen wir mal ein Case und zwar ist das im Lizenzmanagement von Open-Source. Gibt es sogenannte Copy-Left-Lizenzen. Das bedeutet, wenn du diese Software in einer speziellen Art und Weise in deine Software integrierst, bedeutet das, dass du deine Software, auf Anfrage sogar auch, auch open sourcen musst. Und das, wenn das ein proprietäres Software ist, kann dein Businessmodell zerstören. Bei BMW oder bei Audi gab es mal einen super Fall und zwar, muss ich nochmal raussuchen und wenn ich den finde, verlinke ich den in den Shownotes. In dem Bordcomputer des BMWs gab es in dem Impressum Lizenzmodelle. Und da wurde eine Software verwendet, die eine Copyleft Lizenz hatte. Und diese Copyleft Lizenz hatte zur Folge, dass jeder Mensch bei BMW anfragen konnte, gibt mir mal bitte die Software, die hier auf meinem BMW installiert ist. auf Basis dieser Open-Source-Lizenz. Weil die Copy-Left-Lizenzen sagen oft, wenn du diese integrierst, dann muss das, was das neue Erzeugnis ist, auch Open-Source sein. Das ist halt ziemlich viel im GPL-Bereich unterwegs. Und genug Public-Licenses. Und das war recht lustig. Dann hat BMW eine CD zurückgeschickt, wo dann die komplette Software drauf war. Aber die haben es dann gemacht, nicht freiwillig, erst nach mehreren Runden mit mehreren Anwälten. Aber das ist dann zum Beispiel etwas negatives, wo dann eine Firma enorm darauf achten muss, welche Open Source Projekte genutzt werden, welche Lizenz und ganz wichtig, wie diese in diese proprietary Software ist. Das heißt nicht, nur weil du es einsetzt, dass das dann auch für deine proprietary Software auch Open Source sein muss.

Wolfi Gassler (00:35:06 - 00:35:17)

Also definitiv ein Pro-Tipp, vor allem, wenn die Firma größer ist, durchaus mal alle Lizenzen durchchecken und kleine Libraries auch durchchecken, die da verwendet werden.

Andy Grunwald (00:35:17 - 00:35:30)

Leistungsmanagement ist ganz, ganz essenziell, weil sonst kannst du richtig Probleme kriegen im rechtlichen Bereich und da bewegen wir uns nicht in 1000-Dollar-Strafen, sondern das kann richtig hochgehen.

Wolfi Gassler (00:35:31 - 00:35:59)

Vor allem ist ja auch sehr schnell heutzutage, gerade wenn man jetzt an JavaScript zum Beispiel denkt, ist es ja auch sehr schnell feststellbar, welche Libraries werden verwendet, weil da der Source Code ja mehr oder weniger ausgeliefert wird. Und dann finden natürlich Leute auch sehr schnell heraus, oh, die verwenden die und die Library und das ist ja auch alles public dann und das können Leute herausfinden. Also dementsprechend ist es gerade in dem Bereich glaube ich noch mal wichtiger, im Backend ist es schwieriger das Ganze herauszufinden. Es soll jetzt keine Ausrede sein natürlich, aber ist definitiv ein wichtiger Punkt.

Andy Grunwald (00:35:59 - 00:36:45)

Das Lustige ist, das kann man aber oft trotzdem erkennen. Das bedeutet, wenn eine Firma einen Tech-Blog hat und einen Tech-Blog über irgendeinen Artikel schreibt, wo irgendein Software erwähnt wird und dann checkt man die Dependencies etc. etc. Wir reden das jetzt aber alles super schlimm. Die Realität sieht aber anders aus. Die Realität sieht so aus, dass es eine Nische ist, dass sehr, sehr, sehr wenig Anwälte sich wirklich mit Open Sourcen und Lizenzen auseinandersetzen. Das bedeutet, ich kenne keine Firma, keine Anwaltsfirma, keine Kanzlei, die rumguckt und sagt, wo sind Lizenzvorstöße und die verklagen wir jetzt. Ist mir jetzt keine bekannt. Ist ein sehr nischiges Thema. Wenn du also gerade zuhörst und Anwalt bist, mag es vielleicht sein, dass du dich darauf spezialisieren möchtest, weil ich denke, dieser Markt wird in Zukunft sehr stark wachsen.

Wolfi Gassler (00:36:46 - 00:36:51)

Also ganz allgemein, Anwälte, die auch ein technisches Verständnis haben, sind sehr, sehr gefragt, ja. Das kann ich definitiv.

Andy Grunwald (00:36:51 - 00:37:06)

Man muss aber auch sagen, Lizenzmanagement ist auch sehr kompliziert, auch für sehr viele Techniker und auch für mich, wo ich schon jahrelang im Open-Source-Bereich bin. Lizenzen ist ein schwieriges Thema. Wer sich mit Lizenzen ein bisschen weiter auseinandersetzen möchte, ein GitHub hat eine sehr schöne Webseite gebaut, choose-a-license.com.

Wolfi Gassler (00:37:07 - 00:37:08)

Die verlinken wir natürlich.

Andy Grunwald (00:37:08 - 00:37:17)

Die verlinken wir auch in den Show Notes, aber da steht mit einfachen Worten erklärt, was eine License hergibt, was man damit machen kann, was man nicht machen kann.

Wolfi Gassler (00:37:17 - 00:37:34)

Vielleicht noch, weil wir jetzt gerade bei Lizenzen sind, was würdest denn du für eine Lizenz empfehlen für jemanden, der einfach schnell mal ein Projekt startet, ohne da jetzt lang in die Details zu gehen, aber wenn jemand jetzt einfach mal losstarten will, Was würdest du empfehlen oder was verwendest du selbst?

Andy Grunwald (00:37:34 - 00:38:08)

Ich verwende sehr viel die MIT oder die Apache 2 License. Die Apache 2 License ist für mich jetzt gar nicht so relevant, weil die auch sehr viel Patentnutzung usw. miterlaubt und ich leider keine Patente habe. Aber meist die MIT, die ist recht quelloffen, da ist eigentlich alles super drin. Wer möchte, dass man, wer möchte, dass da kommerzielle Lösungen ausgeschlossen sind, dass da keine Leute Geld mitverdienen sollten, der müsste sich mal ein bisschen umgucken, vielleicht in den GPL-Bereich. Aber genau, die MIT, die ist es kurz, die ist einfach zu verstehen.

Wolfi Gassler (00:38:08 - 00:38:59)

Also vielleicht da auch noch, was ich so gelernt habe oder mitgenommen habe, ist einfach, ich habe am Anfang immer eher, bin eher in Richtung GPL gegangen, habe aber schon gemerkt, dass gerade wenn es um Libraries geht und du willst ja schlussendlich, wenn du sowas machst, auch üblicherweise, dass die Leute das verwenden und dass extrem viele Firmen im Vorhinein schon sagen, okay, wenn das GPL ist, dann setzen wir das nicht ein, weil denen das zu gefährlich ist. Also ich bin auch jetzt mehr in die LGBL- oder MIT-Ecke gegangen, damit das einfach möglichst viele Leute verwenden können. Das war mir eigentlich immer auch extrem wichtig. Und vielleicht noch ganz kleiner Punkt abseits von der Open-Source-Welt. Wir hatten das Problem an der Uni sehr oft, weil wenn Studenten Code schreiben in ihrer Bachelorarbeit, Masterarbeit, dann gehört denen der Code.

Andy Grunwald (00:38:59 - 00:39:00)

Den Veteranen oder der Uni?

Wolfi Gassler (00:39:00 - 00:39:49)

Nein, dem Studenten. Das heißt, ich kann auch da vielen, also einerseits kann ich der Uni das empfehlen natürlich, aber auch den Studenten, dass die wirklich MIT oder sowas wählen, weil dann kann erst die Uni das weiterverwenden, weil das ist ja normal Wissenschaft und die hoffentlich setzen die das ein, wenn es für die natürlich Sinn macht. Aber auch für die Studenten, wenn die wollen, dass ihr Software eingesetzt wird in irgendeiner Form, dann können sie das halt so eher fördern, als wie wenn das einfach geschlossener Source-Code ist. Weil, dass jetzt eine Firma irgendwie so einen Code mal ausprobiert, einsetzt und dann dafür zahlt einem Studenten ist eher selten. Also wenn jemand lieber die Motivation oder die Motivation dadurch erreichen will, dass das Firmen das wirklich einsetzen oder andere Leute, dann würde ich mittlerweile immer auf so eine MIT oder LGBL-License gehen, wo halt das wesentlich flexibler ist, wie man das Ganze einsetzen kann.

Andy Grunwald (00:39:50 - 00:40:06)

Spannender Punkt, Lizenzmanagement bei Projekten, die keine Lizenz haben. Was bedeutet das? Nur weil auf GitHub ein Projekt ist, heißt das nicht, dass das Open Source ist. Wenn keine Lizenz angegeben ist, dann ist das nicht Open Source. Dann heißt das nicht, dass du das nutzen darfst.

Wolfi Gassler (00:40:06 - 00:40:11)

Oder Open Source ist es schon, weil du hast ja den Source Code, aber du darfst es nicht nutzen.

Andy Grunwald (00:40:11 - 00:40:24)

Genau, du darfst es nicht nutzen, weil das Intellectual Property dann bei der jeweiligen Person liegt und da ist dann schon wieder schwierig, welches Intellectual Property Recht wird applied.

Wolfi Gassler (00:40:24 - 00:40:54)

Wobei natürlich auch da, wo kein Kläger da, kein Richter ist, in der Realität ist es dann natürlich weniger das Problem, aber für große Firmen, die sollten sich da natürlich schon Gedanken machen. Aber wie du richtig sagst, im Alltag ist das weniger ein Problem und für kleinere Projekte ist es auch weniger ein Problem. Aber es kann durchaus ein großes Problem werden und in größeren Firmen sollte man das auf jeden Fall beachten. Vor allem, wenn man irgendwie kritische Sachen baut und die Konkurrenz findet das raus, dann kümmert sich vielleicht die Konkurrenz darum, dass das dann vorgerichtet wird.

Andy Grunwald (00:40:54 - 00:40:58)

Das ist richtig. Mal eine andere Frage. Kennst du denn die Bier-License oder die Pizza-License?

Wolfi Gassler (00:40:58 - 00:40:58)

Nö.

Andy Grunwald (00:40:58 - 00:41:23)

Die Bier-License ist ganz gut. Die besagt, du darfst das hier nutzen, diese Software. Du darfst damit auch alles machen, wenn du mir ein Bier ausgegeben hast. Oder ähnlich wie bei einer Pizza. Also es gibt auch skurrilere Lizenzen. Man muss zusehen, diese Lizenzen sind nicht von der Open Source Foundation als offizielle Open Source Lizenzen ausgesehen. Aber es gibt auch die What-the-Fuck-License. Do whatever what the fuck you want with this software. Es gibt sehr viele skurrile Lizenzen.

Wolfi Gassler (00:41:23 - 00:42:08)

Aber ich glaube auch nochmal darauf zurückzukommen, dass du vielleicht einfach ein Bier ausgeben könntest oder den unterstützen könntest, den Open Source Maintainer. Wenn ich mir jetzt überlege, bei meiner kleinen Library, keine Ahnung wie viele das wirklich einsetzen, aber es sind glaube ich schon einige Leute, wenn die alle einen Euro gespendet hätten, jede von denen, dann wäre meine Motivation sicher wesentlich höher, daran weiterzuarbeiten. Also garantiert. Auch wenn das dann vielleicht nicht tausende Euro werden, sondern weniger, aber trotzdem, da hat man eine gewisse Motivation. Sei es ein Bier, sei es ein Euro. Also ich finde auch, dass man das extrem, die extrem wertvolle Arbeit auch irgendwie unterstützen sollte und das vielleicht auch den Hinweis an kleine Firmen oder sogar Privatpersonen, dass man das einfach mehr macht.

Andy Grunwald (00:42:08 - 00:42:18)

Sehr guter Einwand. Eine persönliche Story und zwar bin ich seit mehreren Jahren jährlicher Besucher der FOSDEM. Die FOSDEM ist das Free and Open Source Developer Europe Meeting.

Wolfi Gassler (00:42:18 - 00:42:26)

Dank dir bin ich das jetzt auch seit Jahren. Ich wurde da ja jedes Jahr gezwungen, fast mit der Pistole an der Schläfe mitzukommen, aber es hat sich gelohnt.

Andy Grunwald (00:42:27 - 00:42:38)

Für die Leute, die das nicht kennen, die FOSDEM ist die größte Open-Source-Konferenz in Europa. Die findet jährlich in Brüssel in Belgien statt mit weit über 5000 Leuten.

Wolfi Gassler (00:42:38 - 00:42:39)

Zumindest vor Corona.

Andy Grunwald (00:42:39 - 00:42:46)

Vor Corona. Ist komplett umsonst. Das bedeutet, alle Zugänge sind frei.

Wolfi Gassler (00:42:47 - 00:42:48)

Ist nur kostenlos, nicht umsonst.

Andy Grunwald (00:42:48 - 00:43:04)

Oh, Entschuldigung. Ja, ist gratis. Auf jeden Fall, weit über 300 Talks und da die so groß ist, kommen dort wirklich sehr, sehr, sehr viele Open Source Entwickler hin. Richard Stallman lief wieder über den Campus von der Uni.

Wolfi Gassler (00:43:04 - 00:43:26)

Übrigens auch ein sehr schönes Bild, die Kamerine, es war strömend. strömend Regen. Es war grausam kalt, wie immer in Brüssel. Es hat strömend geregnet und dann ist Richard Stallman gekommen in Shorts, barfuß, glaube ich, ist durch den Regen mit seinen langen Haaren und T-Shirt fast geschwebt mit seinem heiligen Schein.

Andy Grunwald (00:43:26 - 00:44:29)

Wie dem auch sei, kommen wir zurück zum Kaffee. Was ich da oft tue, ist, ich kontaktiere Leute von den Open Source Projekten, die ich nutze, oft vorher auf Twitter ein paar Tage. Hey, bist du auf der Forster? Hey, können wir uns mal treffen? Ich würde dir gerne einen Kaffee ausgeben. Kaffee. Kaffee, Entschuldigung. Oder ein Mate oder ein Bier. Und dann treffen wir uns irgendwo und ich geb dir das aus und sag einfach nur, hey, danke für dieses Tool, weil die zwei, drei Euro tun mir jetzt nicht weh. Diese Person hat endlich mal einen User kennengelernt. Und für kleinere Projekte ist das ein Motivationsboost, der geht wirklich unter die Decke. Wirklich, wenn ihr auch nur einen Dollar spenden könnt. Oder es gibt so Tools wie Buymeacoffee oder GitHub Sponsors. Macht das. Spendet einen Dollar. Auch an kleine Tools, ihr wisst nicht, was das für einen psychologischen Effekt für die Maintainer hat, weil als Maintainer bekommt man in der Regel kein Feedback. Man bekommt seltenst ein Danke. Wenn ihr kein Geld habt, anderer Tipp, schnappt euch die E-Mail-Adresse vom Maintainer, schreibt ihm ganz kurz Danke dafür. Hey Wolfgang, danke für deinen Doku-Wiki-Plugin. Ich finde das super, nutze das ein. Liebe Grüße aus Bali.

Wolfi Gassler (00:44:30 - 00:45:35)

Das ist übrigens, auch wenn man ein Issue schreibt zum Beispiel, man kann da in einem Issue ja gerne auch so was schreiben, dass man das Tool nutzt, wie man es nutzt, dass man es gerne nutzt, dass es ein cooles Tool ist, mal sich bedanken. Das kann man definitiv immer machen, das freut einen einfach als Maintainer sehr. Und wie du richtig sagst, oft ist es auch der Kontakt zu den Usern, der ja ganz schwer, weil du hast ja keine Ahnung, wer dein Tool verwendet. Und wenn du dann den Kontakt hast, kannst du vielleicht auch ein, zwei, drei Fragen stellen. Wie setzt du das ein? Wo setzt du das ein? Und das kann auch schon extrem motivierend sein, wenn man einfach hört, wo wird das Tool eingesetzt. Also bei Curl ist es ja so ein Klassiker, der tweetet ja immer extrem gern irgendwelche Screenshots eben von Waschmaschinen, von was für Devices auch immer oder TV-Screens, wo dann irgendwo ein Curl-Command aufgerufen wird, in einem Log-File oder in einem Error-Log oder sowas. Also das ist schon extrem motivierend, wenn man das weiß und wenn man auch User so eine Frage stellen kann, wo setzt du das ein? Da geht es gar nicht darum, dass man dann ein Bier bekommt, sondern einfach nur das Dankeschön und vielleicht eine Frage stellen kann. Also auch das hilft wirklich schon extrem weiter und ist extrem motivierend.

Andy Grunwald (00:45:35 - 00:45:44)

Also ich kann von meinen persönlichen Erfahrungen berichten. Das erste Mal, als ich ein Danke bekommen habe via E-Mail oder Issue, wollte ich nackig durch die Wohnung flitzen. Ich war so motiviert.

Wolfi Gassler (00:45:44 - 00:45:46)

Moment, tust du das sonst nie?

Andy Grunwald (00:45:46 - 00:46:16)

Nein, ich habe eine Hose an am Computer. aber ich wollte wirklich ich habe mich so gefreut meine frau wusste nicht was los ist warum ich mich so gefreut habe und da hat jemand einfach nur hey danke du hast mir gerade enorm viel arbeit abgenommen oder ich habe diese automation gebaut super wenn ihr das hört nutzt mal denkt mal kurz drüber nach welches Opsourceprojekt ihr nutzt geht heute abend oder jetzt gleich irgendwie kurz an den rechner macht ein issue auf und sagt hey thank you packt ein smiley dran das war's und send und ihr glaubt nicht was ihr da für einen effekt für den antenna habt Das gleiche gilt.

Wolfi Gassler (00:46:16 - 00:46:27)

Übrigens nicht nur für Source-Producer, sondern auch Content-Producer. Wenn du einen netten Blog-Artikel zum Beispiel liest, eine E-Mail, danke für den Blog-Artikel, hilft auch extrem viel.

Andy Grunwald (00:46:27 - 00:47:50)

Super Side-Story und zwar hat der inzwischen, ich glaube, Head of Open Source von GitHub, der kam von Microsoft, der hat einen super Blog-Artikel geschrieben, wie bei Microsoft Azure die GitHub-Organisation auf was für Mechaniken, die eingesetzt haben, um die GitHub-Organisation auf 25.000 Leute hoch zu skalieren. Ihr könnt euch vorstellen, wenn du eine GitHub-Organisation hast, wo 25.000 Leute drin sind, dass es andere Methodiken braucht zur Repo-Erstellung und so weiter und so fort, als wenn das 5 Leute sind. Diesen Artikel habe ich gelesen, habe dem Blogartikel, dem Autor geschrieben und daraus hat sich eine kurze Konversation ergeben, Wo wir teilweise über über Probleme bei Microsoft aber auch bei meinem Arbeitgeber gesprochen haben so nach dem Motto und dann habe ich auch gefragt hey wie löst ihr die denn bei Microsoft und so weiter und so fort und auf einmal hast du E-Mail Kontakt mit inzwischen dem Head of Open Source bei GitHub und du sprichst einfach über über alltägliche Probleme und denkst so hey Microsoft hat ähnliche Probleme und die kochen auch nur mit Wasser. Es scheint aber so als haben die mehr Wasserkocher. als ich, aber hey, die haben die gleichen Probleme. Und das ist super und er hat sich auch super gefreut, dass ich Danke gesagt habe und dann habe ich ein paar meiner Erfahrungen geteilt. Hat mich keine Zeit gekostet, wirklich, aber es hat mir einen unglaublichen Benefit gegeben und er sagte dann auch, hey, inzwischen, dieser Artikel ist zwei Jahre alt, ich wollte mal den refreshen, inzwischen sind wir bei 50.000 Leute, haben wir wieder andere Sachen gemacht, ich schreibe den mal, ich melde mich.

Wolfi Gassler (00:47:51 - 00:48:41)

Und da sieht man schon auch, warum wir in der letzten Episode bei Side-Projects auch gesagt haben, Side-Projects können sehr hilfreich sein bezüglich Kommunikation. Wenn man eigentlich ein Open-Source-Projekt hat, dann lernt man einfach extrem viel über Kommunikation und was es bedeutet zu kommunizieren. Und ich glaube, das haben wir jetzt auch in dem Gespräch eigentlich gut gesehen, wie wichtig eigentlich Kommunikation ist. Egal, ob du jetzt ein Issue erstellst, wenn du Contributen willst, dass du davor anfragst, dass du nochmal einfach nachfragst, Was habt ihr eigentlich vor? In welche Richtung geht ihr? Ich würde gerne dieses Feature einbringen. Macht es überhaupt Sinn? Kann ich das überhaupt machen? Wie soll ich das machen? Aber auch auf der anderen Seite, dass man mit den Contributoren kommuniziert als Maintainer in der richtigen Weise, um die ganze Community aufrecht zu erhalten. Und fürs Dankeschön kann man auch noch kommunizieren. Also Kommunikation ist schon ein extrem wichtiger Punkt bei Open Source.

Andy Grunwald (00:48:41 - 00:50:04)

Ich muss sagen, wirklich mein Involvement in der Open Source Community im Allgemeinen. Ich habe sehr viel Zeit investiert über die letzten 12, 13, 14 Jahre. Das ist richtig. Ich habe aber enorm viel gelernt. Ich würde wirklich sagen, mehr als 50% meines aktuellen Wissens habe ich durch das Involvement der Open Source Community. Ich habe wirklich Freunde kennengelernt. Ich wurde auf Hochzeiten von denen eingeladen. Sowas hätte ich nie gedacht. Zu denen habe ich heute noch Kontakt, obwohl ich in dem Projekt gar nicht mehr involviert bin. Ich habe so viel über Kommunikation, über professionelles Arbeiten, über Qualität, über Writing Skills gelernt. Du arbeitest mit anderen Kulturen, mit mit anderen Use Cases, mit anderen Programmiersprachen und Technologien. Ich habe wirklich sehr viel gelernt und ich kann mit Fug und Recht behaupten, dass mich mein Involvement im Open Source Bereich auch im professionellen Job enorm nach vorne gebracht hat und ich in sehr vielen Diskussionen auch valide Punkte anbringen konnte durch das Wissen, was ich da gesammelt habe. Es ist ein Zeitinvestment und es ist nicht immer einfach in die Projekte reinzukommen, da bin ich auch ehrlich. Und es braucht eine intrinsische Motivation und ab und zu kriegt man auch einen Dämpfer. Aber ich denke das ist gleichzusetzen mit allem was man im täglichen Leben lernt oder sich neu auf den Karren packen möchte. Wenn du nähst, versaust du auch mal eine Naht. So sehe ich das. Ich kann es wirklich nur jedem empfehlen.

Wolfi Gassler (00:50:05 - 00:50:25)

Auf diese Pitch ist jetzt wirklich nichts mehr drauf zu setzen. Ich glaube, Andi hat das gut verkauft. Ich hoffe, ihr macht ein Open-Source-Projekt oder beteiligt euch. Zumindest sagt Danke dafür, so wie ich jetzt. Danke Andi für diesen Input. Und wer noch nie auf einer Hochzeit war, startet ein Open-Source-Projekt. Ihr werdet dann auf eine Hochzeit eingeladen.

Andy Grunwald (00:50:26 - 00:50:37)

Lasst uns einfach mal wissen, wie ihr über das Thema denkt. Was habt ihr für Erfahrungen gemacht? Schreibt uns, auch wenn ihr nicht wisst, wie ihr starten sollt. Wenn da genug Feedback kommt, vielleicht machen wir mal eine Folge dazu. Ansonsten genießt den Tag.

Wolfi Gassler (00:50:37 - 00:50:37)

Viel Spaß!