#134 Wir profitieren, sie leiden: Die Schattenseiten von Open Source

Open Source: Die schöne heile Welt - Oder doch nicht?

Doch in der Realität sieht es oft ganz anders aus. Wenn mal wieder einer der Open Source Incidents in die Tagesschau geschafft hat, wird das ganze Set an Problemen, die es in der Maintainership von Open Source Projekten gibt, sichtbar. Und genau darüber geht es in dieser Episode.

Wir klären, welche Probleme es beim Maintainen von Open Source gibt, warum diese nur auf wenige Schultern verteilt sind, aber Milliarden Menschen vom positiven Open Source Output profitieren und welche Lösungen es dafür gibt. Viel Spaß.

Bonus: Viel Negativität auf wenigen Schultern verteilt.

**** Diese Episode wird von We Manage gesponsert.

Für Agenturen und kleinere Unternehmen ist es oft eine Herausforderung, ein vollständiges DevOps-Team aufzubauen. We Manage bietet DevOps und SRE as a Service an – passend für alle Projektgrößen. Ob als Unterstützung für bestehende Mitarbeiter⋅innen, damit diese in den Urlaub fahren können, oder als vollumfängliches Infrastruktur-Team mit optionaler 24/7-Bereitschaft. We Manage ist der ideale Partner für Digitalunternehmen, Startups und Agenturen, die auf der Suche nach finanziell vernünftiger und robuster Infrastruktur sind. Mehr Infos findest du unter https://engineeringkiosk.dev/wemanage

****

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:00:57) Die positive Energie rund um Open Source

(00:07:19) DevOps & SRE as a Service (Werbung)

(00:08:42) Die positive Energie rund um Open Source

(00:25:44) Full-Time-Open-Source: Ein Platz auf dem Schleudersitz?

(00:32:51) Gute Arbeit vs. Miete zahlen vs. Bugs für andere zu beheben

(00:48:18) Business-Customer-Relationship

(00:54:39) Als Firma etwas zurück geben

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

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

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

Die meisten sprechen über Open Source mit einem positiven Mindset. Die Kultur ist einzigartig. Leute, die sich noch nie gesehen haben, arbeiten zusammen an etwas Großem. Als Anwender ist man oft beeindruckt, was für eine großartige Software allein durch freiwillige Arbeit erschaffen und auch bereitgestellt wird. Doch in der Realität sieht es oft ganz anders aus. Wenn mal wieder einer der Open Source Incidents es in die Tagesschau geschafft hat, wird das ganze Set an Problemen, die es in der Maintainer Ship von Open Source Projekten gibt, sichtbar. Und genau darum geht es in dieser Episode. Wir klären, welche Probleme es beim Maintainen von Open Source Software gibt, warum diese nur auf wenige Schultern verteilt sind, aber Milliarden von Menschen vom positiven Open Source Output profitieren und welche Lösungen es dafür gibt. Viel Spaß. Ÿousand einmal, die die Frage stelle, wie viel % deiner eingesetzten Software kommerziell bzw. Open source sind. Was würdest du schätzen, welchen Prozentsatz von Open Source dafür hast du so im Einsatz, so im Lifestyle, so im Business, so einmal komplett durch dein Leben?

Wolfi Gassler (00:01:16 - 00:01:19)

Durch mein komplettes Leben. Das ist jetzt schwierig.

Andy Grunwald (00:01:20 - 00:01:47)

Also jetzt, ich will jetzt nicht wissen, ob du vor fünf Jahren mal irgendwie einen Open Source Image Viewer genutzt hast, sondern wenn du heute auf deine genutzte Software guckst, ohne die du jetzt nicht mehr leben könntest, sowas, dass du tagtäglich nutzt, dein Mail Client, dein Betriebssystem und so weiter. Und ich möchte jetzt auch nicht den proprietären Grafikkartentreiber, den du bei Linux nachgeladen hast, über irgendein Source Repository, weil der sonst von Nvidia nicht funktioniert. Das interessiert mich jetzt eher weniger, sondern so im groben.

Wolfi Gassler (00:01:47 - 00:01:51)

Ja, überlege eher, für welche Software ich überhaupt noch zahle.

Andy Grunwald (00:01:51 - 00:01:59)

Also sind wir dann eher so im ein bis zwei, also eins bis 2 % für proprietäre Software? Oder wie würdest du einschätzen, wenn man.

Wolfi Gassler (00:01:59 - 00:02:31)

Es auf die Zeit runterbricht, wie viel ich die Software verwende, dann wird es wahrscheinlich schwierig, irgendwelche zu finden, weil es gibt natürlich gewisse Hosting Services oder Mail Services, was halt dann wirklich Hosting bedeutet, wo dann auch etwas passiert. Aber klassische Software, bin ausnahmslos in Linux unterwegs. Mein Android Phone ist im Prinzip vollkommen open source. Alles passiert auf open source. Klar wird da immer irgendwo was drüber gebaut, aber auch da habe ich sehr wenig Software, für die ich auch zahle. Die eine oder andere App. Also ich würde mal sagen, sicher im einstelligen Prozentbereich.

Andy Grunwald (00:02:32 - 00:02:48)

Jetzt bist du ja auch Freelancer und Berater und hast natürlich Einblicke in kleine mittelständische Unternehmen, vielleicht sogar noch in einem größeren Unternehmen. Wenn du die gleiche Frage dann auf so ein Unternehmen anwenden würdest, was würdest du mal aus dem Bauch heraus sagen, wie viel % open Source haben die so im Stack?

Wolfi Gassler (00:02:48 - 00:03:30)

Jetzt hast du schon Stack dazu gesagt, ist das natürlich eine fiese Frage, weil Stack ist auch alles darunter Zweitausendein. Das macht es natürlich etwas schwieriger jetzt abzuschätzen, aber es kommt auch ganz auf die Firma drauf an. Es gibt wirklich Firmen, die haben sehr viel Open Source im Einsatz und setzen wirklich stark auf Open Source. Und dann gibt es natürlich die Windows Buden, wo alles irgendwie nur von Windows kommt, wobei auch da dahinter natürlich extrem viel Open Source liegt. Aber kommt also wirklich darauf an. Und ich glaube, es gibt natürlich Firmen und umso größer es wird, umso professioneller es wird, umso kritischere Bereiche es betrifft, musst du dann gewisse Standardisierungen haben. Und da kommst du dann teilweise um kommerzielle Lösungen gar nicht rum, weil dir sonst die ganzen Standardisierungen fehlen und Zertifizierungen.

Andy Grunwald (00:03:30 - 00:03:42)

Okay, nehmen wir mal das Zertifizierungsfeld irgendwie raus. Wenn ich dir jetzt so zuhöre, würde ich meinen, dass du über Open Source sehr positiv nachdenkst, oder?

Wolfi Gassler (00:03:42 - 00:04:25)

Grundsätzlich über das Konzept? Open Source denke ich natürlich extrem drehen positiv nach und es wäre eigentlich cooler, wenn es viel mehr Open source gäbe und wenn z.B. alle öffentlich finanzierte Software einfach automatisch Open Source wäre, wäre genial und würde wahrscheinlich auch viel bewegen. Also das Konzept grundsätzlich, die Idee, Open Source mal überhaupt frei zur Verfügung zu stellen oder den Source frei zur Verfügung zu stellen. Also ich spreche jetzt gar nicht über Lizenzen, weil es beschweren sich sicher wieder Gott und die Welt bei mir, dass irgendwelche Lizenzen und Free Software und Open Source durcheinander gebracht wurden. Aber ganz allgemein Zugriff auf den Source zweitausendein und selber mal reinschauen zu können und vielleicht auch zu lernen, das ist schon extrem cool. Und ich finde es eigentlich schwach, dass es immer noch öffentliche Gelder gibt, die so stark in kommerzielle Software fließen.

Andy Grunwald (00:04:25 - 00:04:30)

Über das Movement public money, public Code. Müssen wir auch mal eine Episode machen, schreibe ich mir direkt mal auf, dass.

Wolfi Gassler (00:04:30 - 00:04:39)

Wir, vielleicht können wir uns da mal jemanden einladen, der in dem Movement noch tiefer drin ist und uns erklären kann, auch warum die Länder das weniger machen oder gar nicht machen wollen.

Andy Grunwald (00:04:39 - 00:04:49)

Machen wir aber du hast gerade einen Punkt nämlich schon genannt, aus Sicht des Anwenders, und zwar, klar, kostet nichts, ist gratis. Du hast gesagt, quelloffen in Anführungszeichen.

Wolfi Gassler (00:04:49 - 00:04:53)

Ja gut, da kann man ja auch drüber streiten, ob es nichts kostet, aber gut, gehen wir mal davon aus, monetär.

Andy Grunwald (00:04:53 - 00:05:48)

Ist das für den Anwender erstmal gratis. Ja, so vom Haus aus. Aber du hast auch gesagt, quelloffen, die Software hat keine Geheimnisse. Und das, was ich immer beobachte als Anwender, als Admin, als Operations, als eine Firma oder vielleicht auch als Hobby ist, viele Leute legen einen enorm hohen Wert darauf, dass sie es verändern können, wenn sie möchten. Obwohl 0,05 %, das ist jetzt eine Assumption, ich habe keine Daten, es niemals ändern werden. Ist das auch schon mal so bei dir vorbeigekommen? Also ich habe früher, als dieser Android versus iPhone Hass da war, ja, aber auf meinem Android Telefon kann ich alles ändern. Ja, zweitausendein. Und dann habe ich gefragt, machst du es denn auch? Und dann fingen alle immer an zu stottern. Also ich finde es faszinierend, dass sie allein die Möglichkeit zu haben, alles zu ändern, einen enorm hohen Stellenwert hat. Hast du sowas schon mal beobachtet?

Wolfi Gassler (00:05:49 - 00:06:46)

Ja, ich würde sagen, gerade im professionellen Umfeld ist es natürlich auch ein sehr wichtiges Argument und schlagendes Argument, weil es gibt ja auch ganz viele Firmen, die sich z.B. den Source Code geben lassen oder vielleicht irgendwie einen Zugriff vereinbaren, wenn z.B. die Firma hinter der kommerziellen Software dann mal pleite gehen sollte, dass man trotzdem irgendwie Zugriff auf den Source Code hätte. Und da geht es immer um das hätte. Also das ist auch, wenn du mit mit Risikomanagement in dem Bereich mal vordringst, hat es einen klaren positiven Wert für eine Firma und für die Nachhaltigkeit. Im privaten Umfeld ist das natürlich alles wieder ein bisschen anders. Ich hatte mal ein alternatives Android System, bis es mir zu viel wurde und zu anstrengend und die Hälfte nicht funktioniert hat und die Updates und so weiter und dann bin ich wieder zurückgewechselt. Aber ich hatte das auch mal ÿousand. Aber es fühlt sich vielleicht einfach gut an, wenn man die Möglichkeit hat überhaupt. Also wie viele Leute haben irgendein Abo, weil es sich gut anfühlt und verwenden tun sie es nie. Ich zahle auch ein Netflix Abo, verwenden tue ich es nie, verwendet nur meine Family.

Andy Grunwald (00:06:46 - 00:07:00)

Das haben wir nicht gehört und auch nicht ausgestrahlt, denn das ist inzwischen verboten. Wie dem auch sei, wie würdest du das denn aus der Sicht von Software Engineers sehen mit Open Source? Positiv, negativ? Wir haben jetzt gerade aus der Anwendersicht gesprochen.

Wolfi Gassler (00:07:01 - 00:07:19)

Nachdem es Open Source immer noch gibt, würde ich es im Großen und Ganzen schon auch positiv sehen, weil sonst würde ja niemand mehr Open Source Software schreiben. Also es muss, was netto unterm Strich dann übrig bleibt, muss scheinbar zumindest für viele Personen noch irgendwie positiv sein. Gott sei Dank, weil sonst hätten wir keine Open Source mehr.

Andy Grunwald (00:07:19 - 00:09:13)

DevOps und Infrastruktur wird immer komplizierter. Stell dir einfach mal vor, du kannst dich auf dein Kerngeschäft konzentrieren, während dein Infrastruktur Team für dich da ist und sich um deine Infrastruktur kümmert und diese auch noch optimiert, um Kosten zu sparen. Wäre das nicht Knorke? Genau das bietet dir unser Episodensponsor Wemanage mit seinem DevOps und SRE as a Service als Partner im Tandem mit Agenturen, deinem bestehenden Infrastruktur Team oder als vollständiges SRE Team. Wemanage ist dein Partner für Betrieb und Skalierung. Zahlreiche Firmen zweitausendein setzen bereits auf weManage und nutzen nicht nur den Support, sondern lassen sich auch komplette Cloud Wechsel zur Kostenoptimierung von wemanage planen und umsetzen. Dazu zählen unter anderem Firmen wie die MyDeals Tochter Abo, die größte Fotobox Vermietung in Europa, crew com, die Sneakersuchmaschine everysize com oder auch FC Bindestrich de btw. Für mich als Fußball Noob unglaublich, dass eine solche Seite pro Monat 9 Millionen User erreicht. Wenn du also auf der Suche nach einem Partner bist, der dir hilft, deine Infrastruktur zu optimieren und zu betreiben, dann schau dir mal wemanage an. Alle infos findest du auf engineering kiosk, dev slash wemanage oder natürlich in den Shownotes. Und nun geht's weiter mit der Episode viel Spaß. Ich hab mir mal ein bisschen Gedanken gemacht, wie ziemlich viele Software Engineers open source sehen, beziehungsweise zweitausendein. Ich habe über die Frage nachgedacht, warum wollen so viele Softwareentwicklerinnen mal zu open source contributen, wenn sie das noch nicht getan haben? Ich höre fast wöchentlich, entweder aus Online communities oder aus der Firma oder aus benachbarten Firmen oder Meetup Treffen ja, ich würde gerne mal zu Open Source contributen, ich weiß aber nicht, wo ich starten soll und ich weiß nicht, welches Projekt und so weiter. Und ich habe mir ein bisschen Gedanken gemacht über die warum ist das denn so?

Wolfi Gassler (00:09:13 - 00:09:17)

Du meinst, warum alle Contributen wollen oder warum sie es dann nicht machen?

Andy Grunwald (00:09:17 - 00:09:20)

Zweitausendein, was deren Kernmotivation ist, warum wollen sie kontributen?

Wolfi Gassler (00:09:20 - 00:09:25)

Und was hast du rausgefunden, wie du da eine Nacht schlaflos im Bett gelegen bist und dir den Kopf zerbrochen hast?

Andy Grunwald (00:09:25 - 00:09:29)

Nein, ich habe ja einen Labrador und deswegen gibt es mindestens.

Wolfi Gassler (00:09:29 - 00:09:30)

Schlafst du sowieso nie?

Andy Grunwald (00:09:30 - 00:10:30)

Ich schlafe nie, ne. Deswegen gibt es ziemlich viele Hunderunden und ab und zu habe ich keine Lust auf Podcasts. Und dann denke ich über sowas nach. Und zwar bin ich zumindest für mich auf die Antwort gekommen, a dass die Leute Teil von etwas größerem sein wollen, beziehungsweise etwas zu etwas ÿousand größerem Contributen und dass man da auch kontributen kann. Ja, ähnlich wie ich kann es verändern, wenn ich möchte, dann. Aber ich tue es nicht. Dann das Open Source Contributen selbst ist natürlich mal was ganz anderes als der day to day Job. Zu Hause muss ich die muss ich die Wohnung putzen, mit dem Hund raus, mit dem Kind spielen. Auf der Arbeit schreibe ich immer wieder das Kontaktformular, was dann anhand eines Dropdowns eine e Mail irgendwo hinsendet. Oder vielleicht bin ich einen neuen Payment Anbieter an. Aber einen Bug in einem Open Source Projekt zu fixen, ist natürlich dann schon mal was anderes. Es macht dann Spaß. Und ein Punkt, den ich immer wieder höre, der, ich würde schon fast sagen, als falsch markiert werden kann, ist ein möglicher Karriereweg bzw. Ein sogenanntes Portfolio Building. Ja, man hört ja im Moment.

Wolfi Gassler (00:10:31 - 00:10:33)

Warum würdest du es als falsch markieren?

Andy Grunwald (00:10:33 - 00:10:57)

Naja, also der der Glaube, dass nur weil man ein tolles Gitterprofil im Lebenslauf hat, dass man, dass das sehr viele Interviewpunkte gibt, würde ich mal sagen, ist schon demystifiziert. Also ich habe mal das ein oder andere Interview gemacht, wo ich dann mal drauf angesprochen wurde Hey, du bist aber auch ganz schön aktiv auf GitHub. Finden war cool und auch das, was du da gemacht hast. Aber in der Maße der Interviews waren das keine 5, %, wo ich auf mein Gitterprofil angesprochen.

Wolfi Gassler (00:10:57 - 00:10:59)

Liegt vielleicht an deinem Gitterprofil, was sehr.

Andy Grunwald (00:10:59 - 00:11:01)

Aktiv ist, muss ich zugeben.

Wolfi Gassler (00:11:01 - 00:11:10)

Aber naja, wenn du ein sehr populäres GitHub Repo hast oder eine App, dann finde ich, ist das schon ein Pluspunkt sowas.

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

Wir reden aber jetzt gerade über das Profil und das ist ja klar, wenn.

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

Du jetzt nur kleiner Contributor bist oder so oder aber dafür viel contributest, ist es natürlich doch noch mal was anderes. Kann aber auch als positives Signal gewertet werden und würde ich zumindest als Interview in irgendeiner Form positiv werten. Hilft dir halt nichts, wenn der Rest nicht passt und nicht stimmt. Ist klar. Aber bist du fertig mit deiner Liste?

Andy Grunwald (00:11:32 - 00:12:11)

Ich bin fertig, wollte aber noch kurz sagen, dass aus irgendeinem Grund und den habe ich für mich noch nicht beantwortet, open source irgendwie was magisches aus der Sicht von Software Engineers hat, zumindest für die, die noch nicht zu open source contributed haben, die noch nicht Teil dieser kompletten Welt sind. Und neben diesen paar Punkten, die ich jetzt aufgelistet habe, fällt dir da noch einer ein? Weil irgendwie was macht die ganze Sache so magisch? Also ist für mich ist das ähnlich wie gerade mit dem Android Phone, was ich dir gesagt habe. Die Leute haben die Möglichkeit, ihre Software zu verändern. Ein ganz, ganz kleiner Teil macht es, aber allein die Möglichkeit zu haben, ist schon dieses Exploding Head Emoji.

Wolfi Gassler (00:12:11 - 00:12:54)

Jetzt gehst du ja ganz viele hunderunden, wie du erklärt hast und da denkst du über solche Sachen nach. Das mache ich ja auch hin und wieder, wenn ich so am Berg bin. Und wenn mir dann die Podcasts ausgehen, fange ich an, mit ChatGPT zu sprechen. Seitdem man da ein Audio Interface hat, kann man ja direkt die Fragen stellen. Das habe ich jetzt natürlich im Hintergrund mal gemacht. Bereite mich ja perfekt vor, während du sprichst in dem Fall. Da kommt vor Lernen und Weiterentwicklung, Gemeinschaft und Netzwerk, Ruhm und Anerkennung. Das ist so ein bisschen, was du auch erwähnt hast. Karrierechancen, also persönliche oder berufliche Vorteile, Selbstverwirklichung, Ethik und Philosophie. Also diese offene Software, dieses Movement überhaupt zu fördern, ist sicher auch ein guter Punkt.

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

Das hatte ich ja gesagt, mit Teil von etwas Großem zu sein vielleicht.

Wolfi Gassler (00:12:58 - 00:13:15)

Genau, oder vielleicht halt einfach überzeugt sein, dass Open Source cool ist, der direkte Nutzen, also wenn man einen eigenen Bedarf hat, weil man die Probleme einfach lösen will, in irgendeinem speziellen Fall, in einer speziellen Library, zweitausendein und einfach aus Spaß und Leidenschaft, Hobby sozusagen.

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

Dieses Hobby kann ich ja schon fast so gleichsetzen mit etwas anderes machen als der day to day Job.

Wolfi Gassler (00:13:21 - 00:13:39)

Ihr habt dann auch noch gefragt, was sind die magischen Punkte? So wie du das gefragt hast, da kommt leider nicht sehr viel Gutes raus. Das unendliche Wachstum findet ChatGPT sehr magisch. Also vielleicht ist doch der Andy mit seiner Hunde Runde noch besser geeignet als ChatGPT. Aber ein paar gute Punkte sind auf jeden Fall dabei, würde ich sagen.

Andy Grunwald (00:13:39 - 00:14:20)

Und wenn wir die Frage jetzt mal umdrehen, im Trash TV wird man sagen, lass mal Real Talk machen. Dann müssen wir natürlich auch über die negativen Seiten sprechen. Und hier ist auch wieder was faszinierendes, zumindest habe ich was faszinierendes festgestellt. Die negativen Seiten von Open Source betreffen die Maße eigentlich gar nicht. Denn die negativen Seiten von Open Source bekommen eigentlich nur eine ganz, ganz kleine Gruppe, und zwar die Open Source Projekt Maintainer zu spüren. Und das ist ja eigentlich unglaublich schade, dass du positive Elemente, wie wir gerade sie genannt haben, auf fast die Maße, 99 Komma weiß ich nicht, wie viel % der Leute, die Open Source nutzen, anwenden, aber die negativen Seiten auf eine ganz kleine Anzahl an Leuten gehen.

Wolfi Gassler (00:14:20 - 00:14:46)

Also nur der Vollständigkeit halber, es gibt natürlich schon auch andere negative Punkte, die man so hin und wieder mal hört von der Open Source Nutzungs Seite, gerade wenn es im Vergleich zum kommerziellen Bereich geht, dass man da den Source lesen kann, dann man kann dann mehr manipulieren, findet die Bugs und so weiter. Und das würde bei kommerziellen Closed Source varianten nicht der Fall sein. Ich glaube, wir sind alle der Meinung, dass das Bullshit ist, aber nur, dass es mal erwähnt ist.

Andy Grunwald (00:14:46 - 00:14:50)

Ich wollte schon sagen, du sprichst dich hier nicht gerade für security by obscurity aus, oder?

Wolfi Gassler (00:14:50 - 00:15:23)

Ja, dass es glaube ich passieren kann, braucht man nur auf die vielen Blue Screens schauen, die Crowdstrike kürzlich verursacht hat. Also ich glaube, das ist gerade wieder aktuell der neueste Beweis dafür, dass dass es komplett egal ist, ob Closed oder Open Source und das Open Source wahrscheinlich noch besser ist, weil es mehr Leute dann zu Gesicht bekommen und überhaupt Fehler finden können. Aber das ist eine andere Diskussion, da wollen wir gar nicht ins Detail gehen. Aber dir geht es primär um die negativen Auswirkungen von Open Source, die eine kleine Benutzergruppe erfährt, und zwar die, die Open source machen.

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

Genau. Und dabei geht es mir jetzt nicht um die negativen Seiten der Software selbst, wie es gibt keinen kommerziellen Support oder sowas, Ÿousand, das ist ja, ich sag mal eher wirklich auf die Software selbst zu beziehen, sondern eher vielleicht so ein bisschen auch ein bisschen auf das Menschliche dahinter. Und wo du gerade Crowdstrike genannt hast, für Alle Leute, die es schon wieder vergessen haben, wenn diese Podcast Episode rauskommt, die haben Update gepusht und dann gab es den Bluescreen auf das an jedem Flughafen gefühlt Banken und so weiter. Und kurz danach, nachdem das passiert ist, hat Daniel Stenberg, das ist der Autor von Curl, meines Erachtens nach der meistbenutzten Software dieser Welt, Ÿousand auf Masalon geschrieben. Vielen dank Crowdstrike, dass ihr einmal bewiesen habt, dass Open Source nicht das Problem ist. Verlinken wir auch unten in den Show Notes. Aber nee, ich meine, natürlich gibt es ein paar seltene, ich sag mal Big White Events, ja, die zur Sichtbarkeit der negativen Seiten von Open Source beitragen. Ich glaube zuletzt haben wir, hatten wir davon so ein paar, die xz Backdoor, Lock for J und Heartbleed. Ich glaube, das waren alles drei Sicherheitslücken, die sogar in die Tagesschau geschafft haben oder teilweise sogar in die Bild. Da gab es ja die Headline Deutscher rettet das Internet bei der Exact Backdoor. Schade, schade, schade. Aber was diese weit Sichtbarkeit immer hat, ist das immer sehr oberflächlich beschrieben. Klar, wie willst du solche technischen Details an die Maße in der Bild oder in der Tagesschau transferieren? Und die tiefe Analyse des eigentlichen Problems zweitausendein fehlt halt. Ja. Und immer wenn sowas dann kommt, dann also so ein großes Event, dann sind ganz, ganz viele Leute sauer wegen ganz viel ungeplanter Arbeit. Ich kann mir schon vorstellen, das habe ich auch selbst schon erlebt, in Firmen, wo der Betrieb, die Betriebsabteilung, die Systemadministratoren sagen, boah, die Open Source Nerds können wir da alle nicht richtig programmieren, weil die eine Sicherheitslücke gefunden wurde und dann man alles updaten musste und so weiter. Und das findet jetzt natürlich hinter geschlossenen Türen statt. Aber ja, das ist ein bisschen schade. Hast du auch schon mal sowas erlebt oder zumindest mitbekommen? Oder hast du schon mal über Leute im Open Source gemeckert, die nicht richtig programmieren können, weil du ungeplante Arbeit hattest.

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

Um diese Administratoren in Schutz zu nehmen? Ich glaube, die jammern auch, wenn Microsoft irgendein Bullshit baut. Also wahrscheinlich jammert man immer, aber die Frage ist es ja auch, ob man es öffentlich oder hinter verschlossenen Türen macht, wie du sagst. Und das ist natürlich oft das Problem, weil ich komme natürlich bei Microsoft gar nicht direkt an die Developer, die es betrifft, weil da sind einfach fünf Support Level dazwischen. Aber bei einem Open Source Projekt kann ich auch direkt auf GitHub gehen und mich in dem Issue auslassen oder auf Twitter, dass es jemand liest, weil ich direkt die Leute, die die Autoren oder Autorinnen ansprechen kann. Und das ist natürlich ein großes Problem, weil ich habe nicht mehr diesen Schutz oder diese Mauer, die ich in einer Firma habe, im kommerziellen Umfeld, wo meine Entwickler innen geschützt sind. Und da habe ich einen direkten Zugriff und kann halt direkt die Bomben werfen.

Andy Grunwald (00:18:16 - 00:18:56)

Als wer ist abgesprochen? Hast du mir gerade die perfekte Überleitung gegeben? Und zwar ein weiterer negativer Punkt, den oft auch nur die Projektmantainer kriegen, den die meisten gar nicht sehen und der vielleicht implizit bei uns allen schon irgendwie festsitzt. Wie du sagtest, ein Open Source Projekt startet man in der Regel in seiner Freizeit, weil es Spaß macht, was zu programmieren oder weil man sein eigenes Problem löst. Die Realität ist jedoch, dass es aus irgendwelchen Gründen so eine Art Business Customer Relationship gibt zwischen Open Source anwendern, die dann etwas von dem Maintainer erwarten, der soll den Bug fixen oder sowas, weil die nutzen ja Open Source und rendern irgendeinen Fehler und irgendwie hat sich das so etabliert. Also ganz, ganz komisch.

Wolfi Gassler (00:18:57 - 00:19:35)

Es gibt ja auch das Beispiel von Daniel Stemberg, weil du uns schon erwähnt hast, der hat da ja auch super viele Geschichten auf Lager, wo ihn dann Leute irgendwie, also Firmen, die ihm dann irgendwie so für Curl irgendwelche Formulare geschickt haben. Kannst du das beim bitte ausfüllen, ob Curl die Sicherheitsstandards erfüllt? Und kannst du bitte das, wir brauchen das für irgendein Audit. Und als wenn es irgendwie selbstverständlich wäre, dass er als Autor irgendwie jetzt haftbar ist für alles und und auch alles machen muss, was da an Arbeit irgendwo bei Firmen irgendwo eingekippt wird, bekommt er dann dreiig seitiges Formular, bitte füll das mal aus für uns. Und die Firmen erwarten sich, dass er das irgendwie als Open Source Maintainer macht.

Andy Grunwald (00:19:35 - 00:20:10)

Zweitausendein, den Link zu dem Talk, den der Wolfgang gerade erwähnt, verlinken wir auch. Hat er auf der diesjährigen Frost gehalten. Aber auch das, was du gerade gesagt hast, ist so eine negative Seite, die vielleicht man auch als Anwender mal spürt, diesmal nicht nur als Maintainer. Und zwar der professionelle Support ist halt nicht da. Und was halt wirklich, auf gut Deutsch gesagt, beschissen ist, wenn man auf der anderen Seite des Tisches sitzt als Anwender, ein kritisches Problem hat und dann man kann es nicht selbst beheben aus irgendwelchen Gründen. Fehlende Skills, fehlende Zeit oder ich weiß es nicht. Und man kann sich dann keine Unterstützung einkaufen. Das ist einfach.

Wolfi Gassler (00:20:10 - 00:20:14)

Wie machst du das als Open Source Maintainer? Du hast ja auch viele Repositories.

Andy Grunwald (00:20:14 - 00:20:27)

Ja, herzlichen Glückwunsch. Deswegen habe ich eine Lizenz, da steht das dann drin, dass ich die Software frei zur Verfügung stelle, aber sie ist as is in use und ich habe keine Probleme damit, wenn das Bugs hat und So. Oder meinst du, wenn ich angefragt werde? Zweitausendein?

Wolfi Gassler (00:20:27 - 00:20:34)

Genau, wenn du ein Issue reinbekommst und keine Ahnung, wegen quasi Support oder irgend sowas in der Richtung.

Andy Grunwald (00:20:34 - 00:21:21)

Ich habe schon ein paar mal bekommen, auch Leute mit einem etwas stärkeren Ton, würde ich mal sagen, und auch mit Schimpfwörtern. Leute machen ein Ticket auf, sagen, meine scheiß Software funktioniert nicht und dann hatten die einen Bug, aber sie ist ganz wichtig, weil sie brauchen es und so weiter und so fort. Dann versuche ich immer ruhig zu bleiben. Also wenn ich das Issue lese, gehe ich dann erstmal eine Runde hier um meinen Schreibtisch und ich antworte nicht direkt. Ihr kennt das, wenn man aufgebracht ist, weil es ist natürlich hart respektlos, aber was ich oft mache, ja, Vielen Dank für das Ticket. Ach so, diese Leute geben dir natürlich keinerlei Information, was für ein Bug oder welches System oder irgendwie sowas. Die sind nur sauer und dann bitte ich immer darum, dass sie mir eine E Mail schreiben sollen, dann kann ich ein Angebot zurückschicken, wie ich dann professionell helfen soll. Und siehe da, dann ist stille. Also ich biete konventionellen Support in dem Ticket an, auf Basis eines Angebots und Ÿousand, dann ist meist Ruhe.

Wolfi Gassler (00:21:21 - 00:22:17)

Das ist ja auch immer super spannend. Es würde ja niemand auf die Idee kommen, dass Microsoft dir kostenlos hilft bei einem deiner Probleme. Oder Oracle, du hast ein Datenbankproblem mit deiner Oracle Datenbank, würde niemand erwarten, dass du Support bekommst, ohne dass du auch zahlst für den Support. Wobei jetzt gar nicht bei Oracle weiß, ob das möglich ist, ohne Support was einzukaufen bei denen. Aber bei Open Source ist es irgendwie normal. Oder man kann auch mal einen Bug einwerfen und sagen, der ist super wichtig. Bis wann wäre denn das möglich? So in der Richtung. Also ich antworte immer auch gern, wenn es so wichtig ist, kann man gerne über eine Implementierung sprechen, die dann kostenpflichtig ist und sonst was ich halt immer gerne zurückwirft, ist ja gar kein Problem, ist ein gutes Feature. Z.B. ich kann dir gern auch paar Anknüpfungspunkte geben, wie man das implementieren könnte, wo, an welcher Stelle und falls Hilfe benötigt ist für einen Bull Request, gar kein Problem, einfach melden und dann ist meistens auch stille.

Andy Grunwald (00:22:18 - 00:22:35)

Aber genau das meinte ich ja mit dieser, ich sag mal unsustainable business customer like relationship. Also die Leute, die Anwender erwarten etwas wie von einer professionellen Firma, dass man dann da ist und so weiter, obwohl die komplette Software gratis ist und sie frei zur Verfügung gestellt wird. Aber Geld ist ja schon ein gutes Problem.

Wolfi Gassler (00:22:35 - 00:22:38)

Geld ist ein gutes Problem. Du hast es ein richtiger fast schon.

Andy Grunwald (00:22:38 - 00:22:53)

Ja, Geld ist ein gutes Problem. Zweitausendein. Ja, oder es ist leider notwendig in unserer heutigen Gesellschaft und wie sagt man so schön, open Source zahlt in der Regel keine Miete, beziehungsweise Open Source bugs beheben zahlt in der Regel keine Miete.

Wolfi Gassler (00:22:53 - 00:22:59)

Außer du hast einen sehr offenen Mieter. Also das wäre natürlich cool mal für Open Source auch Unterkunft zu bekommen. Gibt es vielleicht auch.

Andy Grunwald (00:22:59 - 00:23:11)

Ja. Aber in der Regel, wenn ich jetzt irgendwie meinem Open Source Projekt als Maintainer Bugs fixe, dann kriege ich ja kein Geld. Von wem denn auch? Weil natürlich gibt es Leute, die werden angestellt, um an Open Source zu arbeiten.

Wolfi Gassler (00:23:11 - 00:23:51)

Das wollte ich jetzt gerade sagen. Also es gibt sehr und wir können es gerne auch verlinken, da gibt es gibt Statistiken dazu, dass ja wirklich ein sehr großer Teil, ich glaube weit über 50 % des Open Source Codes eigentlich kommerziell, also nicht kommerziell entwickelt wird, aber eine kommerzielle Firma dahinter steht. Wenn du anschaust Git z.B. git wird schon lange nicht mehr so vom Linus Dorfwalds oder so entwickelt, sondern der haupt Entwickler ist bei Google angestellt z.B. also die ganzen großen Firmen, klar auch so Open Source Firmen wie Red Hat, die die machen natürlich extrem viel, aber auch Microsoft natürlich, die haben alle Angestellte, die auch sehr viel zu Open Source Contributen, muss man schon, muss man schon sagen.

Andy Grunwald (00:23:51 - 00:24:32)

Man muss aber auch sagen, ja, das was du gesagt hast, da packe ich mal oben so ein Sternchen hin. Wenn eine Firma in Open Source arbeitet, dann haben die dahinter eine Roadmap und eine Intention. Die seltensten Firmen stellen Leute an, Och, du arbeitest heute mal an dem Zweitausendein, an der Go Client Library für Jira, wenn sie kein Atlassian Partner sind. Das bedeutet, dahinter ist immer in irgendeiner Art und Weise eine Strategie. Und das bedeutet aber auch, dass nicht jeder Pull Request accepted wird oder nicht immer das Projekt als Ganzes nach vorne getrieben wird, sondern das Projekt ab und zu, ich sage nicht immer ab und zu, in die Richtung der Firma dann auch getrieben wird.

Wolfi Gassler (00:24:32 - 00:25:01)

Auf jeden Fall. Ist ja, ist ja auch fair point. Aber man muss dazu sagen, die Firmen machen das wenigsten. Und die wenigsten Firmen stellen ihren Source offen zur Verfügung oder auch irgendwelche kleinen Libraries oder solche Sachen oder vielleicht sogar nur Contributions. Also ich finde, das ist schon ein Schritt in die richtige Richtung. Klar ergeben sich da dann auch Abhängigkeiten, natürlich, aber das hast du eigentlich bei allen großen Projekten, weil wenn da jetzt ein großer Maintainer dahinter sitzt, wie heißt dein Lieblings, der Anti Res von Redis früher?

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

San Filippo, Salvatore San Filippo, den wirst.

Wolfi Gassler (00:25:06 - 00:25:44)

Du nie vergessen, glaube ich. Mittlerweile ist er ja retired unter Anführungszeichen. Aber wenn du solche Leute hast, natürlich, die entscheiden genauso die Roadmap in die eine oder andere Richtung. Also die entwickeln auch so, wie sie denken. Aber klar, bei einer Firma hast du noch mehr Abhängigkeiten. Und das große Problem bei einer Firma ist natürlich auch, wenn da sich irgendwelche Prioritäten ändern oder du musst gewinnbringender sein oder so. Google kann sich das natürlich leisten mit ihren, keine Ahnung wie viel, 10 Leuten oder Microsoft Ÿousand. Aber wenn du eine kleine Firma bist, wird vielleicht auch mal dein Projekt einfach eingestampft. Oder auch bei Google vielleicht wird das Projekt eingestampft, dann ja, dann hast du plötzlich irgendwie deine fünf Hauptentwickler von dem Open Source Projekt verloren.

Andy Grunwald (00:25:44 - 00:26:46)

Genau, denn hier, das ist wieder ein negative Punkt an der ganzen Thematik. Toll, die Firma stellt Development Power zur Verfügung, aber wie contributet denn Open Source zum Business selbst? Denn wenn es der Firma schlecht geht, heißt es ja nicht immer, dass die Firma direkt bankrott geht. Weil das beste Beispiel ist Google. Google hat vor kurzem das interne Python Core Developer Team rausgeschmissen. Das war ein Team, was sich innerhalb von Google darum gekümmert hat, dass der Google Stack immer auf der neuesten Python Version lauffähig war. Und die haben natürlich auch ziemlich viel Python Features gebaut und blabliblub. Das bedeutet, was ich damit sagen möchte, nur weil du angestellt bist und Open Source machst, kann es in wirtschaftlich schwierigen Zeiten, wo wir gerade z.B. sind für ziemlich viele Firmen, für ziemlich viele tech Firmen auf einem sogenannten Schleudersitz sitzen und von Layoffs Ratzen fatz betroffen sein. Weil die Frage ist, was bringt eigentlich der Wolfgang, der da hinten in der Ecke die ganze Zeit an Open Search baut, zu meinem Business, zu meinem Revenue Driver? Und das ist natürlich dann immer eine schwierige Geschichte, weil in der Regel bist du dann der Erste, der weg bis oder einer der Ersten, kann auch einfach.

Wolfi Gassler (00:26:46 - 00:27:14)

Eine strategische Entscheidung sein, muss gar keine wirtschaftliche sein. Wir machen jetzt was anderes. Die Library ist nicht mehr wichtig. Geht ja uns allen selbst auch so. Ich habe ganz viel contributed Ÿousand, weil ich es halt persönlich gebraucht habe und irgendwann habe ich es dann nicht mehr gebraucht oder die Software nicht mehr eingesetzt und dann war ich weg. Also mein Repository, was am meisten noch Impact hat, verwende ich seit Ewigkeiten nicht mehr. Gott sei Dank habe ich einen neuen Maintainer gefunden, der mithilft und so weiter. Also sonst wäre das eh unmöglich.

Andy Grunwald (00:27:14 - 00:27:47)

Aber das ist der Punkt, auch wenn Open Source deine Miete zahlt, ist das ein unglaublich geringer Anteil der Leute. Denn du musst zusehen, wenn wir 100 % haben, wie viele Leute von diesen 100 % maintainen oder Contributen überhaupt zu open Source. Ist ja schon null irgendwas %. Und die Open Source Maintainer oder Contributor, die dafür noch vom Arbeitgeber bezahlt werden, ist dann noch mal ganz viel kleiner. Also wir reden hier gerade gefühlt über die eine ähnliche Quote wie Startups werden zu Unicorns.

Wolfi Gassler (00:27:47 - 00:28:06)

Ja, es kommt darauf an, von welcher Seite du das siehst. Also Anzahl der Open Source zweitausendein Lines oder oder wichtigen Projekte, da ist das natürlich ein sehr hoher Wert. Aber du hast natürlich recht, der Longtail und klar, so viele Leute wie in Open Source arbeiten, die Anzahl der Leute sind sicher höher, die nicht bezahlt werden, als die, die bezahlt werden.

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

Und kommen wir mal genau auf diese Anzahl der Leute zu sprechen, denn auch die haben Geldprobleme. Jeder hat Geldprobleme, ganz klar.

Wolfi Gassler (00:28:13 - 00:28:16)

Lass es uns mal Finanzierungsprobleme nennen.

Andy Grunwald (00:28:16 - 00:29:42)

Das bedeutet, jemand stellt einen Bug ein und als Maintainer fragt man sich, okay, habe ich diesen Bug denn auch? Kann ich den reproduzieren? Also dann, dann hat halt das Bugfixen halt eine niedrigere Priorität, weil es ist halt in deiner Freizeit. Natürlich gibt es dann hier und da ab und zu mal so Bounty Programme. Bounty Programme bedeutet, du einem Bug Ticket ein Bounty, also Geld, und wer das dann fixt, bekommt dann dieses Geld. Das ist die Grundidee, finde ich sehr lobenswert, in der Realität doch eher weniger bis gar nicht verbreitet, hat sich nie wirklich durchgesetzt, denn bei diesen ganzen ÿousand Programmen, auch GitHub Sponsors und Co. Schwingt natürlich immer so eine Thematik mit, wie, wo sitzt die Person denn, in welchem Land, von wo wird das Geld ausgezahlt? Ja, dann gibt es ja immer noch Finanzsanktionen mit Ländern wie Iran und Nordkorea und was weiß ich nicht noch alles. Also Auszahlung ist ab und zu ein bisschen schwierig, dann Versteuerung liegt dann auf der maintainer Seite, also der, der das auf das Geld bekommt, da haben auch sehr viele Leute einen Blocker und so weiter. Also im Endeffekt hat das dann immer so eine niedrige Priorität. Natürlich gibt es dann mögliche Lösungen, es gibt so Funding Initiatives und dass du irgendwie dein Business um Open Source aufbauen kannst, du kannst Berater werden für irgendwas. Und auch der Wolfgang hat ja schon mal bei so einer Funding Initiative mitgemacht, wie Media Tech Lab, GitHub Sponsors gibt es dann und so weiter. Aber so richtig habe ich das Gefühl, hat sich von diesen ganzen Plattformen noch nichts durchgesetzt, oder?

Wolfi Gassler (00:29:42 - 00:32:50)

Was man unterteilen muss, ist glaube ich eben diese, wenn man es jetzt mal bei 50 % anlehnt, und ich glaube, das ist so der aktuelle Stand, dass man so glaubt, 50 % der Open Source Entwickler sind bezahlt, dann betrifft es die restlichen 50. %. Und für diese 50 % eine Finanzierung zu finden, ist wahnsinnig schwierig. Und da ist meines Wissens auch eigentlich nichts, was sich bisher wirklich durchgesetzt hat. Ich war gerade jetzt auf der Via Developers Konferenz und da hat da einer der Co Founder von GitHub, OSs Pledge, vorgestellt, unter anderem, was er jetzt mit seiner neuen Firma auch machen will. Und zwar ist das so eine ethische Unterstützung von Open Source. Und was das besagt, ist, dass du für jeden Entwickler, den du angestellt hast oder Entwicklerin, fix $2000 pro Jahr spendest einfach. Und das einfach, das ist ein fix vorgegebener Betrag, aber du kannst sagen, okay, OSs Pledge, wir unterstützen das und wir bezahlen einfach so viel Geld fix an die Open Source Community. Was ich nicht genau weiß, ist, wie die das Geld verteilen, weil das ist ja eigentlich immer das größte Problem. Wie bekommst du das an die Leute, an die 50, %, die das auch wirklich brauchen? Weil wenn du natürlich große Projekte hast, wie React z.B. da sind teilweise Leute angestellt, die machen das teilweise Vollzeit, die haben teilweise auch schon sehr viel Geld von Sponsoren und was die z.B. ja auch sagen, ist, dass es uns eigentlich besser geholfen wäre, wenn wir Leute bekommen, die Open source programmieren, weil nur das Geld zu haben, bringt auch alleine nichts. Und dann gibt es halt ganz viele kleine Entwickler, die kleine Dev Tools schreiben, die vielleicht hinten irgendwo in der Pipeline während dem Entwickeln irgendwo verwendet werden und die sieht man vielleicht gar nicht, sind für React aber auch wichtig und die bekommen kein Geld. Und das ist natürlich super schwierig. Das einzige Konzept, was sie eben kennen, ist Thanks Dev, die das wirklich machen, dass das automatisiert an die Dependencies verteilt wird. Das ist so das einzige, weil die ganzen anderen, Tight Lift und lieber Pay, das sind halt einfach Spendenplattformen, wo ich mir ein Projekt aussuchen kann, aber dass das irgendwie automatisch an alle in der Dependency Kette verteilt werden, weil es geht eben um den Stack. Ich verwende ganz oben vielleicht Windows, was kommerziell ist, aber da sind ganz viele Open Source Libraries irgendwo im Hintergrund, die auch verwendet werden oder bei Android oder bei jeder beliebigen App, wenn man da mal reinschaut unter die Hilfe oder oder about Pages, da steht es oft drinnen, was alles für Lizenzen da in irgendeiner Form verwendet werden, weil darunter eben die ganzen Open Source Libraries auch mitverwendet werden. Und genau diesen Leuten, die sind meistens irgendwo im Hintergrund und die bekommen kein Geld, weil Xet, das war halt ein Maintainer und kein Mensch auf der Welt hat es wahrscheinlich irgendwie im Kopf, dass er Xset in irgendeiner Form in seinem Stack irgendwo verwendet, weil es gehört halt einfach dazu. Und genau um diese Leute geht es und denen müsste man in irgendeiner Form auch helfen, weil die kommerziellen Firmen, die sich da entwickeln und die Dual Licensing oder sowas machen, die betreiben das eh sehr professionell und für die gibt es vielleicht Lösungen, aber für Die ganzen kleinen, den Long Tail, die müsste man in irgendeiner Form unterstützen.

Andy Grunwald (00:32:50 - 00:33:36)

Und die sollte man nicht nur finanziell unterstützen, sondern auch auf eine ganz andere Art und Weise. Denn Leute, die nicht für Open Source Arbeit bezahlt werden, die haben Ambitionen, gute bzw. Perfekte Arbeit zu leisten, denn die eigene Arbeit ist public und für jeden sichtbar und man möchte ja kein schlechtes Bild auf sich selbst werfen. Man möchte eigentlich Referenzcode produzieren, best practices, man vielleicht sogar bugfree stolz auf etwas sein. Und ich meine, im Endeffekt, wenn du, wenn du Maintainer bist, ist es ja auch ein tolles Gefühl, ein Ticket zu bekommen. Ist egal, ob ein Bug oder ein Feature, weil summa summarum, jemand benutzt deine Software. Ich hatte, glaube ich, schon mal erzählt, wie toll ich mich immer fühle, wenn ich neues Projekt public setze und jemand macht ein Ticket. Wow, jemand kommt jetzt wieder die Geschichte.

Wolfi Gassler (00:33:36 - 00:33:37)

Dass du nackt durch die Wohnung.

Andy Grunwald (00:33:37 - 00:33:58)

Rennstausend wollte ich sagen. Ja, Wahnsinn, Wahnsinn. Das beste Gefühl einer Entwickler Entwicklerin. Nicht nackt durch die Wohnung rennen, sondern deine Software wird aktuell wirklich genutzt. Und es ist noch besser, ein noch besseres Gefühl, ein Pull Request zu bekommen, denn jemand hat sich die Mühe gemacht, zu deiner Software zu kontributen, das Dev Setup aufzusetzen und so weiter.

Wolfi Gassler (00:33:58 - 00:34:04)

Aber welche Pull Requests würdest du nicht so toll finden, wenn du einen bekommst? Gibt es irgendwelche Abstufungen?

Andy Grunwald (00:34:05 - 00:34:11)

Ah ja, natürlich. Also wenn es dann Pull Request ist, der vollkommen an der Grundidee meines Tools vorbeigeht. Also ich finde das trotzdem toll, dass.

Wolfi Gassler (00:34:11 - 00:34:13)

Er anderer Meinung ist, wolltest du sagen.

Andy Grunwald (00:34:14 - 00:35:27)

Andere Meinung, wohin das Projekt sich entwickeln sollte? Ja, das ist richtig, aber die andere Meinung muss ja nicht schlecht sein, nur nicht für mich. Aber wie dem auch sei, wenn jetzt ein Pull Request kommt, da kommt ja das große Dilemma. Und zwar musst du Zeit haben für die Implementierung. Du musst Zeit haben, um zu antworten. Und wie gesagt, was ist, wenn das Ticket oder der Pullcast nicht ins Tool passt? Du hast vielleicht sogar Angst vor Ablehnung von negativen Nachrichten, diese auszusprechen. So, du bist auf der einen Seite glücklich, da kommt was, jemand hat sich die Arbeit gemacht, aber auf der anderen Seite sagst du du, ich weiß, du hast 6 Stunden daran gearbeitet, aber ich werde es nicht merken. Und wenn du doch gar keine Zeit hast, drauf zu gucken, zu antworten, dann hast du immer noch im Kopf, ich muss noch, ich muss da noch antworten, ich muss da noch reingucken. Dieser innere Druck steigt ja schon so ein bisschen und klingt jetzt wie eine Floskel, aber das, was ich gerade erzähle, das ist realer Druck auf die Maintainer, der da vielleicht implizit ausgeübt wird, vielleicht ab und zu auch explizit, siehe die Exact Vector Lücke. Aber Burnout ist ein großes Problem für Open Source Software Maintainers. Und das ist einfach hart, weil du bist in diesem Dilemma, du freust dich, dass jemand deine Software benutzt, du willst helfen, hast aber keine Zeit, denn Bug fixen zahlt die Miete nicht und so weiter.

Wolfi Gassler (00:35:27 - 00:36:28)

Vor allem hast du ja niemanden, der mit dir daran arbeitet, üblicherweise, wenn du zumindest startest. Das heißt, du hast auch niemanden, mit dem du über diese Probleme unter Umständen sprechen kannst oder irgendwelche Triage machst oder keine Ahnung, in irgendeiner Form gemeinsam daran arbeitest. Das heißt, es gibt jemand von außen gibt dir ständig Issues rein und Arbeit rein, ohne dass das in irgendeiner strukturierten Form passiert. Und das kann natürlich wirklich dazu führen, dass man da zweitausendein dann wirklich Probleme bekommt. Und wenn man da nicht schnell genug versucht, dann Maintainer zu finden. Und es wäre ja nicht so, dass man da einfach mit den Finger schnippt und dann hast du einen Maintainer oder so, oder eine zweite Person gefunden, die dir da vielleicht hilft. Ist ja super schwer, jemanden zu finden. Und dann sind wir genau wieder bei dieser negativen Seite, die halt eine Person betrifft. Aber unter Umständen, wenn es dann zu einem Burnout oder zu einem Rückzug führt, kann es natürlich tausende Firmen oder wirklich einen super wichtigen Baustein in dem Stack betreffen, der weltweit verwendet wird. Aber was würdest du jetzt empfehlen, um dem irgendwie entgegenzuwirken?

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

Ja, auch da habe ich mir bei einer hunderunde Gedanken drüber gemacht. Also eigentlich ist die ganze Podcast Episode während mehreren Hunderunden entstanden. Das, was ich jetzt empfehle, empfehle ich nicht Leuten, die schon mal von Burnout betroffen waren, weil ich war noch nie von Burnout betroffen. Aber der dumme Rat, den ich gebe, ist, besser werden, es zu ignorieren. Mit S meine ich die E Mail, die ich von GitHub bekomme, dass ein Issue da ist oder ein neuer Pull request. Denn das ist jetzt eine eigene Story. Ich habe ganz viele Open Source Projekte, so 70 public repositories, 80. Und da von alten Libraries über neue Libraries Projekte, alles ist dabei. Und ab und zu kriege ich da Tickets und irgend. Ich habe eine ganze Zeit lang Bugs gefixt, eine ganze Zeit lang. Und irgendwann habe ich mich gefragt, warum fixe ich denn in meiner Freizeit Bugs für andere? Ÿousand, es ist doch open source. Und teilweise waren da auch Firmen bei, wo ich inzwischen weiß, dass die davon tausende Euro Profit machen oder sogar Ausfälle vermeiden. Also mal ein Beispiel. Ich habe meine Parsing Library für das Valve Data Format geschrieben, bei Counter Strike, Half Life und so weiter. Ihr kennt das, Steam, die Firma. Und diese Parsing Library wird bei einer der größten eSport Ligen der Welt eingesetzt.

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

Wer übrigens die ganze Geschichte hören will, Episode 42 haben wir nur darüber gesprochen.

Andy Grunwald (00:37:42 - 00:38:23)

Und ich habe auch den Go Client für Atlassian Gyra geschrieben. Und ich weiß, dass große Logistikfirmen wie Maersk, dieser container Schifffirma, diese container Schifffirma, wie nennt man das? Na, ihr wisst, was ich meine. Maersk. Dass die das einsetzen. Und irgendwann habe ich gedacht, warum sitze ich eigentlich zu Hause und fix bugs für die ohne Bezahlung? Und ich werde einfach besser, es zu ignorieren. Es tut mir zwar weh, aber das muss man dann leider sagen. Eine andere Geschichte ist, sich einfach mal bewusst zu werden, dass ihr als Open Source Maintainer niemandem etwas schuldig seid. Und da gibt es einen super guten Beitrag, einen Blogbeitrag, verlinken auch in den Show Notes, und zwar vom Homebrew Maintainer. Homebrew sagt ihr was? Package Manager für macOS.

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

Natürlich habe er lange genug Mac verwenden müssen.

Andy Grunwald (00:38:26 - 00:38:58)

Der hat ein riesen Blogpost geschrieben, grandioses Ding. Der sagt, Jungs, ihr schuldet niemandem was, ihr packt eure Freizeit hier rein, ihr packt die public Code auf GitHub oder GitLab und ihr lizenziert das ja sogar. Und das lustige ist, sogar die mit License und andere Open Source Lizenzen in einem ähnlichen Wording sagen eigentlich genau das, hey, niemand hat hier Anspruch auf irgendeinen Support oder wenn das deine ganze Infrastruktur löscht oder oder oder. Also das muss man sich einfach mal bewusst werden, ihr schuldet einfach niemandem was.

Wolfi Gassler (00:38:58 - 00:39:54)

Was mir auch persönlich immer geholfen hat, ist diese Klassifizierung der Issues, z.B. Ÿousand, das heißt, das kostet nicht viel Zeit, dass man einfach mal den Issue kurz durchliest und sagt, okay, das ist ein guter Issue oder irgendwie einfach eine Message schreibt, weil damit ist er irgendwie weg automatisch. Wenn man dann noch klassifiziert in Bug Issue, Feature Improvement, whatever, dann hat man irgendwie abgeschlossen. Dann kann man sagen, okay, ich habe den jetzt klassifiziert, ich habe dieses Ding abgeschlossen, es ist nicht mehr in meiner Queue drin, weil es ist jetzt in der Feature Request Queue drin oder in der Bug Queue drin und da muss ich jetzt irgendwie die Community drum kümmern und das liegt nicht mehr bei mir persönlich. Ich habe schon das wichtigste getan, ich habe ihn anerkannt, könnte wirklich ein Bug sein, braucht auch mehr Informationen, ist klassifiziert, er ist jetzt öffentlich verfügbar, damit sich jemand anderer darum kümmert. Und das hilft psychisch mir zumindest immer weiter, wenn man das einfach so eingeordnet hat und damit ist es weg aus der eigenen To Do.

Andy Grunwald (00:39:54 - 00:40:03)

Hast du dir eigentlich schon eine GitHub Action geschrieben, die dann sagt, wenn ein neues Issue erstellt wird, dann einfach so ein Würfel rollt und dann einfach aus drei Kategorien auswählt und dann eine ist Help Wanted.

Wolfi Gassler (00:40:03 - 00:40:13)

Ja, meine Projekte sind zu klein dafür, aber für größere Projekte wäre das vielleicht gar nicht so schlecht. Oder man lasst ChatGPT dann einfach das Ding mal vorläufig beantworten.

Andy Grunwald (00:40:13 - 00:41:29)

Eine andere Lösung, die heute vielleicht noch ein bisschen mit Vorsicht zu genießen ist, hat Felix Geisendörfer mal 2013 veröffentlicht mit seinem Blogpost the Pull Request Hack. Und zwar ist Felix ein unglaublich talentierter Softwareentwickler, ist inzwischen Senior Staff by Datadog, glaube ich, und ist auch sehr viel im Go Compiler unterwegs. Auf jeden Fall war er damals sehr viel im Node JS Environment unterwegs, hat super viele Node JS Packages gemacht. Und was er in diesem Blogpost beschreibt, ist die Arbeit, die ein Maintainer hat, auf mehrere Schultern zu verteilen. Und denn immer, er sagte immer, wenn oder ab und zu, wenn er ein Pull Request bekommen hat, hat er diese Person als Maintainer für das Projekt gemacht. Hat funktioniert ein paar mal. Wenn du das im Lichte der heutigen Zeit ein bisschen betrachtest, ist es glaube ich ein bisschen schwierig. Wir nehmen die exet Backdoor Supply Chain Attacken. Da gab es etliche Fälle, von wo Node JS Pakete übernommen werden und dann Schadcode eingefügt wurden. 2000 10:47 Uhr Jahren war eine andere Zeit, würde ich jetzt vielleicht so nicht mehr machen. Ist aber generell mal etwas im Kopf zu halten, sondern die Arbeit auf mehrere Schultern zu verteilen, sich vielleicht mehrere Maintainer zu holen, zu organisieren, was natürlich auch Arbeit ist, Leute zu umzustimmen oder die müssen auch ihre Freizeit opfern. Aber nun gut.

Wolfi Gassler (00:41:29 - 00:43:19)

Also was wichtig ist, ist glaube ich keine schlechte Idee, neue Maintainer zu suchen. Die schlechte Idee ist einfach allen Maintainer Schreibzugriff oder sowas zu gewähren. Aber wenn du das irgendwie skalieren willst und andere Leute an Bord nehmen willst, dann musst du irgendwie vertrauen. Und klar musst du versuchen, das möglichst nach bestem Gewissen zu machen. Und vielleicht, keine Ahnung, ich hatte damals mit dem einen Maintainer in einem Projekt halt ein Video Call gemacht. Das hilft dir schon mal die Person kennenzulernen, wie die Person tickt, wie die Person das einsetzt und so weiter. Das kann ja schon viel helfen, also dass man da halt nicht blind vertraut. Aber du musst natürlich irgendwo Vertrauen haben, sonst kannst du nie skalieren, sonst wirst du immer alleine bleiben. Solche Leute gibt es auch, aber ich glaube, das ist halt kein gutes Open Source Projekt fallen, wenn es dann größer wird. Und da muss man halt einfach abgeben. Aber das ist so wie in jedem Job oder wenn du, keine Ahnung, irgendwann lead wirst oder oder die Developer, musst du auch lernen abzugeben. Also das ist eine Fähigkeit, die man sowieso mal lernen zweitausendein muss. Und daran scheitert es auch oft, dass sich die dann irgendwie in die Haare kriegen und dann hast du einen neuen Fork und hast wieder zwei Projekte danach. Kann passieren, aber ich glaube, es geht halt nicht anders. Du musst es riskieren und möglichst gut machen. Aber es ist die einzige Möglichkeit. Also alleine, wenn man daran denkt, was machst du heute noch allein in jeder Firma heißt, du brauchst mindestens zwei Leute, dass einen Urlaub gehen kann. Du brauchst überall zwei Leute Backup. Also das wird überall gelebt, außer so im Open Source Bereich, wo man halt dann wirklich nur einen Maintainer hat. Und das wird aber teilweise dann irgendwie wie bei Xet weltweit eingesetzt. Und alleine wenn man sich das vor Augen führt, denkt was ich eigentlich ist, ist da irgendwas komplett falsch. Und sonst braucht man tausende Unterschriften in der Firma, um irgendwas einzusetzen und hunderttausend Supportverträge. Aber open source nimmt man gratis. Wenn es gratis ist, dann ist es schon okay und freut sich darüber, anstatt was zurück zu contributen.

Andy Grunwald (00:43:19 - 00:45:23)

Aber wenn ich jetzt mir mal deinen Rat zu Herzen nehme und das versuche ja, das bedeutet, ich versuche jetzt die Arbeit auf mehrere Schultern zu verteilen, dann komme ich ins nächste negative Problem, die ein Open Source Maintainer hat. Und zwar klassifiziere ich das als drive by contributor. Und hier die Story ist wie Onboarding von neuen Maintainern ist sehr, sehr zeitintensiv. In der Regel hast du vielleicht sogar Dokumentation, die hilft zwar sehr, aber die wenigsten Leute haben den eigenen Antrieb und die eigene Ambition, sich da durchzukämpfen. Du hättest mal ein Problem. Fragen ist halt einfacher als in den Source Code zu gehen und das selbst zu debuggen, weil irgendwann denkst du dir, das kann ja nicht so kompliziert sein, hier 3 Stunden mein Dev Setup für eine kleine Library aufzusetzen und flups, verlierst du nämlich die Lust. Also ist Fragen der einfache Weg. Wenn die Zeit investiert wird, kommt vielleicht zweitausendein ein Pull Request, ab und zu auch gar keine. Also der Maintainer, ich in diesem Fall nehme dich Wolfgang jetzt an die Hand, wir springen in Zoom Call oder Google Meet oder wo auch immer und ich helfe dir, das Setup aufzusetzen. Dann sagst du oh ja, es ist aber schon 19 Uhr, ich muss meiner Familie mal essen machen und der Call wird beendet. Meine Erwartung als Maintainer ist jetzt eigentlich, dass du über die nächsten paar Tage oder Wochen vielleicht mal ein bisschen daran weiter programmierst und einen Pull Request machst. Und dass es dann auch nicht bei einem Pull Request bleibt, sondern dass du vielleicht mehr machst, dass du einfach ein toller Maintainer, ein langfristiger Maintainer fürs Projekt wirst. Mit drive by Maintainer meine ich eigentlich, es wird die Zeit investiert, dich onzuboarden. Du kommst rein, machst einen Pull request und fährst einfach wieder weiter. Du löst dein eigenes Problem und weiter geht's. Das ist natürlich unglaublich demotivierend für für mich als Maintainer. Und was ich auch schon erlebt habe, zweitausendein die hören damit einfach dann komplett auf. Ich z.B. habe auch wenig Interesse, weil ich habe das schon drei, vier mal gemacht, dreimal sogar in einem Projekt mit drei verschiedenen Leuten. Ich habe den geholfen, wir haben über Roadmaps gesprochen und so weiter und danach nie wieder was gehört, noch niemals mehr auf E Mails geantwortet und das ist natürlich dann sehr, sehr demotivierend.

Wolfi Gassler (00:45:23 - 00:46:21)

Es ist ja auch so, dass es nicht nur demotivierend ist, sondern es kann ja auch gefährlich fürs Projekt werden, weil wenn du jetzt irgendwelche PRs bekommst mit neuen Features, weil das für diese Person wichtig war, dann wächst ja deine Codebase und du musst es ja weiter warten. Das heißt, du hast ein neues Feature drin, was vielleicht gar nicht so wichtig war, ist schon okay ist, weil du hast ja entschieden, dass es mit reinkommt, aber du musst es dann weiterführen und im schlimmsten Fall muss es entweder wieder rausnehmen, rausschneiden ist auch schwierig. Also auch da mit dem Feature Creep würde ich es mal nennen. Das hast du natürlich dann in so einem Fall noch viel mehr. Und gerade bei einem sehr populären Projekt, wo jeder um die Ecke kommt mit irgendwelchen neuen Features, da kommt dann der Andi und und will da wieder ein Feature einladen, nur weil er irgendwie in Duisburg einen speziellen Use Case dafür hat, dann hast du natürlich das Problem und das demotiviert dann natürlich noch mehr, wenn wenn deine Code Base dann ein Problem wird. Also nicht nur die Einzelfälle, sondern dann das begleitet dich ja dann über Jahre hinweg sozusagen dieses Zusatzfeature, was du eigentlich gar nicht haben wolltest.

Andy Grunwald (00:46:21 - 00:46:43)

Und dann habe ich auch überlegt, was ist denn jetzt hier die mögliche Lösung? Und ich kam nur zu einem Appell. Wolfgang, hör bitte gut zu. Ein Appell an uns alle. Wir sollten mehr Ambitionen an den Tag legen, um es wirklich zu versuchen selbst hinzubekommen, auch wenn keine Dokumentation da ist. Kannst du dich mit diesem Appell identifizieren.

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

Warum da der Zusatz, auch wenn keine Dokumentation vorhanden ist?

Andy Grunwald (00:46:47 - 00:47:13)

Weil wir immer noch im Open Source ist und mich keiner für Dokumentation bezahlt und ich ab und zu keine Lust habe, abends um 23 Uhr noch Dokumentation für irgendwelche Leute zu schreiben, weil ich habe ja mit Open Source mein eigenes Problem gelöst und weiß ja, wie es einzusetzen ist. Und offen gesprochen, je nachdem was es für ein Projekt ist, wenn es jetzt eine JavaScript Library ist, dann weißt du ja, wie du es installierst. Ja, also dann ist es ja common standard Entwicklerstandard, wie man jetzt npm install macht oder go install oder wie es alle heißt.

Wolfi Gassler (00:47:13 - 00:48:08)

Ja, bei der Dokumentation würde ich weniger mitgehen, weil man denkt, da musst du einfach mit dem ersten, der anfragt und du in irgendeiner Form was erklärst, musst du die Dokumentation mitschreiben, im Idealfall Ÿousand, damit du wenigstens irgendwas hast. Also einfach zu sagen, naja, wir sind im Open Source Bereich, wir haben keine Dokumentation und darum müssen sich halt alle ohne Docs auch einlesen können. Ich finde es schon gut, dass man sich auch mal durchgekämpft ohne Dokumentation, aber dann vielleicht die Dokumentation aufschreibt oder da schon contributed, aber ich würde es mal nicht voraussetzen. Aber das, dass man grundsätzlich einfach tiefer geht und länger dabei bleibt, ist sicher ein super Appell, auch wenn er schwer ist. Bei mir genauso dazu sagen, ich habe schon so oft irgendwas gefixt oder geedet und wenn man es dann selber nicht mehr verwendet, die ganze Sache, weil es einfach das Projekt weg ist oder man was besseres gefunden hat, dann ist man halt auch einfach selber weg und hat null Motivation dabei zu bleiben. Das verstehe ich schon.

Andy Grunwald (00:48:08 - 00:48:11)

Auch du bist ja keine Hilfe im Podcast gerade.

Wolfi Gassler (00:48:11 - 00:48:18)

Ja, wie du immer so schön sagst, der happy path ist bei dir jetzt und ich erkläre dir halt die Realität, damit du das auch mal verstehst.

Andy Grunwald (00:48:18 - 00:49:50)

Und wie sieht die Realität aus? Die Realität sieht auch oft wie folgt aus. Leute nutzen deine Software, die beißen sich nicht ÿousand so durch wie der Wolfgang, machen dafür dann aber einfach mal ein Ticket auf, beschreiben neues Feature oder ein Bug. Und das ist auch eine negative Seite. Also es ist ja toll, dass eine Software benutzt wird, haben wir gerade schon mal erklärt, aber nicht immer hat man die Ambition, sich dann hinzusetzen und für die Leute dann etwas zu entwickeln. Denn ich habe mich sehr viel gefragt, warum mache ich eigentlich Open Source? Warum habe ich diese Software eigentlich öffentlich geteilt und welchen Use Case hatte ich eigentlich und was ist eigentlich die Software bzw. Was soll sie nicht werden? Aka eine eierlegende Wollmilchsau und ab und zu. Und das hat mich dazu gebracht, so ein bisschen die Roadmap Strategie oder auch die Limitierungen und Erwartungen z.B. in die Readme zu setzen. Denn im Endeffekt ist es deine Zeit, dein Leben und deine Entscheidung, was du da in die Software baust und ob du für andere ein Feature implementierst. Und meine Standardantwort immer, wenn ich sowas kriege, hey, Pull Requests sind gerne willkommen und schau mal, da siehst du vielleicht, wie du es installierst und wie du dein Development Setup einbaust. Und meine Erfahrung ist leider, leider, leider, da kommt nichts. Stille noch nicht mal mehr danke, ich kümmere mich drum oder danke, ich habe keine Zeit oder das ist auch immer so, es wird, haben wir ja initial schon besprochen, eine ganz komische Beziehung zwischen Anwender und Maintainer. Zweitausendein irgendwie wie eine Art wie ich habe für dieses Produkt bezahlt und ich möchte jetzt den Support dafür haben. So ist das ja ab und zu.

Wolfi Gassler (00:49:50 - 00:50:04)

Wobei du auch bei kommerziellen Software nicht einfach dir irgendwas wünschen kannst. Also da kannst du auch nicht. Klar kannst du das Feature einkippen und wenn du ein großer Kunde bist, bekommst du es vielleicht. Oder es kommt halt auf die Roadmap, aber es kommt halt auch nur auf die Roadmap. Und das kannst du ja bei Open Source genauso machen.

Andy Grunwald (00:50:04 - 00:50:09)

Ja, aber warum wird das, warum wird das implizit bei Open Source so erwartet? Weil du musst schon sagen, so ist es halt leider.

Wolfi Gassler (00:50:09 - 00:50:52)

Ich glaube, es wird eh überall so erwartet, weil man ja immer glaubt, man ist selber der wichtigste Kunde, egal ob kommerziell oder open source. Aber wie gesagt, bei open source hat man den direkten Kontakt. Und das unterschreibe ich voll und ganz. Wie ich zuerst erwähnt habe, einfach auf die Roadmap setzen in irgendeiner Form. Und wenn dann andere Entwickler Spaß daran haben oder die Person selbst. Ja, gerne, kann man, kann man so machen, aber sonst ist es halt nur ein Issue. Und ich habe auch die Erfahrung gemacht, dass da sehr, sehr selten irgendwas zurückkommt. Und ganz oft sind sie auch keine Entwicklerinnen, die da irgendwas schreiben, sondern einfach irgendwelche User, die keine Ahnung haben oder womöglich von der Programmiersprache. Die setzen das auch nur so am Rand irgendwo ein. Das hast du natürlich dieses Problem. Also mit dem muss man fast leben. Ich weiß, es ist.

Andy Grunwald (00:50:52 - 00:51:06)

Sorry, aber du trägst gerade nicht dazu bei, dass mehr Leute ihre Software veröffentlichen, wenn du sagst, da muss man mit leben. Das ist so wie, als wenn du sagst, du hast Burnout. Ja, sorry, aber die Welt ist komplexer geworden, du musst jetzt einfach damit leben. Das hilft auch nicht.

Wolfi Gassler (00:51:06 - 00:51:30)

Ja, man muss damit leben und Wege finden, damit umzugehen. Das ist glaube ich, das wichtige, weil du wirst es nicht ändern können. Es wird immer diese Leute geben und es wird der direkte Kontakt bei Open Source bleiben. Das heißt, du wirst diese Erfahrung machen. Du musst halt versuchen, möglichst gut damit umgehen zu können. Weil nur weil wir da jetzt ein Appell an alle richten, glaube ich nicht, dass sich was ändert, ehrlich gesagt.

Andy Grunwald (00:51:30 - 00:53:30)

Und weißt du, woran sich leider auch nichts ändert? Denn es kommt immer mal wieder vor. Und jetzt kommt eine ganz, ganz traurige Sache, die ich letzte Woche noch selbst erlebt habe. Es kommt kaum ein Danke für ein Open Source Projekt, aber es kommen sehr oft negative Nachrichten. Sachen wie your fucking software took my infrastructure down. Oder because of you, i lost all my data oder folgenden Satz habe ich die Tage bekommen i need this shit because I can't install your fucking software. Ich verlinke das Issue gerne unten in den Show Notes. Die Leute sind sauer, aufgebracht, warum auch immer und können ihre Emotionen halt nicht kontrollieren und lassen es halt dann am Maintainer aus, am Projekt aus, was natürlich knallhart respektlos ist. Da müssen wir uns nicht drüber unterhalten, denn jeder vergisst dann halt in irgendeiner Art und Weise, wie viel Arbeit, Tränen, Schweiß und Mut auch darin steckt, ein Stück Code oder ein Projekt als Open Source Software zu veröffentlichen. Denke ich finde das mutig. Wir hatten ja gerade gesagt, jeder will kein schlechtes Licht auf sich werfen. Zweitausendein das Beste irgendwie von sich zeigen. Und so weiter. Und wenn man, wenn man dann halt kein Danke sagt, sondern eigentlich noch so beleidigend wird, ist das halt nicht nur fehlende Anerkennung, sondern schon echt schrecklich. Und was ist die mögliche Lösung? Falls du gerade in einer guten Laune bist, mach einfach mal in irgendeinem Open Source Projekt, dass du aktiv nutzt, ein Ticket auf. Schreibt einfach nur Thank you for all your work als Titel und in der Description beschreibst du doch einfach mal, wo du die Software gerade jetzt einsetzt, ja, in welchem Use Case und dass du einfach mal Danke sagen möchtest für die ganze Arbeit Schweisstränen und für den Mut auch. Und ich habe das ein paar mal gemacht und auf einmal kommen da ganz viele Emojis an dieses Ticket ran, weil Leute das unterstützen. Und ich habe auch schon sehr viel Danke zurückbekommen dann von von den Maintainern. Die freuen sich und das kostet dich wirklich keinen Cent. Und du bist du hast mit hoher Wahrscheinlichkeit jetzt gerade, wenn du nicht im Auto sitzt, sogar einen GitHub Tab irgendwo auf. Schreib doch da einfach mal ein Danke hin.

Wolfi Gassler (00:53:30 - 00:53:33)

Was hast du geantwortet auf diesen Issue?

Andy Grunwald (00:53:33 - 00:53:52)

Da habe ich geantwortet, dass er doch bitte seinen Ton anpassen soll und dass wir Maintainer ihm nichts schulden, aber dass wir sehr gerne einen Pull Request akzeptieren. Und seitdem ist stille. Ach so und und auch ich habe auch wieder angeboten, falls ihr Professional Support haben möchtet, kann er mich gerne anschreiben. Da kriegt dann Angebot zurück.

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

Ja und wie ist es? Hat er jetzt recht gehabt, dass er sagt, ihr project is a mess, which all needs to be fixed mit Doppel x?

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

Das Projekt ist eine Mess. Das ist so 1520 Jahre alter PHP Code. Ja, hundertprozentig. Also Spaghetti Code vom feinsten. Bin ich auch nicht stolz drauf ist. Aber ich habe das Projekt auch nur irgendwann mal übernommen. Wie dem auch sei, hey, es funktioniert ist open source, ja, also ich habe jetzt keine Zeit, die komplette Sache zu refactoren. Das sind, das sind, weiß ich nicht, 40, 50 Zeilen PHP Code, das ich auf PHP sieben oder acht gehoben habe und das macht halt keinen Spaß in meiner Freizeit.

Wolfi Gassler (00:54:29 - 00:54:34)

Ja, er hat ja auch keinen Spaß, wenn ich so seine 50 Rufezeichen anschaue in seinem Issue.

Andy Grunwald (00:54:34 - 00:54:39)

Ja, ich weiß nicht, ob er irgendwie eine hängende Tastatur hatte, aber da sind ein paar Ausrufezeichen mehr.

Wolfi Gassler (00:54:39 - 00:55:56)

Wenn du aber schon von anderen sprichst, die nichts contributen zu deinem Projekt und sich nur beschweren, zweitausendein, da muss ich schon auch die Firmen noch ein bisschen in die Mangel nehmen, weil ihr lebe das schon sehr oft auch in meiner professionellen Tätigkeit, dass Firmen, die Open source einsetzen, sehr wenig in irgendeiner Form zurückkontributen. Und da spreche ich jetzt gar nicht davon, dass, weil das sind ja oft keine Programmierer, die dann irgendeine Software einsetzen, aber es fließt halt kein Geld zurück. Klar, die sagen ja, es ist wichtig und danke und so weiter und aber dass da wirklich mal was zurückfließt und da stehen ja teilweise wirklich sehr viele Entwickler dahinter und Entwicklerinnen. Das finde ich halt sehr, sehr schade, dass die Firmen da gar nichts machen und sich gar nicht bemühen, weil es verdient jede Firma noch Geld damit und wenn da nicht mal irgendwelche kleinen Beträge zurückfließen an Open Source Entwicklerinnen oder sonst in irgendeiner Form, wie du sagst, ein Danke hilft dir auch schon, wobei bei einer Firma erwarte ich mir eigentlich schon mehr als ein Danke. Und wenn dann so 90 % eigentlich auf Open Source aufbaut und die gesamte Infrastruktur und womöglich deren Haupt Business darauf aufbaut, dann finde ich das schon sehr schwach, dass man es gar nicht versucht, in irgendeiner Form was zurückzugeben.

Andy Grunwald (00:55:56 - 00:58:09)

Kann ich dir nur zustimmen, aber wir sprechen jetzt hier sehr negativ darüber, deswegen lass uns mal bitte ganz kurz realistisch darüber sprechen. Es ist nun leider so, dass die Geschäftsführung in Firmen oft nicht auf dem Zettel hat oder in ihrem Kopf gerade, dass sie ihr Business auf den Schultern von Giganten aufbauen, nämlich der Open Source Szene. OpenSSL, Curl und sogar die meisten Programmiersprachen sind ja Open Source. Also ohne das kann diese Firma eigentlich fast gar nicht mehr existieren. Und deren Hauptproblem von der Geschäftsführung ist halt nicht, oh, ich habe jetzt hier Geld über, wem schenke ich das denn jetzt? Sondern es ist einfach nicht präsent. Und meine Erfahrung nach, und das haben wir auch schon getan, ist einfach mal mit dem Abteilungsleiter sprechen oder mit dem CTO und einfach nochmal vorschlagen, hey, was hältst du denn davon, wenn wir mal in der Firma eine Umfrage machen, welches Open Source projekt wir ein paar Euro geben zur Unterstützung und dann macht man z.b. eine Open Source, eine Open Source Umfrage. Da macht man z.b. eine Umfrage innerhalb der Firma, alle Entwickler können mitmachen und dann gibt es da so kleine Regeln wie z.B. wir müssen diese Software oder diese Library einsetzen, so als Firma, das finde ich ja völlig fair. Und dann sagt man, man verteilt irgendwie, weiß ich nicht, €2000 oder €3000, was ja für eine normale Firma relativ wenig Geld ist, muss ich zugeben. Und dann sagt man 50 % des Geldes geht dahin und dreiig % dahin anhand der Ergebnisse. Und siehe da, viele Manager sind da sehr aufgeschlossen drüber, aber sie haben keine Zeit das selbst zu machen, dass sie wollen das nicht managen, sie wollen einfach nur tue gutes und rede darüber, was ja okay ist, also aber der Treiber, der müsst ihr sein und das zurückgeben ist dann auch eine gute Sache. Ich würde meines Erachtens nach, würde ich das Geld dann nicht an eine Foundation geben, sowas wie die Linux Foundation oder die Cloud Native Compute Foundation, sondern wirklich und auch nicht an so große Projekte wie React, weil wenn du damit ankommst, dann sagt React danke, aber dass das verpufft dann so wie so ein Tropfen auf dem heißen Stein in dem Ökosystem, weil React ist einfach riesig, sondern geht mal auf irgendeine Library, die von React eingesetzt wird, so drei level tiefer und gibt dieser Person €100.

Wolfi Gassler (00:58:09 - 00:58:44)

Ja, man kann das ja auch ändern, also man kann ja ein Jahr an diese Library sponsern, das Jahr drauf an das CMS, das man verwendet oder das Jahr drauf an das, keine Ahnung, interne Ticketing System, was man so an Software halt einsetzt. Also man kann es ja verteilen und es freuen sich glaube ich alle darüber. Und was ich halt schon oft erlebe ist, dass die Firmen sagen, ja, uns ist Open Source wichtig und wir leben Open Source vielleicht sogar oft und alles was es bedeutet ist, wir benutzen Open Source kostenlos und da fehlt halt irgendwas, damit man wirklich sagt, man lebt Open Source.

Andy Grunwald (00:58:44 - 00:59:43)

Was Firmen auch machen können, ist ihren großen Namen mal für, ich sag mal so ein bisschen Recognition zu nutzen. Und zwar macht das Google einmal pro Jahr können Google Mitarbeiter zweitausendein Open Source Contributoren außerhalb von Googles nominieren. Und umso öfter dann ein Open Source Contributor nominiert wurde, dann kommt er auf so eine Liste, das sind so 40, 50 Leute, die wurden vor kurzem wieder durch einen sogenannten Peer bonus anerkannt und Google hat dann die Namen inklusive mit dem Projekt und sogar, was sie da gemacht haben, in den Blogpost veröffentlicht. Und die kriegen ein bisschen Cash. Das wird jetzt nicht viel sein, es werden jetzt keine Euro sein pro Person, sondern wahrscheinlich ein paar hundert Dollar oder so. Steht vielleicht irgendwo, haben wir jetzt nicht rausgesucht, aber das ist eine Liste von Leuten, die von Google Mitarbeitern, ich sag mal, nominiert wurden. Und sowas könnt ihr natürlich intern auch machen. Auch eine super Geschichte, weil dann sagt nämlich Google, also wenn mein Name auf der Google Webseite stehen würde als Open Source Recognition, wäre schon stolz, muss ich schon zugeben.

Wolfi Gassler (00:59:43 - 01:00:18)

Oft ist es ja auch so, dass die Open Source Projekte gar nicht wissen, wo sie verwendet werden. Also alleine, wenn man diese Info zur Verfügung stellt und sagt, ihr dürft es auch gerne auf eurer Webseite hinschreiben, dass es von uns verwendet wird. Gerade wenn du eine größere Firma bist, kann das schon einen extrem großen Impact haben. Da hast du vollkommen recht. Und sonst, man kann auch im Kleinen als kleine Firma lokale Events sponsoren. Es gibt so die ganzen Linux Tage und Linux Stammtische. Und für jedes Open Source Projekt gibt es auch in größeren Städten irgendwo einen Stammtisch oder ein Meetup. Man kann denen ja auch einfach mal eine Runde zahlen, die freuen sich sicher auch drüber. Ÿousand.

Andy Grunwald (01:00:19 - 01:00:48)

Und wenn ihr gar kein Geld in die Hand nehmen wollt, dann macht wenigstens was motivierendes für die eigenen Mitarbeiter. Macht doch einfach mal ein ein Tages Open Source Hackathon, wo die ganzen Leute einfach mal was an Open Source Contributen können während eines Arbeitstages. Denn auch das, wie wir initial gesagt haben, ist mal was anderes als der DJ Job. Da braucht ihr jetzt kein wirkliches Geld in die Hand nehmen. Klar kostet das natürlich Geld, weil die ganzen Entwickler und Entwicklerinnen dann einen Tag nicht arbeiten, zumindestens nicht am Core Produkt, aber ihr wisst, was ich meine.

Wolfi Gassler (01:00:48 - 01:01:48)

Ich habe z.B. auch kürzlich Kontakt gehabt mit, kann man nicht mehr genau erinnern, müsste noch mal raussuchen, können wir dann gern verlinken. Aber es gibt in Tirol so eine Foundation, die glaube auch so mit Schulen, im Schulumfeld irgendwie tätig ist und Use Cases gebraucht hat, wo Open Source überall eingesetzt wird in der Wirtschaft. Und es war für die extrem hart, Kontakte in der Wirtschaft zu bekommen. Und Firmen, die gesagt haben, ja, wir stellen uns dahin, ihr macht ein kurzes Video mit uns, die hätten alles gemacht, aber die gesagt haben, okay, wir wollen einfach nur zeigen, wo überall in Firmen cool Open Source eingesetzt wird. Und das war schon schwierig, weil die meisten Firmen abgelehnt haben und da nicht mitmachen wollten. Also nicht mal da ein bisschen Zeit zu investieren, da geht es gar nicht um Geld, sondern um Zeit war für ganz, ganz viele Firmen, auch größere Firmen vor allem, ein Riesenproblem. Also das ist dann schon schade. Ich verwende schon Open Source, dann kommt sowas, was wirklich darum geht, Open Source weiter zu fördern und dann investiert man nicht diese ein, 2 Stunden, um da irgendwas mit denen zu machen.

Andy Grunwald (01:01:48 - 01:01:55)

So, jetzt haben wir hier schon eine ganze Weile Negativität versprüht und gerentet über alle.

Wolfi Gassler (01:01:55 - 01:02:08)

Aber ist ja auch, dass alle unsere Zuhörerinnen bei Firmen arbeiten und oder fast alle, oder bei ihren eigenen Firmen und daher auch einfluss haben und einen Hebel haben. Also eigentlich kann ja jede und jeder etwas bewegen.

Andy Grunwald (01:02:08 - 01:02:12)

Ja, oder negativ formuliert sind die auch alle ein bisschen selbst schuld, oder?

Wolfi Gassler (01:02:12 - 01:02:22)

Jetzt wollte ich auf der positiven Schiene bleiben, Andi, und du kommst wieder mit der negativen Schiene. So kannst du doch keine Leute motivieren. Ich habe gedacht, du bist der Coach und ähnliches als Engineering Manager.

Andy Grunwald (01:02:22 - 01:02:31)

So, auf jeden Fall habe ich mir auf dieser letzten Hunderunde dann auch überlegt, okay, jetzt habe ich hier so eine deprimierende, negative Folge ausgegraben.

Wolfi Gassler (01:02:31 - 01:02:36)

Beschäftigst du dich mit deinem Hund eigentlich auch oder läuft er nur selbstständig rum und du denkst nach?

Andy Grunwald (01:02:36 - 01:03:56)

Also je nachdem, wie gut ich den Dummy verstecke, sucht der halt mal zwei 3 Minuten und dann habe ich halt Zeit und dann bringt er mir den Dummy und dann schmeiße ich den wieder oder lass ihn einfach fallen und oder setze ihn irgendwo hin und dann laufe ich ja auch mal so 100 m weg, damit er den Dummy sucht. Also das bedeutet, ich habe sehr viel Gehweg, wenn du so möchtest. Aber auf jeden Fall habe ich dann überlegt, okay, wie schließe ich denn dieses deprimierende Format jetzt hier ein bisschen positiv ab? Und zwar, es ist ja nicht alles schlecht. Wir wollten nun mal ein bisschen Realität in diese schöne heile Welt, in das Teletabilant des Open source bringen. Und zwar ein bisschen Licht in diese negativen Aspekte, die ganz, ganz wenige Leute leider täglich spüren. Und zwar habe ich mal ein bisschen gegoogelt, was es nämlich dann auch noch so für Artikel gibt. Denn ich hatte ja vorhin schon einen Artikel erwähnt, dass man als Open Source Maintainer einem nichts schuldig ist. Da habe ich einen anderen schönen Artikel gelesen, der heißt open source is not about you, vom Autor der Programmiersprache Closure. Und er schreibt, was recht brutales aber schon irgendwie war. Und zwar sagt er, Open Source ist ein Lizenzierungs und Bereitstellungsmechanismus. Punkt. Es bedeutet, dass man den Quellcode der Software erhält und das Recht hat, sie zu nutzen und zu verändern. Nichts mehr. Und den Blogpost zumindest. Bitte.

Wolfi Gassler (01:03:56 - 01:04:00)

Manchmal zumindest, kommt auf die Lizenz drauf an. Aber im großen und ganzen ja, ja.

Andy Grunwald (01:04:01 - 01:04:49)

Er redet jetzt von einer Open Source Lizenz, jetzt nicht von der Business Source Lizenz oder der Functional Source Lizenz oder ähnliches, wo dann irgendwie non compete sagt, ihr redet sowas wie mit BSD, GPL und so. Und auf jeden Fall ist das summa summarum von diesen Artikeln halt auch Open source ist nicht perfekt. Alles gut. Wenn es euch keinen Spaß mehr macht, hört einfach auf und gehatet zu werden von irgendwelchen Leuten, macht halt einfach keinen Spaß. Und open Source kann dich zwar in deiner Karriere weiterbringen, aber Arbeit ist halt leider nicht alles. Vielleicht ist sogar das Open Source Contribution als Karriereweg overrated. Verlinken wir auch einen schönen Blogpost in den Show Notes. Im Endeffekt will ich euch damit nicht den Spaß an Open Source nehmen, sondern ich hoffe eigentlich, dass jeder von euch, den noch nicht zu Open Source contributed hat, das wenigstens mal tut.

Wolfi Gassler (01:04:50 - 01:04:54)

Dennoch hört doch auf, wenn es euch keinen Spaß macht. Also wo ist jetzt diese Positivität, an.

Andy Grunwald (01:04:54 - 01:05:11)

Die du nein, jagt halt nicht diesem Fame hinterher. Oh, ich möchte auch mal ein großes Projekt haben, wo ganz viele Leute meine Software einsetzen. Denn ich glaube nicht, dass das wirklich jemand möchte, wenn wir uns die negativen Seiten hier auch mal, die wir heute besprochen haben, zu zu Gemüte führen.

Wolfi Gassler (01:05:12 - 01:05:47)

Und sonst vielleicht auch einfach mal mit der eigenen Firma sprechen. Vielleicht kann man ja auch 10 % seiner Zeit in Open Source in irgendeiner Form investieren, in das eigene Projekt oder in der Firma auch was open Source. Also man kann ja auch zu den 50 % gehören, die bezahlt werden für Open Source. Also auch das ist ja eine Möglichkeit. Kann man ja gerne auch mal intern anregen, absprechen. Vielleicht sind da Firmen ja auch offen, weil wie du richtig sagst, die oberste Management Ebene, die kümmert das nicht. Das muss von unten kommen und von unten raus und überzeugend vorgebracht werden, weil freiwillig zahlt niemand was üblicherweise in der Managementebene.

Andy Grunwald (01:05:48 - 01:06:00)

Und wenn du jetzt immer noch Bedarf hast, mit Wolfgang und mir über dieses Thema zu sprechen, dann komm doch bitte in die Selbsthilfegruppe der engineering Kiosk Discord Community. Du wirst uns da finden und ganz viele Gleichgesinnte, auch ganz viele andere, die.

Wolfi Gassler (01:06:01 - 01:06:04)

Noch mehr Ahnung haben als wir. Wir schwimmen ja nur so mit in dieser Community.

Andy Grunwald (01:06:04 - 01:06:25)

Jeden Donnerstag um 11 Uhr treffen wir uns da und sagen ja, mein Name ist Andy und ich bin auch open source süchtig. Und so entlasse ich dich zur nächsten Podcast Episode, denn deine nächste Podcast Episode, die du nach dieser Podcast Episode anmachst, wird natürlich auch wieder eine Engineering Kiosk Podcast eben Episode sein. Viel Spaß also und bis bald.

Wolfi Gassler (01:06:25 - 01:06:48)

Am besten einfach auf den Tag Open source gehen, findet man alle Open source Episoden, alle Open source relevanten Episoden und da findest du sicher auch was. Und nicht DevOps und SRE as a Service für dein Digitalunternehmen, Startup oder Agentur. Flexibel und nachhaltig. Schau rein bei wemanage Ÿousand.