#163 Benevolent Dictator for Life (BDFL)

Benevolent Dictator for Life (BDFL): Was ist das? Wer ist das? Ist dies was gutes?

Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema.

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

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Benevolent Dictator for Life (BDFL)

Hosts

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

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
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Twitter: https://twitter.com/EngKiosk

Transkript

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

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

Willkommen zum letzten Türchen in der ersten Halbzeit. 12 to go. Und by the way, hast du dich auch schon gefragt. Aktives Zuhören ist also ein wichtiger Skill und darum habe ich mir die Websockets zu Herzen genommen und habe in dieser Episode meine Listening Skills bei Andy sehr intensiv trainieren müssen, denn es geht um BDFL und Andy und ich sind da ganz anderer Meinung. Aber hört selbst.

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

Also ich muss schon sagen, open Source ist ja immer eine super Sache und ich bin immer wieder beeindruckt, was man mit Open Source alles machen kann. Denn jeder kann Features kontributen, hinzufügen, Bug fixen und das ist auf der einen Seite super grandios, weil dadurch wird die Software halt deutlich mächtiger. Auf der anderen Seite gibt es natürlich das Sprichwort viele Köche verderben den Brei. Und genau das ist der riesen Nachteil an Open Source, denn die ganze Sache kann auch zu einem Wildwuchs führen. Wildwuchs, wie man die APIs benutzt, Wildwuchs, was eigentlich der Kern der Software sein soll, bzw. Welches Problem denn eigentlich gelöst werden soll. Und halt damit diese Open Source Software keine eierlegende Wollmilchsau wird. Kennst du das, Wolfgang? Eierlegende Wollmilchsau, gibt es das in Österreich? Natürlich gibt es das und natürlich Wildwuchs in Sachen Softwarearchitektur und so weiter. Und um diese Art wildwuchs zu verhindern, gibt es in vielen großen populären, langlaufenden Projekten so eine Art Teamleiter. Das ist meist so eine Person, die von jedem gemocht wird und zumindestens, ich sag mal, das Gesicht des Projektes, der Community ist. Wenn ich jetzt von der teamleiter Position spreche, dann ist das Ziel dieser Person natürlich, dass alle Spaß haben, das Projekt gut finden und dass das Projekt gut läuft. Denn wie gesagt, diese Person steht halt irgendwie auch mit ihrem Gesicht da und wo wären, wenn dieser Teamleiter nicht auch einen Namen hätte? Und diese Person nennt man Benevolent Dictator for Life, kurz BDFL, also BDFL. Wenn man danach googelt, weil das Wort Dictator hat jetzt in der Regel keine positive Notation, dann wird dieser Titel als humorvolle Bezeichnung für eine Person, die in einem Softwareprojekt die letztendliche Entscheidungsgewalt hat, bezeichnet. Also im Endeffekt eine Person, die hauptverantwortlich dafür ist, bei Konflikten oder Meinungsverschiedenheiten zweitausendein einzuschreiten und die Richtung vorzugehen. Und deswegen ist das Wort benevolent, also aufs gut Deutsch wohlwollend, auch so wichtig, denn es ist ein Diktator, der im Endeffekt halt eine Entscheidung treffen muss, im besten Sinne und Interesse des Projekts und seiner Community.

Wolfi Gassler (00:02:41 - 00:02:50)

So, jetzt gib mal, nachdem du da immer so Name Dropping betreibst, gib mal da ein paar gängige Namen, die es da so in der Geschichte der Entwicklung gegeben haben.

Andy Grunwald (00:02:51 - 00:03:23)

Geschichte heißt immer so Vergangenheit, aber sie sind teilweise immer noch wahr. Der wohl bekannteste ist Linus Torvalds, der Gründer bzw. Originalautor von Linux. Er ist heute immer noch der BDFL von Linux und hat auch immer noch die endgültige Entscheidungsgewalt. Zwar hat er ein paar Subkomponenten auch an andere abgegeben, aber das nur als Nebensatz. Im Endeffekt ist Linus selbst dafür bekannt, dass er halt für hochwertigen und sicheren Code steht und da auch wirklich, ich sag mal, sehr direkt ist, wenn ein Quellcode halt nicht seinen Qualitätskriterien entspricht und.

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

Leute anderer Meinung sind. Also direkte Kommunikation könnte man da auch noch mit reinnehmen. Manche würden es sagen eher unfreundlich. Man kann sich da gerne vor allem alte E Mails durchlesen auf der Mailing Liste. Das ist schon anderer Umgangston, würde ich mal sagen, der heutzutage eher schwierig zu pflegen.

Andy Grunwald (00:03:40 - 00:05:06)

Wir können es gerne beim Wort nennen, manche Leute bezeichnen ihn auch als Arschloch, ist halt so. Aber im Endeffekt hat er natürlich auch als BDFL für Linux, nämlich eine zweitausendein Betriebssystem, was die weit verbreitetste Installationsmenge auf dem Planeten hat, halt auch eine enorme Verantwortlichkeit. Von daher, na Gut, das heißt nicht, dass ich alle Aktionen von Linus gut finde. Linus war aber nicht der erste BDFL, beziehungsweise da kommt nicht der Term her, sondern der Term wurde geclaimt von bzw. Für Guido von Rossum. Guido von Rossum war der BDFL von Python, der Programmiersprache. Und sein spezieller Take bei Python war eigentlich, dass er dafür gesorgt hat, dass Python einfach lesbar und vielseitig bleibt. Ich habe gesagt war, weil Guido von Rossum ist seit 2018 kein BDFL mehr für Python. Wo wir bei Programmiersprachen sind. Larry Wall Pearl. Meines Erachtens nach ist Pearl keine Programmiersprache, sondern eher die Kunst, das richtige Zeichen zu finden. Aber das nur als Nebensatz. Larry Wall hat auf jeden Fall Pearl als leitende Figur weitergetrieben und er prägte die Philosophie there is more than one way to do it. Also es gibt mehr als einmal den richtigen Weg. Ja, und wie gesagt, anhand der Sonderzeichen in per würde ich ihm dazu stimmen. Ziel erfüllt. Andere populäre Namen sind David Heinemeier Hansen DHH für Ruby und Wales, Theo de Rath für das Betriebssystem OpenBSD oder vielleicht für die JavaScriptler unter euch, Evenu für das Projekt Vue JS.

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

So, jetzt hast du ja sehr positiv über diese Rolle gesprochen. Warum glaubst du, dass es wichtig ist, so jemanden zu haben so ein BDLF, Ÿousand BD, wie heißt der? BDFL?

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

So ein BDFL, benevolent dictator for life, ja, wo Menschen im Team zusammenkommen, gibt es Konflikte und irgendwer muss halt mal Klarheit schaffen. Ja, also so der BDFL verhindert halt, dass Projekte durch entleere Diskussionen ins Stocken geraten, sondern dass es weitergeht. Wie wir bei Linux sehen, geht es da auch an die Qualitätssicherung. Manche bdfls entscheiden, wann der Code gut genug ist, um ins Projekt überführt zu werden. Dann natürlich, was ist die Vision des Projektes? Welche Probleme löst dieses Projekt nicht, wie sieht die Roadmap aus? Aber was ich ganz speziell wichtig finde, ist die Einheitlichkeit bzw. Dass das Projekt einen Stil hat. Natürlich kannst du es auch so wie Larry Wall bei Pearl betreiben, du hast ganz viele Möglichkeiten, aber ich bin ein Freund von Opinionated Software und das merkt man natürlich bei den ganzen BDFL. Was mir bei der Recherche für diese Mini Episode aufgefallen ist, irgendwie habe ich nur männliche Personen als BDFL gefunden. Und da kommt natürlich in 2024 auch die Frage, wo sind denn da die Frauen? Und da habe ich meine Recherche ein bisschen ausgeweitet und habe wirklich gemerkt, dass die Historie gezeigt hat, dass diese Position wirklich stark männlich geprägt. Aber ich habe trotzdem ein paar sehr, sehr populäre Frauen in Open Source Projekten gefunden. Z.B. mitchell Baker ist die ehemalige CEO von Mozilla und sie war maßgeblich daran beteiligt, Mozilla und natürlich Subprojekte, Firefox und wie sie alle heißen, dass das zu einem der größten Open Source Projekte wird, wie es halt aktuell ist. Und sie hat ihre klare Vision für offene Standards und Internetfreiheit weiterverfolgt und natürlich auch durch die Mozilla Community in die Welt getragen. Karen Sandler ist wer anderes, sie war Executive Director der Gnome Foundation, Gnome auch sehr bekannt im Linux Umfeld. Dann gibt es noch Valerie Aurora, sie ist die Gründerin der Ada Initiative zur Förderung von Frauen in Open Source. Denise Cooper im Bereich Innersource hatten wir auch mal eine Episode drüber. Sie hat eigentlich Open Source Initiativen bei großen Konzernen wie Sun Microsystems, Paypal und natürlich jetzt in der Innersource Commons Foundation geführt. Also sie kämpft halt auch für Open Source, auch im proprietären Umfeld. Und dann habe ich noch Elena Zanoni gefunden, sie war federführend für die Entwicklung von GDB, einem Gnu Debugger. Aber wenn man sich die Positionen mal ansieht, dann fällt eine Sache auf. Frauen zweitausendein sind weniger in der Position als Softwareentwicklerinnen im Bereich PDFL, sondern mehr in der Führung von Foundations und Initiativen ist zumindest mein Pattern oder meine meine Erkenntnis aus dieser kleinen Stichprobe und da bin ich offen. Vielleicht ist diese Stichprobe aufgrund der Datenbasis nicht repräsentativ. Also wenn du vielleicht noch weitere Frauen, die die Rolle des BDFL eingenommen haben, kennt, lass uns doch mal wissen. Als Fazit würde ich mal sagen, wenn du das nächste mal über den Begriff stolperst. Man denkt zwar immer Diktator ist etwas negatives, in diesem Fall ist es etwas positives. Dass ich das jemals sagen würde, dass ich sage, dass ein Diktator etwas positives ist, habe ich auch nicht gedacht.

Wolfi Gassler (00:08:15 - 00:10:32)

Moment, da muss ich natürlich reinkrätschen, weil es ist ja so ähnlich wie man sagt, ja, es war ja nicht alles schlecht unter dem guten Herrn. Es gibt ja die deutschen Autobahnen so fast. Also was mir dann schon auffällt, ist einfach diese Benennung dieser term Dictator, weil es ist ja schon irgendwie was, man stellt da eine Person, sei es jetzt männlich oder weiblich, aber üblicherweise ist es halt eher eine männliche Person. Man stellt da eine Person in den Vordergrund und man definiert ja da schon, auch wenn man sagt, es ist gut, dass das the way to go ist, weil es funktioniert nur, wenn eine Person am Ende entscheidet. Es kann keine Gruppe entscheiden. Z.B. also man sagt ja nur gute Software und die Einheitlichkeit, die du erwähnt hast, die ist nur möglich, wenn du eine Person dort oben stehen hast. Und es zeigt halt auch die Historie. Es gibt ja auch bei Python, seitdem er 2018 der Guido von Rossmann zurückgetreten ist, dass es jetzt ein Steering Council gibt. Bei Node es gibt es ein Steering Council, bei Drupal gibt es mittlerweile ein Steering Council. Apache Foundations hat ganz viele Steering Councils, sogar der Linux Kernel ist erweitert worden jetzt auf mehrere Personen, auch wenn der Linus natürlich da schon noch die Oberhand hat, muss man dazu sagen. Und wir hatten ja auch in Episode 108 und dreiig über Tandems z.B. gesprochen oder wenn man den Engineering Kiosk anschaut, da gibt es ja auch zwei Personen. Bei uns hat ja auch nicht eine Person am Ende das Recht, immer die Entscheidung zu treffen. Gerade heutzutage muss man darauf hinweisen, dass man in einer Gruppe sehr wohl auch einheitlich arbeiten kann, weil in einer großen Firma gibt es ja auch nicht eine Person, die den gesamten source code immer reviewt, damit es in eine Richtung getrieben wird, sondern da gibt es ja auch Dokumente, die gemeinsam definiert wurden, in welche Richtung man die Software treibt, was für Kriterien es gibt, was für Code Style guidelines, diese ganzen Dinge. Die waren ja auch gemeinsam entschieden, gerade bei ganz großen Companies. Also klar hast du am Ende irgendwie einen Boss, der unter Umständen eine Entscheidung trifft, aber es kann ja auch in der Gruppe was entschieden werden und dann wird halt gevotet. Z.B. also wenn sich die Gruppe, die ja in die gemeinsame Richtung arbeitet, nicht einig ist, dann entscheidet vielleicht sogar die Münze am Ende. Das heißt nicht, dass immer nur eine Person immer absolut alles entscheiden muss. Und ich glaube, darüber sollte man sich auch Gedanken machen und eben auch vielleicht überlegen, ob man diesen Begriff so gerne verwendet und dann auch positiv framen will oder ob man in eine andere Richtung geht. Aber das ist mein Woker Input zu dem ganzen Themenkomplex.

Andy Grunwald (00:10:32 - 00:12:44)

Du hast einen Punkt. Nur weil ich sage, dass BDFL in dem Kontext von Open Source nichts Negatives ist, heißt das nicht, dass ich sage, dass die Gruppenentscheidung was Negatives ist. Und auf der anderen Seite muss ich mal ganz ehrlicherweise sagen, ein Projekt muss erst die Größe bekommen, dass ein Steering Council sich finden kann und auch in ihrer Freizeit daran arbeiten möchte. So, und ich denke, bis ein Projekt diese Größe hat, dass mehrere Leute private Zeit investieren, muss irgendwer die Richtung vorgeben und durch die vorgegebene Richtung, durch den einheitlichen Stil wird, werden natürlich auch vielleicht Leute mit einem selben Mindset angezogen, die dann zu dem Projekt kontrollen wollen, etc. Also nur, das heißt jetzt nicht, dass keine Gruppe da schlechter ist, sondern es ist, wenn du sofort was open source technisch starten möchtest und dann, ja, ich suche Leute, die das Theorien Council mitmachen, dann würde ich sagen, setzt du da Bürokratie schon drauf, wo vielleicht gar keine sein. Also von daher sagte der alte weiße Mann, so bin ich älter als du. Naja, aber wie dem auch sei, falls ihr diesen Begriff BDFL, Benevolent Dictator for Life, mal seht, dann wisst ihr nun, was es bedeutet. Und aber eins muss ich nochmal dazu sagen, natürlich ist es überall da, wo Entscheidungen getroffen werden, gibt es auch Verlierer. Und Verlierer in diesem Sinne, das meine ich damit, dass die Personen nicht ihre bevorzugte Lösung bekommen haben, aber es geht halt um mein Projekt, um meine Software und zweitausendein, der BDFL schreibt sich halt oft auf die Fahne, maßgeblich für dieses Projekt verantwortlich zu sein, so dass es auf der einen Seite diese große Popularität erreicht hat und b, natürlich auch diesen einheitlichen Stil hat. Das war es soweit zum Term BDFL. Ich hoffe jetzt nicht, dass ihr der BDFL von jeder kleinen Library sein wollt, denn ich denke, viele Projekte brauchen kein BDFL. Sehr große Projekte mag es positiv sein, aber moderne Governance, wie Wolfgang sagte, lässt sich auch durch Steering Komitees und Gruppen entscheiden, wobei man natürlich darauf achten muss, dass man auf der einen Seite ein klares Regelwerk fürs Voting hat, 2/3 Mehrheit oder ähnliches, oder wenn man zu zweit ist, vielleicht besser zu dritt sein sollte, damit man immer eine Entscheidung hat, weil ich bin für eine Entscheidung, aber gegen Münze werfen, weil das ist einfach random und hat einfach kein why, kein Grund dahinter. Das war's von uns vor Weihnachtszeit und tschüss.

Wolfi Gassler (00:12:44 - 00:13:13)

Das war's mit dieser Mini Episode. Ich hätte noch viel zu sagen gehabt, aber wir respektieren natürlich auch eure Zeit. Was mich natürlich jetzt interessieren würde, wie stehst du generell zu dieser Position oder dem Begriff an sich und bist du vielleicht sogar ein WDFL? Lass uns das doch mal wissen, entweder über Social Media oder in unserer Discord Community. Ist übrigens auch eine gute Gelegenheit, dein Open Source Projekt vielleicht zu bewerben. Wir freuen uns also auf dein Feedback und wünschen noch eine besinnliche, kommunikative Zeit.