#148 Wenn Open Source eigene Wege geht: Forking und seine Folgen

Forking: Ein Grundpfeiler von Open Source mit eigenen Herausforderungen

Das tolle an Open Source? Man hat das Recht, die Software zu modifizieren und auch in ihrer modifizierten Form zu verbreiten. Wenn man plant, das Open Source Projekt zu modifizieren und unabhängig von seiner Ursprungsform weiterzuentwickeln, nennt man dies Fork bzw. Forking. Das klingt erstmal super und nach viel Freiheit. Doch Forking hat ganz eigene Herausforderungen.

In dieser Episode klären wir, was Forks sind, welche populären Forks es in der Geschichte von Open Source gegeben hat und was die Motivation dieser Forks war, welche Projekt-Forks es nicht zur Popularität geschafft haben, warum Forking auch als Druckmittel genutzt werden kann und warum es eine Art Grundrecht auf GitHub ist, welche (oft unsichtbaren) Herausforderungen Forking mit sich bringt und klären, was das Urheberrecht und der Digital Millennium Copyright Act (DMCA) aus den USA damit auf sich hat..

Bonus: Bei Debian hieß der Firefox Browser mal Iceweasel.

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

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Die Vorteile von Open Source

(00:05:41) Info/Werbung

(00:06:41) Die Vorteile von Open Source

(00:14:31) Erfolgreiche Forks aus der Open Source Welt

(00:29:08) Forks, die es "nicht geschafft" haben

(00:36:59) Die Motivation, ein Projekt zu Forken und das Urheberrecht

(00:44:50) Der Rattenschwanz des Forkens von großen Projekten

(00:53:46) Ist forken ein positives oder negatives Zeichen?

(01:01:16) Kommunikation ist das wichtigste Element in der Open Source Community

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:04 - 00:02:01)

Eine weitere Episode vom Engineering Kiosk, deinem deutschsprachigen Softwareentwicklungspodcast. Weißt du, was eine tolle Sache an Open Source ist? Man hat das Recht, die Software zu modifizieren und auch in ihrer modifizierten Form zu verbreiten. Wenn man plant, das Open Source Projekt zu modifizieren und unabhängig von seiner Ursprungsform weiterzuentwickeln, nennt man dies Fork bzw. Forking. Das klingt erstmal super und nach viel Freiheit, doch Forking hat ganz eigene Herausforderungen. In dieser Episode klären wir, was Forks sind, welche populären Forks es in der Geschichte von Open Source gegeben hat und was die Motivation dieser Forks war, welche Projektforks es nicht zur Popularität geschafft haben, warum Forking auch als Druckmittel genutzt werden kann und warum es so eine Art Grundrecht auf GitHub ist, welche oft unsichtbaren Herausforderungen Forking mit sich bringt. Und wir klären, was das Urheberrecht und der Digital Millennium Copyright Act DMCA aus den USA damit auf sich hat. PS, wusstest du, dass bei Debian der Firefox Browser einmal Ice Weasel hieß? Warum? Genau das erklären wir, wenn du dran bleibst. Los geht's. Viel Spaß. Wolfgang, auch du musst deine Brötchen verdienen. Und du verdienst deine Brötchen oft in beratender Funktion, nämlich als Consultant externer bei hoffentlich dem guten österreichischen Mittelstand. Und stell dir vor, ich wäre jetzt der gute österreichische Mittelstand, würde dich beauftragen und meine erste Frage ist eigentlich lieber Herr Gassler, können sie mir einfach mal erklären, was denn eigentlich das tolle an Open Source ist? Warum sprechen alle meine technischen c Level Kollegen vom Mittelstandsstammtisch hier in Tirol über Open Source? Und warum sagen die, ich sollte mir mal überlegen, von proprietären Software Vendoren wegzugehen und zu schauen, ob ich nicht eine Open Source Lösung machen kann? Was würdest du dann antworten, was das tolle an Open Source ist? Was sind tolle Attribute an open Source?

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

Die Frage ist, ob du jetzt meine Meinung hören willst oder die vom Mittelstand. Weil die vom Mittelstand oder von ganz vielen Firmen ist, das ist gratis, das kostet uns nichts.

Andy Grunwald (00:02:10 - 00:02:20)

Da ich als Mittelstand dich ja engagiert habe, musst du mir ja nicht die Mittelstandsmeinung nennen, sondern ich frage dann als Mittelstand ja deine Meinung, damit ich eine neue Meinung kriege.

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

Wahrscheinlich muss ich dich jetzt enttäuschen, weil höchstwahrscheinlich ist noch immer die Aussage, für die meisten Firmen ist wahrscheinlich der Kostenpunkt das einzige, was irgendwie ausschlaggebend ist und denen weiterhilft. Weil wenn man mit allen anderen positiven Dingen von Open Source kommt, die eigentlich viel wichtiger sind, dann ist es meistens für die Leute nicht mehr relevant. Leider muss man dazu sagen, weil es will niemand irgendwie Zeit in die Hand nehmen, um zu contributen oder seine Leute das zu ermöglichen, dass die kontributen, geschweige denn Geld ausgeben natürlich in irgendeiner Form.

Andy Grunwald (00:02:50 - 00:03:09)

Finde ich sogar eine sehr gute Antwort und ich bin jetzt gar nicht enttäuscht. Meine Folge Follow up Frage wäre als immer noch in der Rolle des österreichischen Mittelstandes. Herr Kassler, können sie mir erklären, warum Open Source so populär ist? Was ist das Faszinierende an Open Source? Warum ist das eine. Ich habe sogar den Begriff Bewegung schon mal gehört im Open Source.

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

Möchte nur anmerken übrigens, dass in Tirol niemand bei sie ist. Wir sind alle bei du.

Andy Grunwald (00:03:13 - 00:03:31)

Ich bin ja kein Österreicher, ich bin ja Deutscher, der im österreichischen mittelstand arbeitet. Also ich habe inzwischen verstanden, dass das gratis ist, die Software. Doch wieso stecken da so viele Leute Arbeit rein? Was ist an dieser Bewegung dran? Wir sind ja nicht mit mehr bei den ERN, mit den ganzen Hippies und dem kiffen und das waren die er. Entschuldigung, aber wenn ich es auf das.

Wolfi Gassler (00:03:31 - 00:04:22)

Wichtigste Argument runterbrechen müsste, würde ich wahrscheinlich sagen, dass Entwicklerinnen ein sehr gutes Gefühl haben, wenn ihr Code verwendet wird in irgendeiner Form. Das Heißt, wenn, wenn es da User gibt, wenn das irgendwie Leute weiterbringt. Und bei Open Source hast du das natürlich, dass du weltweit vielleicht Leute ansprechen kannst. Also wenn du irgendwas entwickelst, was dann andere gut finden, wo du merkst, denen hilft es was, du bekommst vielleicht sogar Feedback, das ist cool, das hat mir weitergeholfen, das hat unsere Firma weitergebracht, dass das bei den Leuten, die das kreieren und erstellen, positive Gefühle auslöst, weil man kann natürlich open Source veröffentlichen und es verwendet dann niemand, aber ob das dann so dasselbe Gefühl ist und ob das so viel Spaß macht. Also ich glaube, die meisten veröffentlichen schon, damit andere irgendwas davon haben. Also das Teilen in irgendeiner Form und das positive Feedback dann zu bekommen. Was wäre dein Take?

Andy Grunwald (00:04:22 - 00:04:45)

Das ist ein guter Punkt, den du genannt hast. Die Downside ist natürlich, du weißt erst, dass dein Open Source Tool oder was auch immer du veröffentlicht hast, dass es benutzt wird, wenn du ein Issue bekommen hast oder eine Danke e Mail oder, oder oder. Oft sind das ja die sogenannten Lurker, die die große Mehrheit darstellen. Lurker sind die Leute, die immer nur konsumieren, aber nicht zu dem, was sie konsumieren, beitragen. Nehmen wir mal z.b. hacker News, den.

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

Mittelstand, also die ganzen Firmen, die es einfach so benutzen. Ah, die können ja wenigstens den Start drücken, oder? Dann bekommst du ja auch schon ein bisschen Feedback.

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

Das hast du jetzt gesagt, aber nehmen wir mal z.b. hacker News, da ganz wenige Leute Kontributen zu Hacker News reichen links, einkommentieren, viel mehr lesen. Also lerken ist bei Open Source natürlich genauso. Ganz wenige Contributen, viele, viele, viele Leute laden sich die Software runter und modifizieren. Und eine Thematik, du hast jetzt aus der contributer Sicht gesprochen, ich spreche jetzt mal aus der aus der Benutzersicht. Da hast du natürlich ketzerisch gesagt, die Software ist gratis, darf man so benutzen.

Wolfi Gassler (00:05:21 - 00:05:41)

Wobei ich möchte nur dazu sagen, ich möchte jetzt nicht den Mittelstand schlecht reden, weil ich glaube, das ist bei allen Firmen so, also auch gerade bei den großen Enterprise Firmen, die sich vielleicht noch eher leisten können, da gibt es auch ganz oft Probleme und da wird noch härter kalkuliert und gar nichts gemacht. Also möchte es jetzt nicht nur auf den Mittelstand beziehen. Ich glaube von Startup bis zu Enterprise ist es überall da.

Andy Grunwald (00:06:41 - 00:06:51)

Ich würde sagen, das tollste an Open Source ist folgender Grund, den ich auch sehr oft in meinem erweiterten Bekanntenkreis höre, auch von nicht Technikern, dass ich die Möglichkeit habe, den Source Code zu ändern.

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

Das hört man oft, aber wie viele Leute machen es dann wirklich?

Andy Grunwald (00:06:54 - 00:08:10)

Und das ist genau mein Knackpunkt, nämlich für diese Episode. Da wollte ich nämlich drauf hinaus, denn für mich ist das so wie dieses zweitausendeinundzwanzig originale Battle zwischen Hey Wolfgang, warum hast du eigentlich ein Android Telefon? Ja, du mit deinem Apple proprietären System, ja, und sage ich, was machst du mit deinem Android Telefon? Ja, wenn ich möchte, kann ich hier alles modifizieren, ist ja alles offen. Dieses Statement habe ich schon so oft gehört und lustigerweise stimmt das ja eigentlich gar nicht. Denn erstens kannst du da alles modifizieren? Ja, kannst du, kannst du das auf dem Betriebssystem, was du jetzt gerade auf deinem Telefon hast? Mit hoher Wahrscheinlichkeit nicht. Denn wenn du ein Samsung hast oder ein Xiaomi Telefon, dann ist da zwar ein Android Betriebssystem drauf. Xiaomi, Xiaomi, dann ist da zwar ein Android Telefon drauf oder ein Android Betriebssystem, aber es ist eine, aber es ist ein Android Derivat. Das bedeutet, die haben sich Android genommen, ihren eigenen App Store darauf geknallt, deutlich modifiziert und all die Modifikationen haben die gegebenenfalls gar nicht öffentlich gemacht, sondern ist alles closed source und das haben die dann auf dein Telefon gespielt. Natürlich kannst du das Telefon mit einem, ich nenne es mal naturellem Android bespielen. Meine Frage ist an dich als Android Nutzer, wie viele Leute kennst du, die wirklich ein naturelles Android fahren und nicht das Android Derivat von ihrem Handyhersteller, also ein offenes Android.

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

Es sind in der Tat einige, aber es sind natürlich alles ziemliche Nerds und teilweise aus der Security Ecke oder Linux Ecke. Wenn man das jetzt aber wieder umbricht auf die Firma, muss ich schon sagen, dass dieses Argument natürlich schon was zählt. Weil gerade wenn du jetzt als Firma sagst, okay, investiere jetzt was in irgendeinem Bereich und das muss jetzt 10 Jahre funktionieren, dann gibt dir das natürlich schon eine gewisse Sicherheit oder nimmt das Risiko weg, dass die Firma pleite geht, dass die Firma irgendwas in ihrem Business Modell ändert und vielleicht auf ein Subscription Modell umsteigt. Diese Sicherheit hast du im Open Source Bereich natürlich schon, wenn du Änderungen machen könntest, auch wenn du selbst es nicht durchführst, gibt es vielleicht eine andere Firma, die einen Fork macht, die das offen hält, die dann trotzdem mit dem alten Businessmodell weiterfährt oder mit einem anderen Business Modell. Also gerade im Firmenbereich zählt es, glaube ich, noch viel, viel mehr als im privaten.

Andy Grunwald (00:08:59 - 00:09:43)

Ÿousand, ich habe gerade die Android Story erzählt und eine ähnliche Story, die relativ wenig mit Technik zu tun hat, ist eigentlich der Company Benefit von unbegrenztem Urlaub. Ich glaube, Netflix hat den mal eingeführt. Die Realität ist ja, zumindest im Internet, dass man sagt, man nimmt dadurch deutlich weniger Urlaub. Aus meiner eigenen Erfahrung, bei unbegrenztem Urlaub habe ich nie mehr als, ich sage mal, dreiig Tage genommen, was, ich würde mal sagen, für viele ITler in Deutschland so Standard ist. Für mich ist der faszinierende Punkt an diesen beiden Stories, an der Android und an der unbegrenzten Urlaubsstory eigentlich, und auch bei Open Source, dass es für unglaublich viele Menschen sehr, sehr wichtig ist, dass man die Möglichkeit hat, den Source Code zu ändern.

Wolfi Gassler (00:09:43 - 00:10:12)

Das ist ja Risk Assessment, oder? Also wenn du das sehr sinnvoll planst, du planst ja nicht immer nur für jetzt, sondern auch für mögliche Situationen, Szenarien in der Zukunft. Und als Firma natürlich noch viel mehr, als privater jetzt eher weniger, aber wenn du das sauber machst und ein risk Assessment machst, zählt es natürlich schon, auch wenn du das nie verwendest oder gar nie in die Situation kommst. Aber dann könntest du ja auch sagen, okay, du bezahlst keine Versicherungen mehr in Zukunft, weil das ist ja auch nur eine Wette, obwohl du die nie in Anspruch nimmst, die Versicherung, dass dein Haus abbrennt.

Andy Grunwald (00:10:12 - 00:10:23)

Ich wollte gerade fragen, sind Österreicher auch überversichert, so wie Deutsche? Weil Risiken und Risk Assessments, die evaluiert man ja bei jedem großen Projekt nach ihrer Eintrittswahrscheinlichkeit.

Wolfi Gassler (00:10:24 - 00:10:46)

Ich kann dir jetzt keine Statistik nennen, aber ich kann dir z.B. sagen, dass aktuell ein Problem ist, z.B. mit den ganzen Unwettern bei den Landwirten, dass die Versicherer derzeit sagen, aktuell geht es in die Richtung, dass die Sachen nicht mehr versicherbar sind in Zukunft, weil du ja eigentlich nur Sachen versicherst, die selten eintreten. Wenn du weißt, dass etwas jedes Jahr eintritt, kannst du es eigentlich nicht mehr versichern.

Andy Grunwald (00:10:46 - 00:10:48)

Das ist korrekt. Kommen wir wieder zurück zur Technik.

Wolfi Gassler (00:10:48 - 00:10:54)

Aber willst du jetzt damit sagen, dass nur Leute, die sich gerne überversichern, auch Open source verwenden?

Andy Grunwald (00:10:54 - 00:11:40)

Nein, was ich damit sagen möchte, ist, dass ich das psychologisch unglaublich faszinierend finde, dass Leute die Möglichkeit, etwas durchzuführen, z.B. den Source code zu verändern, sehr, sehr hoch in ihren Entscheidungsfaktoren mit einfließen lassen und es kaum machen. Und weil dieses Event im Kontext von Open Source, den Source Code zu verändern und eine veränderte Version selbst zu nutzen, so selten vorkommt, habe ich mir gedacht, darüber machen wir mal eine Episode zweitausendein. Und diese Episode geht komplett um das Thema Forking bzw. Forks mit dem eigentlichen Ziel, was Forks sind, welche populären Forks es gibt, aber auch welche Probleme das hinten dran hat. Denn obwohl man die Möglichkeit hat, den Source Code zu verändern und ihn auch in der veränderten Version zu nutzen, hängt da ein Rattenschwanz an Fallstricken dran.

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

Aber klären wir mal, was ein Fork wirklich ist. Weil wenn ich jetzt als Firma z.B. irgendeine Open Source Software, keine Ahnung, Redmind, dieses Ticketing System oder Metabase zur Visualisierung, nehme ich Fork das ganze oder lade mir den den Source code runter und ändere jetzt z.b. das Layout, baue da mein Logo ein für meine Firma, verändert da vielleicht ein, zwei Dinge. Ist es dann schon Forken oder ab wann sprichst du von dem Fork?

Andy Grunwald (00:12:08 - 00:12:20)

Wenn ich von dem Fork spreche, spreche ich erst mal nicht von einer Gabel. Das ist die erste Baustelle und die zweite Baustelle. Ich spreche von einem Fork, wenn das Projekt in einer anderen Art und Weise und unabhängig vom ursprünglichen Mutterprojekt weiterentwickelt wird.

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

Also wenn es auch dann wieder zur Verfügung gestellt wird. Also nicht nur, wenn ich das für meine Firma adaptiere, sondern dann auch wieder zur Verfügung stelle.

Andy Grunwald (00:12:27 - 00:12:53)

Z.B. wenn du jetzt GitLab forkst und GitLab hat keine Funktionalität zum Logo anpassen und du möchtest deine und du möchtest ein Corporate Design auf GitLab haben und du musst dafür den GitLab Source Code modifizieren und hast diesen Fork, diesen diese Kopie des Source Codes bei dir lokal, proprietär irgendwo liegen. Natürlich ist das dann auch ein Fork, weil du hast den Source Code verändert. Diese Möglichkeit, von der wir gerade die ganze Zeit gesprochen haben.

Wolfi Gassler (00:12:53 - 00:12:58)

Wobei das jetzt natürlich noch nicht heißt, dass ihr das ganze Projekt jetzt in eine andere Richtung treibe.

Andy Grunwald (00:12:58 - 00:14:31)

Nee, aber du hast die Möglichkeit, deine geänderte Version ursprünglich vom Mutterprojekt weiterzuentwickeln. Ob du dann tust oder nicht, sei dahingestellt, aber du hast den Source Code verändert und das kannst du bei proprietärer Software in der Regel nicht. Ja, wenn du den Source Code von proprietärer Software hast, kannst du das schon, aber auch dann wird der Support vom proprietären Softwarehersteller eingestellt, weil du hast an der Software rumgefummelt und der Vendor weiß nicht mehr, was passiert. Und beim Fork ist das genauso. Du kannst dir ja nicht GitLab runterladen, dein Logo da einbauen, Buttons verschieben und dann auf dem ursprünglichen Mutterprojekt, was in diesem Kontext eigentlich auch upstream heißt, ein Issue aufmachen, mein JavaScript geht nicht mehr, weil dann sagt das ursprüngliche Mutterprojekt upstream nämlich auch, ja Moment mal, aber du hast da alles umgestellt, da kann ich dir jetzt keinen Support mehr geben. Ich weiß ja gar nicht, was du umgestellt hast. Ÿousand. Und das Lustige ist jetzt eigentlich, wir reden jetzt natürlich im Forking Bereich nur von du machst Code Editierung, aber jeder von uns, der schon mal ein Pull Request gemacht hat, hat eigentlich ein Projekt geforkt. Denn bei einem klassischen GitHub Projekt ist Forking Teil des normalen Pull Request Workflows. Wolfgang, du hast jetzt ein Projekt, ich möchte das verbessern, ich forke dein Projekt in meinen Account, mach meine Änderungen, Branche, erstelle einen neuen Branch, mache meine Änderung und pushe den Branch zu meiner Instanz, zu meinem Fork. Dank GitHub und auch wie GitLab und BitBucket ermöglichen die mir dann, dass ich meinen Branch in meinem Fork als Änderung zu deinem Projekt, zu dem Mutterprojekt, zu Upstream wieder zurückkommt. Also eigentlich jeder, der schon mal ein Pull Request auf GitHub gemacht hat, hat eigentlich schon mal ein Fork gemacht.

Wolfi Gassler (00:14:31 - 00:15:05)

Jetzt ist es eine sehr technische Beschreibung, die du da gegeben hast, weil im klassischen Volksmund, wenn man von Fork spricht, dann spricht man jetzt eher von Ÿousand, dem was du in deiner Definition gesagt hast. Man treibt das Projekt in eine komplett andere Richtung. Also wenn ihr da an meine Heimat denke, also im Sinne von Datenbankheimat, dann ist da natürlich mariadb und MySQL z.b. so ein absoluter Klassiker. Da gibt es einen Streit und dann gibt es einen Fork. Das ist, was ich so unter Fork verstehe. Wenn ich eigentlich Fork höre, ich denke nicht dann, ich habe einen Fork gemacht, haben Bull Request gemacht, damit er dann was zurückkontributet.

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

Wenn du Volksmund sagst, denke ich immer daran, dass das irgendwie so eine Headline in der Bild Zeitung ist. Mariadb wurde von Mais Gol gefolgt.

Wolfi Gassler (00:15:13 - 00:15:25)

Maria klingt eigentlich eh so wie im Volksmund, so ein Volksname, aber in Österreich sollte man mit dem Volkszeug jetzt nicht gerade aktuell politisch so herumposaunen, aber ist ein anderes Thema. Bitte. Ja, MariaDB und Maiskoel wolltest du sagen.

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

Aber in der Tat ist wohl einer der erfolgreichsten Forks in letzter Zeit in der Datenbankwelt. Du hast aber gerade Streit genannt und ein Streit liegt diesem Fork meines Wissens nach nicht zugrunde, sondern eher eine Befürchtung. Und zwar hat Sun Microsystems im Jahr 2008 MalsQL gekauft und im Jahre 2010 wurde Sun Microsystems von Oracle übernommen. Und die Open Source Community, die MySQL Open Source Community, hat befürchtet, dass Oracle mit MySQL weniger offen bzw. Primär kommerziell gestalten würde. Und deswegen haben sie unter anderem mariadb rausgefolgt. Und deswegen hat unter anderem der damalige oder einer der damaligen Core Entwickler, Monty, mariadb rausgefolgt. Also es ist kein Streit gewesen, meines Wissens nach, sondern eine Befürchtung, wie Oracle mit der Datenbank umgeht.

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

Richtiger Streit war dann natürlich nicht, aber wenn ich das richtig im Kopf habe, hat Monti dann gekündigt, weil der war bei Sun noch dabei. Aber man muss schon sagen, das Verhältnis war dann noch relativ okay, auch wie sich vielleicht Oracle dann entwickelt hat, weil wenn man so auf den MySQL Konferenzen sich herumgetrieben hat, war das schon immer noch ein sehr inniges Verhältnis. Also die Leute haben sich gekannt, die haben noch miteinander gesprochen. Es war immer noch mariadb sehr stark auf den Konferenzen neben MySQL. Also es hat irgendwie so coexistiert oder existiert immer noch nebeneinander. Und die Leute gehen eigentlich, so wie ich das zumindest immer erfahren habe, bei den Konferenzen sehr nett miteinander um. Es fliegen dann vielleicht so ein paar subtile Jokes irgendwo von der Bühne runter oder rauf, aber im Großen und Ganzen sind die Leute eigentlich schon noch befreundet und arbeiten auch noch relativ gut miteinander, muss man schon sagen. Wir haben da übrigens auch eine Episode gemacht, die Episode 69, MySQL versus MariaDB, wer sich da mal näher interessiert.

Andy Grunwald (00:17:12 - 00:17:18)

Aber Oracle selbst ist anscheinend für eine ganze Menge Forks verantwortlich. Man könnte sie vielleicht auch die Fork.

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

Company nennen, ja, aber unfreiwillige. Also es haben andere dann immer gefolgt durch andere Akquisitionen.

Andy Grunwald (00:17:24 - 00:19:01)

Denn als Oracle Sun Microsystems gekauft hat, kam dann nicht nur MySQL mit, sondern nämlich auch eine Software namens Star Office und StarOffice wurde dann nach OpenOffice geforgt. Kennt ihr vielleicht noch apache OpenOffice zweitausendein oder inzwischen apache Open Office. Und zwar war das der gleiche Grund, dass man durch die Übernahme von Oracle eine gewisse Unsicherheit in der Community hatte. Okay, wie geht das jetzt weiter mit mit Star Office und so weiter? Dann wird OpenOffice gegründet. Die Entwicklung an Open Office selbst stagnierte dann aber zu einem späteren Zeitpunkt. Und wiederum wurde dann OpenOffice erneut geforgt in LibreOffice. LibreOffice hat dann nicht nur Open Office gefolgt, sondern auch the Document Foundation gegründet und somit eine ein Governance Modell oben drauf gesetzt. Also man eigentlich sagen von Star Office zu OpenOffice zu LibreOffice ist es vielleicht ein doppelter Fork, obwohl OpenOffice aber noch existiert. Und jetzt könnte man sagen, wieso nennt man Oracle jetzt die Fork Company? Eigentlich alle Leute, die Software entwickeln, die kommen um ein System nicht drum herum, ob sie wollen oder nicht, ist für viele so eine Hassliebe und zwar Jenkins. Jenkins ist ein continuous integration Server und Jenkins ist selbst auch ein Fork. Jenkins stammt aus Hudson. Hudson ist ein Projekt, was aus Sun Microsystems stammt und ebenfalls es wurde gefolgt, als Sun Microsystems von Oracle gekauft wurde. Und die Hudson Community hatte Bedenken bezüglich der Kontrolle. Und die künftige Entwicklung von Hudson ist immer noch ein Projekt in der Eclipse Foundation, so viel ich weiß, ist aber in der Entwicklung stagniert. Und Jenkins lebt in der CI und CD Community. Viele Leute wollen das System zwar nicht nutzen, aber es ist immer noch ein sehr, sehr stabiles System, muss man leider sagen.

Wolfi Gassler (00:19:01 - 00:20:13)

Ein sehr bekannter Fork, den wir auch schon mal in einer Episode besprochen haben, und zwar in der Episode 86, ist der Fork von Nextcloud. Wir haben ja in der Episode auch mit dem Gründer von OnCloud, also von dem Nextcloud ja weggefuckt wurde, gesprochen, der gleichzeitig Gründer von owncloud und Gründer von Nextcloud ist. Und da merkt man schon auch, dass ganz oft bei diesen Forks der kommerzielle Gedanke ein Problem ist. Also wenn sich Projekte in eine Richtung entwickeln, dass es zu kommerziell wird, dass vielleicht Teile auch nicht mehr open source sind, wie es bei OnCloud der Fall war. Dass sogar dann die eigenen Leute, wieder Frank, der erzählt es in der Episode auch ganz gut, dann unzufrieden ist oder mit den Investoren nicht mehr kann, dass er seine eigene Firma eigentlich forkt. Also der hat nicht nur den Source Code gefolgt, sondern eigentlich auch die eigene Firma, hat die Belegschaft teilweise auch noch mitgenommen, also auch rausgefoggt, um dann eben das in eine andere Richtung zu treiben, in seiner Perspektive eben die richtige Open Source Richtung, dass alles Open source ist, alles offen ist. Kann man aber gerne in der Episode 86 nachhören. Also eigentlich könnte man vielleicht sagen, so die Investorwelt sind eigentlich so die Treiber, die die Forks vorantreiben.

Andy Grunwald (00:20:13 - 00:22:06)

Bei Oracle ist das weit hergeholt, weil ich glaube, als Sun Microsystems übernommen wurde, hatte das Leadership von Oracle jetzt nicht auf dem Schirm, oh ja, da könnte es Forks von Jenkins, Star Office und MySQL geben. Aber wo du auf jeden Fall recht hast, ist bei den Forks aus der Datenbankwelt, die eigentlich große Wellen geschlagen haben, und zwar einmal bei Elasticsearch wurde zu OpenSearch gefolgt und einmal bei Redis. Und da ist der Fork Valkey entstanden und eigentlich aus den gleichen Gründen, und zwar Elasticsearch mit der Firma Elastic Inc. Dahinter, hat die Datenbank erstellt und hat sich gedacht, hey, wieso machen die ganzen Hyperscaler denn eigentlich so viel Geld mit meinem Service und ich nicht? Und da haben die einfach gesagt, ja, dann ändern wir doch mal die Lizenz, und zwar von der apache Lizenz auf die Server side Public Lizenz. Und die Server side Public Lizenz schränkt eigentlich die Nutzung der Software in Cloud Umgebungen ein. Das heißt jetzt nicht, dass du, Wolfgang, als Enduser Elasticsearch nicht mehr auf EC betreiben darfst, sondern eigentlich, dass Amazon dir keinen managed Elasticsearch anbieten kann. Und somit bricht natürlich ein unglaubliches Market Offering von den Hyperscalern weg, in der Hoffnung, dass die ganzen Kunden, die vorher Elasticsearch auf Amazon betrieben haben, jetzt zu Elastic Inc. Gehen und sich das da als Managed Service einkaufen. Zweitausendein. Und das gleiche ist auch mit Redis passiert. Die Firma hinter Redis nennt sich Redis Labs. Die sagten auch, hey, wieso verdienen eigentlich alle anderen Hyperscaler und Datenbank as a Service provider Geld mit Redis, nur ich nicht, beziehungsweise nicht so viel, ich hätte ja mehr haben können. Und deswegen haben die gesagt, oh, wir ändern ebenfalls die Lizenz. Und dann hatten sich die Redis Community gedacht, ja Moment mal, dann forken wir das ebenfalls weg, nennt sich jetzt Valky, das Projekt ist ein Teil der Linux Foundation geworden, zweitausendein, das kann also auch ein Grund sein, bzw. Das würde ich auch als Grund sehen, wie Investoren Forks vorantreiben oder erzwingen mehr oder weniger.

Wolfi Gassler (00:22:06 - 00:23:07)

Wobei das natürlich teilweise schon auch verständlich ist, wenn dann natürlich andere Firmen sehr große Gewinne daraus erzielen und man kennt ja die die Gewinne von den, von AwS z.B. die halt irgendwie eine Spanne von 60, guten 60 % drauf haben, dann denkt man sich da natürlich als Open Source Entwickler dann auch irgendwie, ja du investierst da deine Zeit vielleicht, egal ob jetzt als Firma oder als Privatperson und die anderen machen viel Kohle damit. Das entspricht ja auch nicht so ganz dem Open Source Gedanken und keine Ahnung wie viel Amazon z.B. zurück beigesteuert hat dem dem Projekt, das kann ich jetzt auch nicht einschätzen, aber ich kann das zumindest in irgendeiner Form nachvollziehen, dass das bei den Firmen oder auch bei den Entwicklerinnen definitiv ein Problem ist. Und ich kann da auch persönlich nachfühlen, weil du kennst halt dann irgendwo zweitausendein Leute, die dein Open Source Projekt einsetzen und du denkst dir, sind teilweise große Firmen, haben extrem viel Gewinn und die verwenden dein Open Source Produkt so einfach und du bekommst keinen einzigen Euro davon. Also ich kann das durchaus nachvollziehen, aber ich verstehe natürlich auch, dass es ein großes Problem ist.

Andy Grunwald (00:23:07 - 00:23:25)

Ist ein zweischneidiges Schwert, weil Eine Sache, die du ganz vergisst ist a, die Entscheidung, die ganze Sache open source zu entwickeln, kam von Elastic Inc. Oder beziehungsweise haben die das Produkt entwickelt und dann später Elastic Ink drauf gesetzt. Das bedeutet, es war eine aktive Entscheidung von den Creatorn. Das ist die erste Baustelle, was interessiert.

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

Mich das Geschwätz von gestern? Kann ja auch wieder schlauer werden als Entwickler, oder? Oder mir kann es ja auch innerlich dann wehtun, auch wenn ich dann trotzdem dahinter stehe, aber es kann ja trotzdem wehtun in dem Sinne.

Andy Grunwald (00:23:38 - 00:23:49)

Das ist richtig, aber auch die Produkte Elasticsearch und Redis sind so populär, weil sie als Open Source gestartet haben und wären sie proprietär gestartet, wäre es vielleicht niemals zu einem zweitausendein solchen Bekannten.

Wolfi Gassler (00:23:49 - 00:24:19)

Ja, es ist ja nicht proprietär, aber die Frage ist, wären sie so bekannt geworden, hätten sie mit der server Seite Public license gestartet. Das ist ja immer die Frage und es wird sich, die wird sich zeigen, weil es gibt ja einige Projekte oder recht viele Projekte, die mittlerweile mit solchen Lizenzen starten, dass du das alles frei verwenden kannst, außer du bist ein Hosting Anbieter oder eine Cloud, dann musst du eben zahlen und du kannst es nicht hosted managed anbieten. Und das wird sich zeigen in den nächsten Jahren, ob das eine Möglichkeit ist und wie das angenommen wird von der Community.

Andy Grunwald (00:24:19 - 00:25:19)

Genau. Bei Elasticsearch gibt es aber nochmal eine Sonderfunktion bzw. Eine Sonderentwicklung, denn Open Search ist als Fork aus Elasticsearch hervorgegangen. Um Open Search hat sich ein Komitee gegründet und Amazon ist ganz, ganz, ganz stark im Komitee von Open Search vertreten. Fast alle Core Entwickler sind Amazon Entwickler, bis auf wenige Ausnahmen. Und du siehst auch bei den ganzen Hyperscalern, dass Elasticsearch durch Open Search ersetzt wurde und es ist ein neues Produkt geworden. Also Open Search hat Features zweitausendeinundzwanzig, die Elasticsearch nicht hat, und vice versa. Sehr, sehr vergleichbar mit MySQL und MariaDB. Und jetzt kommt das Lustige. Seit 29. Aug. 2024 ist Elasticsearch wieder open source. Und die Begründung war, wir haben unser Ziel erreicht. Amazon rennt mir nicht mehr den Market Share ab, so als Tool didn't read. Aber das hat natürlich, ich sag mal, ich glaube, wie sagt man in Baden Württemberg, ein Beigeschmäckle, Geschmäckle. Ÿousand, ich komme aus Nordrhein Westfalen, tut mir leid für alle Leute aus Baden Württemberg, aber ich glaube, das nennt man a geschmäckle.

Wolfi Gassler (00:25:19 - 00:25:26)

Hast du super schön gesagt. Es kann sogar ich hören, dass das falsch ist von der Aussprache, aber ich hab's versucht.

Andy Grunwald (00:25:26 - 00:25:48)

Aber Geld ist nicht der einzige Treiber von Forking, denn ich weiß nicht, ob es alle noch wissen, aber 2014 gab es eine richtig große Lücke in OpenSSL, die nannte sich Heartbleed. Und dabei hat man festgestellt, dass OpenSSL eigentlich die Basis für das moderne Internet und für moderne Verschlüsselung ist.

Wolfi Gassler (00:25:48 - 00:25:49)

Neben Curl meinst du, oder?

Andy Grunwald (00:25:49 - 00:26:49)

Neben Curl, ganz genau. Auf jeden Fall, OpenSSL wurde damals von zwei Leuten entwickelt in ihrer Freizeit, vielleicht von einem, der noch bei einer Firma angestellt wurde, auf jeden Fall von unglaublich wenigen Leuten. Das ist auch sehr alte Software und es war auch nie Geld da bzw. Wurde nie die Priorität gesehen, OpenSSL mal zu modernisieren. Dann kam Hardbleed, dann wurden da die Scheinwerfer auf diese Software gelenkt und das OpenBSD Team und die ganzen BSD Derivate wie OpenBSD, Net BSD, Dragonfly und FreeBSD sind alle sehr, sehr sicherheitsbedacht. Die haben damals OpenSSL gefolgt in Libre SSL, primär aus der Motivation, weil OpenSSL viele veraltete und schlecht dokumentierte Teile hatte, die unter Umständen die Sicherheit gefährdeten, wie man z.B. bei Heartbeat gesehen hat. Und libre ssl ist jetzt die OpenSSL Variante, die unter anderem in OpenBSD verwendet wird. Also jetzt nicht nur Geld motiviert Leute zum forken, sondern auch Security, was ich.

Wolfi Gassler (00:26:49 - 00:26:58)

Natürlich auch sehr positiv und du hast schon FreeBSD erwähnt. BSD ist ja auch so eine Bubble, wo links, rechts, nach oben, nach unten gefolgt wird, wie es losgeht.

Andy Grunwald (00:26:58 - 00:27:31)

Ja, es gibt so ein paar BSD Derivate, das stimmt schon. Ich meine, OpenBSD ist ja selbst auch ein Fork. Ich habe gerade von OpenBSD gesprochen, aus NetBSD und so weiter. Also da kann man sich, glaube ich, den ganzen Forkbaum mal im Internet ansehen. Warum man forken sollte bzw. Kann bzw. Gefunden wird, ist eigentlich, wenn die Weiterentwicklung eines Projektes, welches ich nutze, stagniert, wenn der oder die Maintainerin einfach nicht mehr weiterentwickelt, keine Pull Requests mehr annimmt, keine Issues mehr beantworten.

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

So wie du bei deinen 18 oder wahrscheinlich eher acht und dreiig Open Source Projekten.

Andy Grunwald (00:27:35 - 00:27:59)

Ganz genau, so wie ich. Aber aber ich habe ja schon mal in diesem Podcast erwähnt, dass ich meine Meinung zu Open Source ja etwas geändert habe. Ich bin ein riesen Open Source Fan. Ich kontribute auch immer noch, aber ich sehe es auch nicht immer als meine Pflicht an, bugs zu fixen, die andere betreffen, die ich gerade nicht habe. Und für mich ist es schon ein genug geben, wenn ich den Source Code, den ich geschrieben habe, veröffentliche und Leute können das nutzen.

Wolfi Gassler (00:27:59 - 00:28:04)

Also seid alle mal bauchgebinselt, dass ihr andis Code überhaupt verwenden dürft.

Andy Grunwald (00:28:04 - 00:29:08)

Ich zwinge ja keinen. Ich war erwarte ja auch nicht, dass jemand den Code nutzt. Also von daher, wenn jemand wissen möchte, was ich so verbreche, schaut auf mein GitHub. Aber wo es z.B. auch funktioniert hat, wo die Weiterentwicklung stagniert hat und dann ein Fork gemacht wurde es bei dem Projekt Paperless. Wer es nicht kennt, Paperless ist ein Projekt zum Scannen, Indexieren und Archivieren von deinen physikalischen Briefen. Wir wollen ja alle digital werden. Und da gab es mal ein Projekt, das hieß Paperless. Das dort hat die Weiterentwicklung stagniert. Das wurde dann geforgt in Paperless NG. Ich glaube, NG steht für Next Generation. Nach kurzer Zeit ist auch da die Weiterentwicklung stagniert. Und jetzt gibt es ein Projekt Paperless NGX und da zum aktuellen Zeitpunkt im Jahre 2024 stagniert die Weiterentwicklung noch nicht. Es lebt eigentlich und kriegt auch regelmäßig Upgrades. Also ebenfalls wie Star Office, OpenOffice, LibreOffice gab es hier paperless, paperless NG, paperless NGX. Da finde ich natürlich schön, dass die Community das dann aufnimmt und weiterhin.

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

Jetzt ist es da natürlich bei diesen Projekten eigentlich relativ easy, wenn das alte Projekt schon fast tot ist oder kurz davor zumindest, dass du erfolgreich bist mit dem Fork. Aber das ist natürlich nicht immer so. Also Forks sind nicht automatisch erfolgreich, nur weil du was weg forkst. Das ist ja auch gar nicht so einfach. Hast du irgendwelche Beispiele, wo es nicht funktioniert, die bekannt sind? Oder vielleicht sind sie eben nicht bekannt, weil es eben gar nicht funktioniert hat?

Andy Grunwald (00:29:32 - 00:29:57)

Bei der Recherche zu dieser Episode habe ich wirklich nach Projekten gesucht, die zweitausendein es nicht geschafft haben, beziehungsweise nicht an Popularität geschafft haben. Aber ja, sie sind nicht bekannt, weil sie es nicht geschafft haben. In der Tat. Ich habe nicht ganz so viel gefunden. Was ich aber gefunden habe, ist ein interessanter Fall. Das ist jetzt so eine Perspektivgeschichte, ob der Fork erfolgreich war oder nicht. Also je nachdem, warum man forgen sollte. Und zwar geht es um Node JS und damals auch um sogenannt IOJS.

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

Also IOJS ist das Projekt, das gefolgte Node JS.

Andy Grunwald (00:30:01 - 00:31:34)

Ganz genau. Und 2014 haben Leute NOJS geforgt und haben das umbenannt in IOJS und wollten das weiterentwickeln. Und das hat auch sehr viel Bass in der JavaScript Community erzeugt. Die primäre Motivation war eigentlich, dass Node JS eine unglaublich langsame Release Geschwindigkeit hatte und dass damals Node JS primär unter der Kontrolle von Joy End stand. Joy End hieß die Firma. Die ganzen JavaScript Leute wollten Node JS weitertreiben, wollten wirklich hier, ich sag mal, den Fuß auf Gaspedal drücken, ein paar mehr Features reinknallen, haben die gesagt, Jungs, wisst ihr was? Joy End, ihr seid mir ein bisschen zu langsam, wir machen OGs Fork. Und das hat anscheinend so viel Druck erzeugt bei Joy End, dass knapp ein Jahr später, 2015, die sich mal hingesetzt haben, mal gequatscht haben und dann später die Changes von IOJS wieder zurück in Node JS gemerged wurden. Und seitdem, muss man ja auch sagen, hat sich die Entwicklung von Node JSausend ja deutlich verändert. Sie ist inzwischen unter einem Open Governance Model. Die Release Geschwindigkeit ist mir zumindestens vielleicht ein bisschen zu schnell, aber ich bin auch kein JavaScript Entwickler. Aber das hat natürlich jetzt einen positiven Outcome eigentlich erzeugt, weil das hat no Js, ich sag mal, ein bisschen Feuer unterm Hintern gemacht. Und jetzt kann man sich die Frage stellen, war der Fork eigentlich erfolgreich? Also der Fork wurde als Motivation genutzt, um Druck aufzubauen, aber in der ursprünglichen Definition von ich erstelle ein Fork und entwickel das ÿousand neue Projekt unabhängig vom Mutterprojekt weiter, kann man schon fast sagen, der Fork hat es nicht geschafft. Aber mit einem Happy End, wie man in einem Disney Film, glaube ich, sagen will.

Wolfi Gassler (00:31:34 - 00:32:16)

Also Wettbewerb belebt die Innovationskraft sozusagen, weil die Leute sich dann schon irgendwie gegeneinander übertreffen wollen. Ich würde fast sagen, bei MariaDB und MySQL, also keine Ahnung, ob das der Grund war natürlich, aber ich würde schon sagen, für das gesamte Ecosystem war das schon eigentlich eine starke Weiterentwicklung. Natürlich, Oracle hat auch viel Geld und viele Leute auf das MySQL Projekt gesetzt, aber MariaDB wollte das natürlich auch. Da hat sich ja mittlerweile auch eine größere Firma im Hintergrund gebildet. Ob die jetzt super erfolgreich ist, ist sei noch mal dahingestellt. Aber es ist schon im gesamten MySQL Space wahnsinnig viel weitergegangen. Also da war dann schon super viel Druck drauf. Und für mich als User würde ich mal sagen, ist verdammt viel weitergegangen im Gegensatz zu den Jahren davor.

Andy Grunwald (00:32:16 - 00:32:33)

Da würde ich dir zustimmen. Und jetzt im Falle von Node, JS und IOJS, genauso wie MariaDB und MySQL, würde ich auch wirklich sagen, dass der folgende Spruch auch irgendwie eine gewisse Wahrheit hat. Konkurrenz belebt das Geschäft. Denn MySQL bzw. Oracle muss sich ja auch auf die Hinterbeine setzen. Und jetzt mal ein bisschen Gas geben.

Wolfi Gassler (00:32:33 - 00:32:41)

Wo aber die Hinterbeine setzen, ist vor allem schön. Ich dachte, sie müssen sich auf die Hinterbeine stellen, aber bei euch im Pott sitzt man sich wahrscheinlich auf die Hinterbeine.

Andy Grunwald (00:32:41 - 00:32:46)

Ich weiß nicht, ob ich doof bin, aber so kenne ich die Redewendung. Sich auf die Hinterbeine setzen. Google das mal.

Wolfi Gassler (00:32:46 - 00:32:50)

Bei uns heißt es stellen, aber vielleicht ist es Österreich und Deutschland.

Andy Grunwald (00:32:50 - 00:34:40)

Ich habe gerade mal gegoogelt. Redensarten Setz dich auf deine Hinterbeine und such dir einen Nebenjob. Ja, ich sag ja, aber einen Fork machen, um Druck aufzubauen. IoJS war jetzt nicht das einzige Beispiel. Und zwar hat Debian mal Mozilla Firefox geforkt. Wusstest du das? Nope. Und zwar gab es von 2006 bis 2016 einen kleinen Disput zwischen Mozilla und Debian. Damals gab es natürlich schon Mozilla firefox, Mozilla Thunderbird und so weiter und so fort. Und Debian hatte diese Projekte auch im Projekttree. Konntest du dir installieren, alles gut. Irgendwann kam die Mozilla Corporation. Und die Mozilla Corporation, wie es eine Corporation macht, hat sich natürlich dann auch die Rechte an der Marke Firefox und Thunderbird und so weiter gesichert. Und die hatten dann auch sogenannte Trademark Policies. Und Trademark Policies sind eigentlich Anweisungen, wie du ein Logo und einen Name zu verwenden hast. Die Trademark Policy hat unter anderem gesagt, Ÿousand, du darfst das Firefox Logo nur in Verbindung mit dem Namen Mozilla benutzen. Das bedeutet, überall wo du Firefox hinschreiben musst, musst du auch irgendwie Mozilla hinschreiben. Und das galt natürlich auch für das Logo. Das Problem war jetzt an dieser Trademark policy, Debian hat das so nicht gemacht, da dieser Zusatz mit Mozilla proprietär war. Also es war keine offene Grafik oder es gehörte nicht, es stand nicht unter Open Source und die Mozilla Corporation hat davon mit, hat davon Wind bekommen, hat gesagt uh, Dieben, wir beide müssen mal reden. Und dann hatten die unterschiedliche Ansichten, wie man das zu lösen hat. Und dann hat die Bienen gesagt auch wisst ihr was, Firefox und Thunderbird ist eigentlich, ist eigentlich open source. Also warum forken wir die nicht? Was sie gemacht haben, ist eigentlich, die haben das komplette Projekt gefolgt, haben bei Firefox ja weiterhin Open Source war die Source Codes immer gemerged und hat das Projekt einfach in Ice Weasel umbenannt und Thunderbird in Ice dove.

Wolfi Gassler (00:34:40 - 00:34:46)

Das heißt, die haben aber nichts weiterentwickelt, die haben wirklich nur ja eine Kopie gemacht und das auch weitergezogen.

Andy Grunwald (00:34:47 - 00:35:23)

Genau. Also eigentlich nur um diesen, um dieser Trademark Policy Guideline zu umgehen. Denn du musst auch wissen, Debian selbst hat sich ein eigenes Regelset gesetzt, dass Debian selbst keine proprietären Sachen mitschippt, dass alles, was in die werden mitgeschickt wird, wirklich 100 % open source. Deswegen hat z.B. die BIEN auch ein Problem mit MySQL, weil MySQL hat proprietäre Teile drin, die nicht unter hundertprozentiger Open Source Lizenz stehen. Deswegen ist glaube ich bei Debian MariaDB der Standard als MySQL Server. Inzwischen, wenn du up get mysql server eingibst im Standard Debian Repository, kriegst du mariadb.

Wolfi Gassler (00:35:23 - 00:35:32)

Ich glaube jetzt endlich, das ist erst kürzlich jetzt entschieden worden als eine der letzten Distributionen, weil ich glaube, alle anderen Linux Distributionen haben das schon ziemlich lang, dass MariaDB der Standard ist.

Andy Grunwald (00:35:32 - 00:35:34)

Ne, ich glaube, das war Ubuntu, von dem du gerade redest.

Wolfi Gassler (00:35:34 - 00:35:36)

Okay, ja, ist ja fast Debian.

Andy Grunwald (00:35:36 - 00:35:53)

Und zwar sind das die sogenannten Debian Free Software Guidelines. Zweitausendein. Dieser ganze Disput wurde erst 2016, also vor gar nicht allzu langer Zeit beigelegt. Und jetzt kommt's, weil Deviant halt sich sehr um Backwards compatibility kümmert, kann man Ice Weasel immer noch installieren.

Wolfi Gassler (00:35:53 - 00:35:53)

Spannend.

Andy Grunwald (00:35:54 - 00:36:03)

Also da sieht man halt ebenfalls, dass Druck aufbauen ebenfalls eine Motivation sein kann, um zu forken. Wer da ein bisschen mehr mit einsteigen möchte, verlinkt natürlich auch.

Wolfi Gassler (00:36:03 - 00:36:54)

Wobei dieses dumme Forken würde ich es mal nennen, also gar nicht mit dem Ziel, irgendwas zu ändern oder was weiterzuentwickeln. Das kann ja auch ganz andere Gründe haben. Ich kann mich erinnern, ich habe ein Projekt, das läuft glaube ich immer noch auf einer sehr alten Cooksto Variante, keine Ahnung, ob du es kennst, guckst du, ist das UI JavaScript Framework von Gmx und die haben da eigentlich was sehr cooles gebaut, ist ein sehr altes Projekt und irgendwann hatte ich mal dieses Problem, dass mein Bild nicht mehr durchgelaufen ist. Jetzt werden alle sagen, bei JavaScript ist das ganz normal, aber in dem Fall hat ein Plugin gefehlt, das aber sehr wichtig für mich war und es hat mir echt viel Zeit gekostet, bis ich dieses dumme Plugin wiedergefunden habe. Und seitdem gibt es einen Fork von diesem Plugin, der mir gehört, weil das ist irgendwann gestorben, dieses Plugin, aber für mein Bild natürlich extrem wichtig. Und das ist einfach, um mich abzusichern, dass mein Bild weiterhin funktioniert.

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

Noch.

Wolfi Gassler (00:36:55 - 00:36:59)

Avi war da mal kurz nervös wirklich, weil ich hatte das echt eine Zeit lang nicht mehr gefunden.

Andy Grunwald (00:36:59 - 00:37:17)

Jetzt bin ich mir nicht ganz sicher, hast du jetzt den Fork aus der Motivation herausgemacht, damit du dein Business weitermachen kannst, so ähnlich wie Redis Elasticsearch oder auch Terraform Open Tofu und so weiter, oder hast du eine Sicherungskopie des Source Codes durchgeführt und hast deswegen die ganze Sache geforgt?

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

Das war eine Sicherheitskopie eigentlich, ja. Also es war im Nachhinein, das originale Repo war plötzlich weg und ich habe dann noch irgendwo eine Kopie gefunden im Internet und seitdem wird die verwendet.

Andy Grunwald (00:37:29 - 00:37:54)

Das ist nämlich auch eine Motivation fürs Forken. Wenn du mal auf GitHub gehst, ÿ, dann wirst du ganz überrascht feststellen, dass diverse Projekte einfach 1000 Forks haben. Die Leute haben sich dann entweder im Button verklickt und wollten das Projekt daran, haben es aber geforgt, oder sie wollten explizit eine sogenannte Sicherungskopie anlegen in ihrem Account, um, weiß ich nicht, möglichem Schaden, möglicher Entfernung oder so weiter vorzubeugen.

Wolfi Gassler (00:37:54 - 00:37:57)

Oder Contributen, da musst du ja normalerweise auch ein Fork machen.

Andy Grunwald (00:37:57 - 00:39:23)

Contributen auch, ist richtig, ja. Mit der Sicherungskopie ist auch immer so eine Sache, weil ich meine, du weißt ja, was einmal im Internet war, geht da leider nie wieder raus. Und das ist nämlich ab und zu mal der Fall. Und zwar gibt es bei GitHub oder gibt es eigentlich bei jeder Plattform, die unter anderem in Amerika zur Verfügung steht, den sogenannten Digital Millennial Copyright Act. Und zwar geht es natürlich auch bei Software, auch bei Open Source Software und so weiter, bzw. Auch auf Software, die auf GitHub gehostet ist, ab und zu mal um Urheberrechte. Und zwar gibt es den sogenannten DMCA Takedown. Der DMCA take Down ist ein rechtliches Verfahren, wo man sagen kann, hey, da ist irgendwer, der hat meinen proprietären Source Code, auf dem ich die Urheberrechte habe, auf GitHub veröffentlicht, bitte entferne diesen und alle Forks. GitHub maintained ein öffentliches Repository, wo du alle DMCA Takedowns nachlesen kannst. Das Problem dabei ist, git ist halt git und git ist distributed. Deswegen findet man ziemlich viele Source Codes, die einmal auf GitHub veröffentlicht wurden, später als DMCA Takedown offline genommen wurden, dann auf BitBucket oder auf GitLab wieder. Denn einfach mal einen neuen Server hinzuzufügen, ist halt bei Git relativ einfach. Deswegen wird Forking auch ab und zu mal genommen, um sich eine in anführungszeichen Sicherungskopie zuzulegen, auch wenn dies vielleicht nicht ganz legal ist. Also das hier ist keine Anstiftung zur Straftat.

Wolfi Gassler (00:39:24 - 00:39:27)

Aber wann darf man jetzt eigentlich wirklich eine Kopie anvertingen und wann nicht?

Andy Grunwald (00:39:27 - 00:39:55)

Ja, das ist eine sehr gute Frage. Darf man überhaupt forken? Denn Urheberrecht, besonders internationales Urheberrecht, ist unglaublich schwierig. Generell kann man sagen, solange die Softwarelizenz einer Software nicht explizit erlaubt, dass Derivate erzeugt bzw. Verbreitet werden dürfen und ein Vorkommen ist automatisch ein Derivat, ist dies eigentlich verboten. Also forken ist standardmäßig mal verboten. Jetzt kommt aber Gitter um die Ecke und jetzt schaut man einmal mal in die GitHub Terms of Service und da.

Wolfi Gassler (00:39:56 - 00:39:58)

Steht, was ja jeder ständig macht, natürlich.

Andy Grunwald (00:39:58 - 00:40:01)

Ja logisch, liest du die AGBs nicht, bevor du dich registrierst?

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

Natürlich. Drum weiß ich ja auch, was du jetzt bringst. Ganz klar. Du redest über Paragraphen fünf, oder? Kann ich mich noch erinnern?

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

Ganz genau gemacht habe. Im Paragraph fünf Lizenzgewährung an andere Benutzer steht nämlich drin, ich indem sie festlegen, dass ihre Repositories öffentlich einsehbar sind, aka schalte dein Repo auf public, erklären sie sich damit einverstanden, dass andere ihre Repositories anzeigen und forken dürfen. Das bedeutet, jedes public repository auf GitHub darf laut den AGBs von GitHub geforkt werden. Aber was ist denn jetzt, wenn ich auf GitLab bin? Wenn ein Projekt eine Osi Approved Lizenz hat, das bedeutet eine Open Source Approved Lizenz, also eine richtige Open Source Lizenz zweitausendein, dann beinhaltet diese Lizenz ebenfalls das Recht zur Nutzung, Modifikation und oder das Teilen dieser Software unter den definierten Terms and Conditions. Und Terms of conditions bedeutet in diesem Fall sowas wie die GPL Software z.B. immer wenn du GPL Software forkst und modifizierst, muss diese Software ebenfalls unter GPL lizenziert werden. Das sind z.B. sogenannte definierte Terms und Condition. Aber jede Approved Open Source Lizenz beinhaltet die Erlaubnis zum Walking. Und wer hat es nicht verstanden? Die aktuellen Copyright Owner meines Lieblingsmusikplayers.

Wolfi Gassler (00:41:24 - 00:41:27)

Was ist dein Lieblingsmusikplayer? Spotify.

Andy Grunwald (00:41:27 - 00:41:33)

Ja, bevor es Spotify gab, gab es Vinamp. Die Frage ist eigentlich nur, welches Vinamp Theme hattest du? Welchen Skin?

Wolfi Gassler (00:41:33 - 00:41:44)

Ich glaube, meiner war so halb transparent blau, wenn ich das richtig im Kopf habe. Aber was für ein Name das war oder so, keine Ahnung mehr. Aber klär mal alle auf die, die nicht aus dieser Steinzeit kommen.

Andy Grunwald (00:41:44 - 00:42:03)

Für die jüngeren Zuhörerinnen und Zuhörer unter uns, Winamp war nicht irgendein Musikplayer auf dem Computer, es war der Musikplayer auf dem Computer. Ich glaube, jeder, der zwischen 1997 und 2013 irgendwas am Computer gemacht hat, der hatte mindestens einmal Winap installiert.

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

Moment, winapp gibt es erst seit 2007?

Andy Grunwald (00:42:05 - 00:42:07)

1907 und neunzigste.

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

Ah, okay.

Andy Grunwald (00:42:08 - 00:43:24)

Und Winamp hat Kultstatus. Wie beweise ich diese Aussage? Googelt einfach mal Winamp bei GitHub und ihr findet das als Beispielprojekte, wie wenn du ein neues JavaScript Framework baust. Und was baust du dann? In der Regel eine to do List. Bauen Leute auch Winam nach. Wie dem auch sei, der aktuelle Copyright Holder von der Winamp Software hat sich gedacht, wisst ihr was so populär wir veröffentlicht das mal auf GitHub. Auf GitHub hat wurde dann der Source Code auch veröffentlicht mit der Winamp Collaborative License in Version eins. Und die Winamp Collaborative License besagte no forking, you may not crate, maintain or Distribute a fork version of this software. Findige GitHub User sind natürlich ins Repository gesprungen, haben es natürlich erstmal gefolgt zur Sicherungskopie, ganz klar. Haben dann aber auch ein Issue aufgemacht. Jungs und Mädels, ihr veröffentlicht das auf GitHub, schreibt in der Lizenz, da darf nicht geforgt werden. In den GitHub AGB steht aber drin, alles was auf GitHub ist, darf geforkt werden. Was machen wir denn nun? So wurde dann rumdiskutiert. Ende vom Lied ist, der Copyright Owner von Vinap hat das Repository wieder runtergenommen, gelöscht. Schade, die Welt hätte so schön sein können und Weihnachten hätte früher da sein können, weil ich bin mir 100 % sicher, irgendwelche Entwickler hätten das ähnlich wie Doom auf alle der auf alle Devices geportet.

Wolfi Gassler (00:43:25 - 00:43:29)

Aber mit einem Takedown bekommt man dann ja die ganzen Kopien auch wieder runter, oder? Das ist ja kein Problem.

Andy Grunwald (00:43:29 - 00:43:40)

Zweitausendein, ja, die referenzierten Forks auf GitHub, klar, aber nicht auf GitLab. Also ein Fork ist ja nicht nur ein Fork, wenn du auf den Button bei GitHub drückst. Ich kann es ja auch runterladen und bei GitLab hochpushen, dann ist es ja auch ein Fork.

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

Kann ich eigentlich ein Repository dann private nehmen, nachdem ich es gefolgt habe, wenn es public war? Müsste funktionieren, oder?

Andy Grunwald (00:43:46 - 00:44:15)

Ja klar. Es sei denn, es ist dann GPL Software. Also diese Forks, das ist ja diese Terms and Condition, die ich es gerade gesagt habe. Also die Lizenz sagt ja, was du mit dem Fork machen musst. Und wenn es dann GPL Software ist, dann musst du es wieder unter GPL veröffentlichen. Also ich glaube auch ziemlich viele Firmen in der Industrie machen da nicht legale Sachen, weil sie einfach diese Art, weil sie diese Details von diesen Open Source Lizenzen nicht verstehen bzw. Nie gelesen haben bzw. Ihnen das nie so wichtig war oder es hat noch nie niemand geklagt.

Wolfi Gassler (00:44:15 - 00:44:29)

Also ihr habt jetzt mal schnell gegoogelt. So wie es aussieht, ist es gar nicht so einfach, ein Public Repo, das gefolgt ist, private zu setzen. Wird scheinbar nicht erlaubt, wenn ich das richtig rausgefunden habe. Aber kommt gerne vorbei in unsere Discord Community und belehrt uns anders, besser.

Andy Grunwald (00:44:29 - 00:44:38)

Naja, Wolfgang, du begrenzt dich aber auch gerade selbst, oder? Ich meine, wovon du redest, ist ein referenzierter Fork, das in der GitHub UI dann auch angezeigt wird.

Wolfi Gassler (00:44:38 - 00:44:40)

Kopieren kannst du natürlich alles, das ist ja klar.

Andy Grunwald (00:44:41 - 00:44:46)

Ja, aber auch das ist ein Fork, wenn ich es runterlade und erneut hochlade, ist ja auch ein Fork. Es ist nur kein referenzierter Fork.

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

Natürlich, natürlich. Wenn du so smart bist, dann geht es natürlich.

Andy Grunwald (00:44:50 - 00:45:31)

Jetzt reden wir aber die ganze Zeit von Forking und Forking und Forking, als wäre das was ganz normales, wie auf Toilette zu gehen. Auf Toilette gehen ist einfacher, zumindest für viele Leute. Aber forken selbst ist wirklich gar nicht so einfach, denn auf den Button zu drücken oder das runterzuladen, ja, das ist das. Das ist das eigentliche Forking, das stimmt schon. Aber damit ist es ja nicht getan. Denn nehmen wir mal an, das Projekt ist richtig groß, was du da forken möchtest, wie z.B. kubernetes. Du möchtest jetzt Wolfgang Netes bauen und da hängt natürlich ein riesen Rattenschwarz dran, Ÿousand, weil du möchtest, dass dein Wolfgang Netes Fork von Kubernetes auch populär wird. Musst du natürlich auch raus in die Welt und den Leuten das mitteilen.

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

Ja, ich wüsste da ein Podcast, der sehr gut das machen könnte.

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

Würdest du dann hier Werbung buchen?

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

Natürlich.

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

Verstehe.

Wolfi Gassler (00:45:38 - 00:45:40)

Ich bekomme ja vielleicht internen Rabatt.

Andy Grunwald (00:45:40 - 00:46:27)

Je nach Größe des Projektes muss man natürlich auch eine ganze Menge Marketing machen, teilweise Open Governance Strukturen aufbauen, siehe Open Search z.B. oder Valkyrie Fork von Redis, was jetzt Teil der Linux Foundation ist. Also da steckt natürlich dann schon noch eine ganze Menge dahinter. Gegebenenfalls gibt es Firmen, die mit der originalen, mit dem Mutterprojekt irgendwie Geld verdienen, sei es Cloud Hoster, Datenmarkt as a Service Provider oder oder oder vielleicht auf dem originalen Mutterprojekt ihr Business aufgebaut haben. Deswegen ist das vielleicht businesskritisch. Vielleicht tritt man dann mit diesen Firmen mal in Kontakt, warum sie deinen Fork nutzen sollten und nicht mehr das Mutterprojekt und so weiter. Also wenn man wirklich möchte, dass dein Fork bekannt wird, genutzt wird, dann ist die größte Arbeit beim Forken eigentlich nicht die technische, sondern die Marketingarbeit, weil man.

Wolfi Gassler (00:46:27 - 00:47:04)

Forkt ja auch nur den Source Code und nicht die Community. Das Schwierige ist ja dann wirklich der Aufbau einer Community oder vielleicht Leute mitzunehmen von dem alten Projekt. Jetzt bei Oncloud und Nextcloud war das natürlich einfacher, wenn der Hauptentwickler mit seinem gesamten Team wechselt oder ein Großteil von seinem Team. Der hat natürlich einen anderen Hebel. Aber wenn du jetzt einfach irgendwo was forkst, viel Spaß, mal eine Community aufzubauen, vor allem, wenn das alte Projekt auch beliebt ist. Also da, das ist schon eine riesen Herausforderung. Es geht ja nicht nur darum, dass es jemand verwendet, sondern dass du dann auch richtig open source weiterlebst und deine Community rundherum aufbaust, die dann wieder zurückkontributen und das mit dir weiterentwickeln.

Andy Grunwald (00:47:04 - 00:48:30)

Ja, ich kann mir schon vorstellen, dass das bei den Leuten, die wirklich im Mutterprojekt involviert sind, die alle News lesen, die alle Release folgen und so weiter, da ist das sehr wahrscheinlich recht einfach zu kommunizieren. Aber bei den Endusern, die, wie du auch im Intro sagtest, Software als gratis ansehen und sich nur das fertige Release runterladen, das führt ja zu Verwirrung. Die stellen sich die Frage Hey, warum gibt es Kubernetes? Warum gibt es Wolfgang Netes? Was ist denn jetzt an Wolfgang Netes anders? Welches soll ich denn jetzt nutzen? Und das ist ja nicht nur bei Hobby Benutzern, das ist ja auch bei Firmen wirklich so. Firmen sind ja wirklich verwirrt und haben haben teilweise rechtliche Fragen, Business Fragen. Nehmen wir mal den Fall von Hashicorps Terraform. Terraform hat ebenfalls die Lizenz geändert, dass aus dem, aus denselben Gründen wie Elasticsearch, dass andere Leute, die ein Terraform Derivat oder ihr Business auf Terraform aufgebaut haben und es weiterentwickelt haben, dass die nicht den Market Share von Hashicorp essen. Auf jeden Fall haben die Blogposts gemacht, wie, was bedeutet denn die Lizenzänderung von Terraform denn jetzt für mich als Kunde? Also diese Art von Blogpost gab es auch bei Elasticsearch, diese Blogpost gab es auch bei Redis, weil die ganzen Firmen, die auf Redis aufbauen, die auf Elasticsearch aufbauen, die auf Terraform aufbauen, müssen ihre Kunden beruhigen. Also du mit einem Fork oder mit einem populären Fork stiftest du auch End User Verführung und die muss man erstmal resolven und wir wissen alle, das geht nicht in der Woche.

Wolfi Gassler (00:48:31 - 00:49:24)

Ja, mir geht es ja oft so bei eher kleineren Projekten, wenn man so auf GitHub irgendwas sucht oder so eine JavaScript Clip, dann findet man teilweise irgendwie so fünf Forks, die alle irgendwie behaupten, sie sind jetzt das eigentliche coole Ding, was du verwenden solltest. Und dann ist es wirklich schwierig rauszufinden, wer war denn da überhaupt zuerst. Also klar, du kannst irgendwelche Grafen durchgehen und dir das raussuchen, aber das ist teilweise wirklich schwierig. Ich gehe halt dann gern nach irgendwelchen Stars oder eben Anzahl der Forks, die so ein bisschen mir eine Entscheidungshilfe geben, aber gerade bei so kleinen Projekten ist es halt auch nicht klar sichtbar, wer ist jetzt da der Hauptplayer, wer, wo stecken die wirklich ein dahinter oder was sollst du verwenden oder hat es einen guten Grund, dass die jetzt irgendwie gefolgt sind und ist es wirklich das Bessere? Also es ist super schwer und so im Alltag, wenn man viel mit Libraries arbeitet, die jetzt nicht die großen Heroes sind, dann wird es schon oft schwer.

Andy Grunwald (00:49:24 - 00:49:31)

Vor kurzem wieder hatte ich das Problem, ich wollte eine Office Suite installieren auf einem, auf einem Laptop von einer Bekannten.

Wolfi Gassler (00:49:31 - 00:49:34)

Und Office meist du sowas wie LibreOffice?

Andy Grunwald (00:49:34 - 00:50:09)

Ja, ganz genau. Ich wollte jetzt kein Microsoft Office kaufen, weil die Dame das nicht gebraucht hat hat und dann habe ich mich, weil ich in der Office Szene nicht so drin bin, wusste ich nicht mehr, was ist jetzt das aktuellste, LibreOffice oder OpenOffice? Und das Problem ist, ich hatte ja gesagt, LibreOffice ist ein Fork von OpenOffice, von Star Office, aufgrund der stagnierten Entwicklung von Open Office, aber Open Office wird aktiv weiterentwickelt. Das bedeutet, du hast jetzt beide LibreOffice und Open Office wird weiterentwickelt und ich wusste gerade nicht mehr, ja Moment mal, welcher ist denn Fork von welchem? Und dann musste ich mich auch erstmal wieder mit der kurzen paar Minuten nur, aber ich musste mich damit beschäftigen und das ist ein prädestiniertes Beispiel für End User Verwirrung für mich.

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

Was ist es dann geworden?

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

LibreOffice.

Wolfi Gassler (00:50:11 - 00:50:28)

Okay. Ja, ich bin ja auch nicht mehr informiert. Also im Linux Umfeld ist es ja relativ einfach. Du nimmst, was dir der Paketmanager so vorschlägt und ich hätte gar nicht gewusst, dass OpenOffice noch weiterentwickelt wird oder ich bin mir auch gar nicht sicher, ob man das. Ich glaube in den Linux Paketmanagern ist es auch gar nicht mehr drinnen, würde ich jetzt sagen.

Andy Grunwald (00:50:28 - 00:51:13)

Und die zweite Story mit Forks, mit der End User Verwirrung, die ich vor kurzem hatte. Und zwar habe ich eine Library in einem Goprojekt fürs Structured logging und was ich wollte ist, immer wenn ein Error gelockt wird, dann soll dieser Error automatisch nach Sentry gelockt werden. Also habe ich mir gedacht, cool, es gibt doch bestimmt in diese Library irgendeine Möglichkeit, mich als Middleware einzuklinken, dass wenn ein Error gelockt wird, wird er nach Sentry geschickt. Kurz cool, es gibt eine Repository, die machen genau das für die Library, die ich nutze. Seit sechs Monaten kein Commit mehr. Ich denke so, das ist schade. Funktioniert die denn? Weiß ich noch nicht. Habe ich mir die API kurz angeschaut. API auch nicht ganz so schön. Kurz weiter gegoogelt. Oh, drei Forks, drei Forks wurden da gemacht, haben verschiedene Features hinzugefügt.

Wolfi Gassler (00:51:13 - 00:51:18)

Ende vom Lied ist, du hast einen vierten Fork gemacht, wo du alle Features zusammenfasst.

Andy Grunwald (00:51:18 - 00:51:44)

Das ist aktuell mein Plan. Ich habe die Library immer noch nicht eingebunden, weil ich gerade die Forks evaluieren zweitausendein, weil so nach dem Motto, man will ja nicht auf den nächsten stagnierten Entwicklungszweig aufspringen, sondern man will schon angucken, was habt ihr da gemacht? Hat er da irgendwie seine persönlichen Sachen hartgecodet oder ist das wirklich eine Weiterentwicklung oder hat der auch was zurückgespielt und so weiter. Klassische End User Verwirrung und das kostet mich jetzt richtig Zeit. Es ist nur ein Hobbyprojekt, aber es kostet mich trotzdem richtig Zeit und ich muss mich da rauswühlen.

Wolfi Gassler (00:51:44 - 00:52:23)

Ja, da stellt sich ja mir auch oft die Frage, hat es da einfach keine Kommunikation gegeben? War da wirklich jemand stur oder gibt es den Original Entwickler Entwicklerin vielleicht nicht mehr? Oder was halt einfach so, ich brauch was fork und ich mache mein eigenes Zeug. Weil oft kommt mir das schon so vor, man hat sich gar nicht bemüht. Ich weiß, es ist oft schwierig. Andi hat da ja auch seine seine Geschichten mit der Home Assistant Contribution. Die ihm um die Ohren geflogen ist. Also es passiert ja immer wieder, muss man ja, passiert den besten. Wollte natürlich sagen, aber man kann es ja trotzdem mal probieren. Also ich finde schon, man sollte den ersten Schritt schon mal probieren. Kann man upstream irgendwas zurückgeben, anstatt immer sofort einen Fork zu machen und sein eigenes Zeug weiterzumachen?

Andy Grunwald (00:52:23 - 00:52:32)

Ja, also ich meine, in open Source geht es ja primär um Menschen und wo Menschen am Werk sind, gibt es auch Knatsch und ich bin auch nicht perfekt. Vielleicht habe ich auch einfach Fehler gemacht. Keine Ahnung. Ist aber auch egal.

Wolfi Gassler (00:52:32 - 00:52:35)

Aber du hast es probiert. Darum geht es ja natürlich.

Andy Grunwald (00:52:35 - 00:53:46)

Kommunikation ist immer immer der der Kern der ganzen Thematik. Aber worauf ich hinaus möchte, jetzt stell dir mal vor, die Library, von der ich gerade erzählt habe, die seit sechs Monaten keine Contributions mehr gekriegt hat oder kein Merch, sagen wir mal so. Der Maintainment hat halt keine Zeit für ihn. Aus Upstream Perspektive ist es auch eine wahre Herausforderung, sich einen Überblick über die Forks seiner Library zu erschaffen und dann zu sagen hey, dieser Fork hat aber ein cooles Feature rangeholt, das merge ich wieder upstream, weil auf GitHub hat man zwar einen Netzwerkgrafen, da sieht man, wann das geforgt wurde, wie viel Commit seitdem zweitausendein dazugekommen sind und so weiter. Dennoch ist das super viel Arbeit, die Übersicht zu behalten, weil du ja eigentlich, wenn du es sehr, sehr sauber machen möchtest, in jeden Fork runtergehen müsstest, dir die Changes im Detail ansehen müsstest und dann evaluieren müssen. Kann ich denn so mergen? Möchte ich den so mergen und so weiter, um das Mutterprojekt und das Upstream Projekt eigentlich ja wirklich mal schön weiterzutreiben. Weil es kann ja auch einfach sein, dass der Maintainer oder die Maintainerin gerade Mutter oder Vater geworden ist und dann steht halt der Nachwuchs im Vordergrund und nicht mehr irgendeine Library für ein structured logging Projekt, die mit Sentry kommunizieren, weil.

Wolfi Gassler (00:53:46 - 00:53:58)

Wir jetzt gerade gesprochen haben. Man muss halt checken, was jetzt wirklich die sinnvolle Lieb ist oder der beste Fog. Und eben auch erwähnt, ich schaue auf Stars und Forks. Findest du, dass viele Forks ein gutes Zeichen sind oder ein schlechtes Zeichen?

Andy Grunwald (00:53:58 - 00:54:42)

Ich denke, da gibt es keine pauschale Aussage, denn ob ein Projekt geforkt wird, liegt 100 % außerhalb der Kontrolle des Maintainers. Hätte der Maintainer in irgendeiner Art und Weise eine Kontrolle bzw. Einen Einfluss darauf, weniger Forks zu haben, dann könnte man sagen, viele Forks sind schlecht. Aber da er oder sie wirklich gar keinen Einfluss auf die Anzahl der Forks hat, weil es Open Source ist und das ist ja das Schöne an der ganzen Thematik, muss man ja auch sagen, ist das eine neutrale Geschichte. Was aber ein Indikator von hohen Forks ist, ist eine geringe Tendenz, Contributions zu merchen. Also wenn das Projekt tot ist, dann steigt die Anzahl der Forks, weil dann mehr und mehr Leute denken, ach ja komm, dann merge ich eben mein Kram rein, dann kann ich wenigstens hier weiterbauen.

Wolfi Gassler (00:54:42 - 00:55:08)

Ja, ich glaube, was man natürlich schon machen kann, man kann checken, haben die Forks wieder neue Commits drauf und sehen im Originalprojekt keine Merges drin, dann ist es ein Zeichen, dass dieses Repository keine Merge Requests mehr aufnimmt. Das ist natürlich ein klassisches Zeichen, aber wenn da natürlich Bewegung drauf ist, dann sind die Forks natürlich wahrscheinlich ein Großteil auch davon darauf zurückzuführen, dass da natürlich auch Pull Requests passieren.

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

Ja, du nimmst ja an, dass die Forks auch wirklich den Pull Request zurückspielen.

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

Genau, aber das kann man herausfinden. Also primär geht es meiner Meinung nach auch darum, werden noch Pull Requests angenommen? Also und wenn dann natürlich noch eine große Vorrate oder eine hohe Zahl dort steht, dann finde ich das schon eher ein positives Zeichen.

Andy Grunwald (00:55:25 - 00:55:33)

Es gibt aber auch Projekte, die sagen ganz explizit Hey, dieses Projekt ist Feature complete, es werden keine Pull Requests angenommen, bitte folgt es.

Wolfi Gassler (00:55:33 - 00:55:39)

Das sind mir eigentlich die liebsten Projekte, die irgendwie dastehen haben. Wir entwickeln das nicht mehr weiter. Großes Rufezeichen, weil da weiß man wenig.

Andy Grunwald (00:55:39 - 00:55:40)

Wo man dran ist.

Wolfi Gassler (00:55:40 - 00:56:32)

Genau, es gibt paar andere for schaut dort nach oder so. Aber wenn man immer durchkriegt und alle schauen irgendwie so halb aktiv aus oder halt irgendwie aber alle nicht super neu, das ist immer das schwierigste meiner Meinung nach. Also ich glaube, da kann man schon auch viel mithelfen und einen harten Schlussstrich ziehen. Das hilft glaube ich schon auch als Maintainer, wenn man, wenn man sowas macht und ich glaube, man kann doch gute Kommunikation und vielleicht auch durch gutes Design durchaus solche Forks verhindern. Also einerseits, damit die Leute einfach nicht grantig sind und dann ihren Fork machen, aber man kann natürlich auch eine schönere Architektur machen, dass z.B. das Contributen einfacher wird oder vielleicht überhaupt ein Plugin System bauen, dass die Leute selber mit Plugins die Erweiterung machen können. Dann bist du weniger angreifbar, weil du sagst okay, dieses Feature ist vielleicht nicht willkommen im Hauptbranche, im Hauptprojekt, aber du kannst ja dein Plugin zweitausendein, also darüber kannst du vielleicht dann auch steuern.

Andy Grunwald (00:56:32 - 00:57:01)

Ist eine geniale Idee. Da holst du natürlich eine andere Komplexität rein. Auf der einen Seite möchtest du natürlich die Marketingkomplexität haben und eine Liste von allen guten Plugins führen, damit Leute auch wissen, welche Plugins gibt. Dann möchtest du vielleicht diese Plugins in irgendeiner Art und Weise klassifizieren, zertifizieren. Und wie z.b. das Projekt Home Assistant sagt, die haben so Qualitätslevel pro Plugin, weil wenn sehr viele Leute sehr viele Plugins entwickeln, haben die halt eine unterschiedliche Qualität. Und ja, wobei du sprichst da jetzt.

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

Schon von den Riesenprojekten. Also gerade Home Assistant ist, glaube ich, eines der größten Open Source Projekte. WordPress hat auch wahrscheinlich, keine Ahnung, Millionen von Plugins und da gibt es eigene Listen von Listen wahrscheinlich. Also klar, wenn du auf so einem Scale bist, kannst du da natürlich noch mehr investieren, aber es reicht ja schon, dass du frühzeitig vielleicht überlegst, okay, könnt ihr ein Plugin System überhaupt mal zur Verfügung stellen? Und eine Liste ist jetzt auch schnell gemacht. Also das wächst ja dann mit der Zeit. Ist ja nicht von heute auf morgen, dass die Komplexität zweitausendein ums tausendfache steigt. Aber ist vielleicht dann gut, mit der Community so umzugehen, dass man denen eben trotzdem was in die Hand gibt. Du kannst deinen Willen durchsetzen, muss das Ganze aber nicht extra forken dafür.

Andy Grunwald (00:57:39 - 00:58:25)

Klar, und die erhöhte Komplexität der externen zur Verfügung gestellten API mit Releases, Breaking Changes und so weiter. Aber wir haben jetzt ziemlich viel aus der Maintainer, aus der Upstream Sicht gesprochen, welche Herausforderung es gibt. Auch die andere Seite. Stell dir vor, du forkst ein Projekt, weil die Entwicklung des Mutterprojekts geht dir nicht schnell genug oder die Hürden zum Mutterprojekt zu Contributen sind sehr hoch und die möchtest du einfach nicht eingehen. Du möchtest dich einfach schnell weiterentwickeln. Und genau das hat Google gemacht. Google hatte nämlich für eine ganz lange Zeit den Linux Kernel gefolgt. Und da Google ja in manchen Bereichen, speziell auch in der container Technologie, Isolation und so weiter, in den frühen Zeiten des Web und der Cloud ja doch schon eine gewisse Pioniersarbeit geleistet hat, muss man ja leider sagen.

Wolfi Gassler (00:58:25 - 00:58:26)

Warum leider?

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

Ja, das habe ich mich gerade auch gefragt. Warum? Warum habe ich leider gesagt? Die haben Pioniersarbeit geleistet und haben natürlich dann ziemlich viele a Bugs im Kernel gefunden, aber natürlich auch Bugs gefixt und auch neue Features entwickelt. Und Google hat eine ganze Zeit lang ihren eigenen Fork von Linux maintained. Was haben die dann gemacht? Die haben sich die Changes upstream angeschaut, haben die runter in den Fork gemerged, mussten ihre Patches erneut drauf spielen und du kannst dir vorstellen, dass das ziemlich zeitaufwendig.

Wolfi Gassler (00:58:55 - 00:58:56)

Aber war das public dann?

Andy Grunwald (00:58:56 - 00:59:52)

Meines Wissens nach war das nicht public. Es war google intern. Ich habe die Story auch nur gelesen. Was ich aber jetzt dann gelesen habe, weil dieses, weil die Maintenance Arbeit des Linux Kernel Forks innerhalb von Google so viel Zeit aufgenommen hat, hat Google irgendwann gesagt also wir müssen jetzt wirklich mal anfangen, unsere Patches upstream zu spielen. Das haben die aber nicht initial gemacht, weil auf die Mailing Liste posten, dann Diskussionen und so weiter, bis sie dann im Kernel sind und bis das Release dann draußen ist. Das dauert halt ewig. Deswegen, die wollten sich einfach schnell bewegen. Irgendwann hatten die aber so viele Patches, dass dieses drauf patchen und zurück merchen einfach so viel Arbeit gefressen hat, dass sie gesagt haben wisst ihr was? Wir gehen jetzt die schmerzhafte Route, beißen uns da jetzt ein Jahr, anderthalb Jahre durch abstreamen unsere Patches in den Linux Kernel, damit wir den Mainstream Kernel nutzen können bzw. Nur noch wenige Patches zu maintainen haben und dann diesen Fork Maintenance Aufwand nicht mehr haben.

Wolfi Gassler (00:59:52 - 01:00:23)

Ich habe erst kürzlich gelernt, dass das mit GPL überhaupt möglich ist bzw. Dass es die AGPL Lizenz gibt, die genau dieses Problem verhindert, dass wenn du etwas änderst an GPL Code, das aber nur intern verwendest, aber z.B. als Hoster dann bereitstellst in irgendeiner Form als Service oder im Hintergrund irgendwie läuft, dann musst du das auch wieder upstream veröffentlichen oder? Also veröffentlichen, nicht upstream, aber grundsätzlich veröffentlicht. Und bei der GPL brauchst du das hier nur, wenn du zweitausendein das auch distributest, was ja bei Web Software oft gar nicht der Fall ist. Du lässt es halt einfach auf deinen Servern rennen.

Andy Grunwald (01:00:23 - 01:00:27)

Ja, Lizenzrecht ist eine Welt für sich. Also wenn, wenn du wünschst dir ja.

Wolfi Gassler (01:00:27 - 01:00:38)

Immer noch eine Episode, wo wir nur über Lizenzen reden oder mit einem Spezialisten, der sich wirklich auskennt bei Lizenzrechten. Falls sie so jemanden kennt oder eine Spezialistin, bitte uns gerne mitteilen.

Andy Grunwald (01:00:38 - 01:01:11)

Sehr gerne eine deutschsprachige Juristin oder Juristen, spezialisiert auf Lizenzrecht, Open Source Lizenzrecht, proprietär Lizenzrecht, aber speziell für Software. Bitte. Also wir haben jetzt ein paar Herausforderungen beim Forken, auch genannt den Rattenschwanz, der bei großen Projekten mitkommt, die enduser Verwirrung, wie man die Changes von Upstream in den Fork Merch, aber auch andersrum, wie man als Maintainer damit umgeht. Wenn seine Software geforkt wird. Und du hattest ja auch schon das Plugin System als technische Lösung oder als technische Alternative zum Forken vorgestellt.

Wolfi Gassler (01:01:11 - 01:01:16)

Also vielleicht nicht als Lösung, sondern als vorbeugenden Schutz vor einem Volk.

Andy Grunwald (01:01:16 - 01:01:58)

Meine Königslösung ist leider auch die, die am schwierigsten ist, muss ich zugeben, und zwar mit dem Hauptmanntainer oder der Hauptmanntainerin einfach mal in Kontakt zu treten. Such dir die E Mail Adresse und schreibt diese Person einfach mal eine E Mail und einfach nur so Hey, ich benutze dein Projekt, ich habe hier ein Fork mit 15 Patches, bist du noch an dem Projekt dran oder siehst du irgendeine Chance, dass du diese Pull request mal annimmst oder oder hast du Zeit? Hast du überhaupt Interesse daran noch? Und so weiter. Weil wenn man da in aktiver Kommunikation, im aktiven Austausch steht, dann kann man nämlich auch z.B. vorschlagen Hey, was hältst du denn davon, wenn ich das Projekt übernehme? Wenn wenn du mich als Contributor da hinzufügst.

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

Also als Maintainer meinst du?

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

Genau, als als ich maintaine das Projekt mit.

Wolfi Gassler (01:02:02 - 01:02:21)

Ja, das ist schwer, das haben wir eh schon öfters erwähnt, aber zufälligerweise gerade heute hat uns gemeinsamer Freund wieder ein paar Screenshots geschickt, wo seine PRs einfach sofort geschlossen wurden oder so mehr oder weniger einfach i don't like it closed im Proxmox Umfeld. Also es ist teilweise schon schwierig, aber da muss man einfach auch durch dieses.

Andy Grunwald (01:02:21 - 01:02:36)

Oh, mir hat jemand eine E Mail geschrieben und diese Person mache ich jetzt als Maintainer. Hat natürlich auch ein paar negative Seiten. Es kann natürlich auch ein Attack Vector sein, könnte gegebenenfalls. Also ich meine, genau das ist nämlich der Punkt gewesen bei dieser xz Backdoor, die vor kurzem durch die durch die.

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

Medien zweitausendein, wobei man natürlich da auch sagen muss, da musst du schon mal so eine Software haben, die so kritisch ist und so wie XSet überall Anwendung findet. Das ist dann natürlich noch mal eine andere Sache. Aber ehrlich gesagt, wir sprechen ja ganz oft auch über Software, die jetzt vielleicht nicht in jeder Linux Distribution dabei ist.

Andy Grunwald (01:02:55 - 01:02:56)

Naja, wir müssen ja nicht nur von Linux reden.

Wolfi Gassler (01:02:56 - 01:02:58)

Gibt es, Moment, gibt es was anderes?

Andy Grunwald (01:02:59 - 01:03:02)

Ich bringe jetzt nur noch mal das JavaScript Package Left pad in den Raum.

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

Ja, das war ja auch überall verwendet. Also Ÿousand. Klar, wenn du natürlich so große Projekte hast, ist es was anderes, so große.

Andy Grunwald (01:03:08 - 01:03:10)

Projekte in der Verwendung, weil das Leftpad war ja nicht groß.

Wolfi Gassler (01:03:10 - 01:03:13)

Ja, nicht im Sinne von Lines of code.

Andy Grunwald (01:03:13 - 01:03:26)

Ja, da hast du recht, auch in der JavaScript Dependency Hölle. Es tut mir leid, ich lehne mich mal aus dem Fenster. Ich brauche keine 3 Stunden. Dann habe ich auch ein Paket in der Größe von Left Pad, was in React eingebunden ist, irgendwie in der fünften Ebene.

Wolfi Gassler (01:03:26 - 01:03:30)

Ah, das. Da lehnst du dich jetzt weiter aus dem Fenster. Wie viel hast du gesagt? 3 Stunden?

Andy Grunwald (01:03:30 - 01:03:32)

In 3 Stunden finde ich so ein.

Wolfi Gassler (01:03:32 - 01:03:34)

Ah, du findest ein Paket, okay.

Andy Grunwald (01:03:34 - 01:04:02)

Genau, genau. Ich finde ein Paket, was. Oder vielleicht auch zwei, drei, vier, was man in Anführungszeichen attackieren könnte. Aber ich möchte nur darauf zu aufrufen. Nur weil ich euch eine E Mail schreibe, bedeutet das, macht mich bitte nicht zum Maintainer. Unter anderem ist diese Library in eurem GitHub User Namespace. Und dann, offen gesprochen, interessiert es niemanden, ob du der Schuldige bist oder nicht. Es fällt alles auch dich irgendwie ein bisschen zurück. Das ist jetzt ein bisschen Schwarzmalerei, gebe ich auch zu.

Wolfi Gassler (01:04:03 - 01:04:29)

Aber man kann ja auch einfach mit den Leuten mal telefonieren. Das ist ja bei Xet auch nie passiert. Das habe ich z.B. gemacht bei einem netten mit Maintainer von von einer meiner Repositories. Der ist super aktiv, vielen Dank dafür übrigens. Von einem Doku wiki Plugin. Und das erste, was ich mal gemacht habe, eben den Video Call mit dem einfach gemacht und dann lernt man sich mal kennen und dann kann man eh schon sehr viel sagen. Natürlich, böses Blut kann überall sein, aber ja, mit dem muss man dann halt auch leben.

Andy Grunwald (01:04:29 - 01:04:45)

Habe ich auch gemacht. Ein paar Leute haben mir eine E Mail geschrieben. Hey, maintainst du diese Library noch? Habe ich mit den Videocall ausgemacht, ein bisschen über die Strategie, ein bisschen Vision, wohin geht's? Durchgesprochen. Und ja, seitdem mergen die da auch mal ein bisschen was durch. Finde ich ziemlich cool. Was ist das Ende vom Lied? Was ist das Resultat dieser Podcast Episode?

Wolfi Gassler (01:04:45 - 01:04:47)

Du hast gar nicht gesungen. Moment, wo ist das Lied?

Andy Grunwald (01:04:47 - 01:05:27)

Meines Erachtens nach, macht euch einfach mal Gedanken, ob ihr wirklich einen Fork wollt, also ob ihr wirklich einen Fork maintainen wollt. Macht euch Gedanken, warum oder beziehungsweise wie ihr das Ganze forkt. Ob und mit welcher Motivation. Denn im Endeffekt ist ein Pull Request immer noch das beste zum Upstream Projekt zu kontributen, auch wenn er nicht sofort angenommen wird. Versetzt euch bitte in die Lage der Maintainerin, der Maintainer. Vielleicht haben die gerade Nachwuchs bekommen, vielleicht wechseln die gerade den Job, vielleicht sitzt er gerade im Gefängnis, ich weiß es nicht. Auf jeden Fall, das sind auch nur Menschen, die haben auch ein Leben. Und vielleicht ist das Leben von denen gerade ein bisschen busier und vielleicht sagen die hey, der Pulverquest vom Wolfgang ist jetzt nicht so wichtig.

Wolfi Gassler (01:05:27 - 01:05:46)

Und es ist ja auch private Zeit, muss man ja auch dazu sagen, von den Leuten. Also gleich wie man selbst die Zeit investiert, private Zeit investieren die anderen auch und haben schon viel Zeit investiert. Und man muss teilweise einfach auch dran bleiben und vielleicht paar Messages mehr schicken und nicht sich sofort abschmettern lassen. Und vielleicht hat man dann sogar noch eine viel bessere Ÿousand Beziehung, wenn man sich da mal durchgekämpft.

Andy Grunwald (01:05:46 - 01:05:53)

Naja, also sehr, sehr viel Open Source Software wird auch aus kommerziellem Umfeld maintained, deswegen ist das nicht nur private Zeit.

Wolfi Gassler (01:05:53 - 01:05:59)

Aber es klar, zu MySQL zu contributen ist schwierig. Ja, das stimmt. Zu Own Cloud genauso.

Andy Grunwald (01:05:59 - 01:06:26)

Deswegen, forken ist nicht immer einfach, egal ob du der Forkende bist oder der Geforkte. Macht euch Gedanken darüber, was die Zukunft dieses Projektes denn wirklich ist. Denn wenn du was forgst, dann ist es ja auch in irgendeiner Art und Weise etwas, was du mitnehmen musst. Denn Sicherheitslücken gibt es überall und irgendwo müssen die gefixt werden, entweder upstream oder im Fork, ansonsten bist du halt der Attack Vektor. Nun gut, das war es von uns. Mal ein bisschen Einsicht in Open Source.

Wolfi Gassler (01:06:26 - 01:06:49)

Und wie man da auch wieder sieht, es geht gar nicht um die eine kleine technische Funktion des Forks, sondern um alles rundherum, was wir jetzt besprochen haben. Und darum ist das Ganze eigentlich komplexer als bei Andy. Vielen Dank für deine Einblicke. Für Alle anderen, wenn ihr irgendwelche Einblicke teilen wollt mit Forking, was ihr so erlebt habt, vielleicht auch ein paar Screenshots von Pull Requests, die abgelehnt wurden, empfangen wir auch immer gerne in unserer Discord Community.

Andy Grunwald (01:06:49 - 01:06:54)

Der gute österreichische Mittelstand ist natürlich auch sehr gerne im Discord willkommen.

Wolfi Gassler (01:06:54 - 01:06:57)

Ja, da sind schon ganz viele von unserem Meetup in Innsbruck garantiert.

Andy Grunwald (01:06:57 - 01:07:27)

Ich finde es immer wieder faszinierend, wenn wir über Themen sprechen, die aktive Open Source Contributor so als gegeben hinnehmen, weil, und wenn man darüber ein bisschen philosophiert, ein bisschen nachdenkt, dann merkt man erst wirklich, Open Source ist nicht wirklich Technologie. Open Source ist wirklich nur die Zusammenarbeit mit Menschen, mit all diesen Problemen, was das bringt aber auch was tolles, denn wie wir auch in dieser Episode gesagt haben, es gab ein paar sehr, sehr tolle Forks, die sehr, sehr groß geworden sind. Und vielen Dank an alle, die an diesen Forks auch mitarbeiten. Das war's von uns. Wir hören uns in der nächsten Episode. Bis später.

Wolfi Gassler (01:07:27 - 01:07:27)

Tschüss.