OpenD, ein D-Sprach-Fork, der Beiträge willkommen heißt

• Weil sich über lange Zeit Unzufriedenheit darüber aufgestaut hatte, dass Beiträge über die bisherige D-Führung blockiert wurden, wechselten einige Mitwirkende zu OpenD, einem Fork der Programmiersprache D
• Der Kern des Konflikts ist weniger die Frage, ob D Closed Source ist, sondern dass Entwicklungsweise und Entscheidungsfindung selbst nach der GPL-Veröffentlichung und dem Release von gdc der Community nicht ausreichend offenstanden
• Als Begründung für den Fork werden der Fall Ares/Tango, der später zu druntime führte, der Rückgang der Phobos-Aktivität, liegen gelassene PRs und die mangelnde Umsetzung nach „D gripes and wishes“ angeführt
• Nach dem Wechsel zu OpenD werden PRs, Bug-Reports, User-Support, DLF-Meetings und die Teilnahme an DConf Online für Upstream-D eingestellt; dpldocs.info bleibt bestehen, solange die Kosten gedeckt sind
• Bestehende D-Bibliotheken und -Anwendungen ohne bezahlten Supportvertrag erhalten keine garantierte Kompatibilität mit Upstream-D mehr; der Weg für langfristigen Support verlagert sich zur Beteiligung an OpenD

---

Warum zu OpenD gewechselt wurde

• OpenD ist ein Fork der Programmiersprache D und entstand aus der Einsicht, dass der Prozess, über die bisherige D-Führung Beiträge in Upstream einzubringen, seit Langem sehr frustrierend war
• Die immer wiederholte Behauptung, D sei eine Closed-Source-Sprache, ist nicht korrekt
  • Die D-spezifischen Teile des Compilers wurden 2002 unter GPL veröffentlicht
  • gdc als vollständiger GPL-Compiler wurde 2004 veröffentlicht
• Kritisiert wird jedoch, dass die Entwicklungsmethodik von D nicht ausreichend offen war und die Community bei Entscheidungen nur sehr wenig sinnvollen Einfluss hatte
• Viele Kernfunktionen und Konzepte von D sowie ein erheblicher Teil des heute existierenden D-Codes stammen aus Community-Beiträgen und -Arbeit, doch wenn man nur auf angenommene Beiträge schaut, kann man leicht in einen Survivorship Bias geraten

Alter Beitragsengpass und der Fall Ares/Tango

• In der Geschichte von D gab es viele angenommene Patches, aber auch viele Patches, die über lange Zeit liegen gelassen wurden
• Der Code, der heute als druntime bekannt ist, ging aus einem Fork hervor, der entstand, weil Walter keine Community-Beiträge annahm
  • 2004 forkten Entwickler, die mit Upstream zusammenarbeiten wollten, D, um ihre Beiträge nicht zu verlieren
  • Dieser Fork hieß zunächst Ares und wurde später mit anderen Community-Bemühungen zu Tango zusammengeführt
• Tango verstand sich als „The Developer's Library for D“ und funktionierte als Raum, in dem Beiträge von Entwicklern tatsächlich willkommen waren
  • Im Tango-Ökosystem gab es viele Elemente, die im Phobos-Ökosystem fehlten
• Nachdem der Fork vier Jahre lang Bestand hatte und an Popularität gewann, suchte Upstream die Versöhnung; aus dieser Entwicklung entstand das heutige druntime
• Dahinter steht die Einschätzung, dass D ohne den Fork Ares/Tango keine relevante Position im Markt erreicht hätte und dass dieser Fork D in einer Krisenphase gerettet habe

Sinkende Beteiligung nach der goldenen Zeit

• Die Zeit, in der die Kernentwickler von Tango zurückkehrten und sich Andrei Alexandrescu und andere anschlossen, wird als vergleichsweise offene Phase der D-Entwicklung und als goldene Zeit mit steigender Aktivität rund um 2013 beschrieben
• Hervorgehoben wird auch, dass nahezu alle kommerziellen Nutzer von D direkt von Code abhingen, der aus dem Ares-Fork hervorgegangen war
• Die alten Gewohnheiten verschwanden jedoch nicht, und viele Mitwirkende aus der goldenen Zeit blieben der Community nicht erhalten
  • Einige gingen ausdrücklich, weil sie den kaputten Prozess als Grund nannten, in dem ihre Arbeit nicht gewürdigt wurde
  • Andere wurden aus persönlichen Gründen weniger aktiv, und es blieben nicht genug neue Mitwirkende dauerhaft dabei
• Die Entwicklungsaktivität von Phobos nahm ab Mitte 2018 stark ab; danach gab es zwei kleinere Anstiege
  • berni44s Ergänzung von CTFE-fähiger Gleitkommaformatierung
  • die Übernahme von Paul Backus’ sumtype-Modul als std.sumtype
• berni44 erklärte 2020 nach fast drei Monaten Wartezeit auf ein PR-Review, dass er die Community verlassen werde; ein Jahr später kehrte er zurück und sorgte für den jüngsten Anstieg der Phobos-Aktivität, verließ sie aber wenige Monate später erneut
• Auch bei dmd selbst blieb Walters persönlicher Beitragsumfang insgesamt relativ konstant, doch weil die Beiträge anderer zurückgingen, stieg sein Anteil von etwa 1/6 in der goldenen Zeit auf heute etwa 1/3

Wiederholtes Sammeln von Beschwerden, aber zu wenig Umsetzung

• Rund um Weihnachten 2022 bat Mike Parker die Leute, ihm eine Liste mit „D gripes and wishes“ zu schicken
• Viele gingen davon aus, dass daraus nichts werden würde, dennoch gab es viele Antworten
• Etwa sechs Monate später, am 18. Mai 2023, wurde ein öffentliches Dokument mit den gesammelten Antworten veröffentlicht
• Danach beschränkten sich die öffentlich erkennbaren Ergebnisse auf die Festlegung folgender Ziele
  • Stabilisierung von Sprache, Compiler und Standardbibliothek
  • Verbesserung des Ökosystems einschließlich Unterstützung für Tools und Third-Party-Bibliotheken
  • Stärkung der Community durch Aufräumen der Website, Aktualisierung veralteter Dokumentation und Tutorials sowie ein Redesign der Website
• Zwar lautete die Bitte, nicht allgemein, sondern konkret zu schreiben, doch viele konkrete Beschwerden wurden am Ende nur mit übergeordneten Ziel-Bullets beantwortet
• Schon im Vision Document 2016H1 gab es ähnliche Ziele wie mehr Beteiligung, bessere Tools, Stabilität von Sprache und Verbesserungen an der Spezifikation sowie zusätzliche Bibliotheken; deshalb sei nun eher Umsetzung als weitere Zielformulierung nötig

Was sich mit dem Wechsel zu OpenD ändert

• Versuche, zu Upstream-D beizutragen, werden eingestellt, stattdessen erfolgt der Wechsel zu OpenD, einem Fork des gesamten Compilers
• Das Dokumentations-Hosting von dpldocs.info wird über Patreon gerade so finanziert und läuft einschließlich der Unterstützung für dub-Pakete weiter, solange die Kosten gedeckt bleiben
  • Updates von Upstream-D werden nicht übernommen
  • Bestehende Funktionen werden vermutlich weiter weitgehend problemlos funktionieren
• Im Blog wird der auf Upstream-D spezialisierte Support eingestellt
  • Statistiken werden nicht mehr aufgenommen
  • Der Name ändert sich zu „This Week in ARSD“ und könnte später zu „This Week in OpenD“ werden
• PRs und Bug-Reports für Upstream-D werden mit sofortiger Wirkung eingestellt
  • Was für die eigene Arbeit hilfreich ist, wird nicht an Upstream geschickt, sondern in OpenD gemergt
• Auch der Support für D-Nutzer wird eingestellt
  • In der Vergangenheit wurden pro Woche mehrere Stunden in die Unterstützung von D-Nutzern unterschiedlicher Erfahrungsstufen investiert, nun gibt es keine Zusage mehr, auf Fragen zu Upstream-D zu antworten
  • Falls doch geantwortet wird, dürfte die Empfehlung oft lauten, OpenD auszuprobieren
• An DLF-Meetings wird nicht teilgenommen, sofern nicht vorab Änderungen an der Governance zugesagt werden
• Einladungen zu DConf Online Livestreams werden abgelehnt
• Bei D-Bibliotheken wird das Kompatibilitätsversprechen zwischen internen Versionen und externen Compiler-Updates nur noch für Ziele mit bezahltem Supportvertrag aufrechterhalten
  • Für alle anderen Nutzer entfällt die Kompatibilität mit Upstream-D mit sofortiger Wirkung
  • Der Code wird ohne jede ausdrückliche oder stillschweigende Gewährleistung so bereitgestellt, wie er ist
  • Wer sich dem OpenD-Fork anschließt, erhält für diese Bibliotheken weiterhin Support
• Für D-Anwendungen gilt wie bei Bibliotheken kein Kompatibilitätsversprechen gegenüber Upstream-D; da sie ursprünglich für den Eigengebrauch entwickelt wurden, war diese Garantie ohnehin lockerer

Verbleibende Haltung

• Es wird erklärt, dass in den vergangenen 16 Jahren sehr viel Zeit in D investiert wurde und dass ein Großteil der eigenen Programmierkarriere D und davor Digital Mars C++ zu verdanken sei
• Walter Bright und seine Kollegen hätten das eigene Leben stark beeinflusst, und Walter wird als bedeutender Mitwirkender an Programmiersprachenprojekten gewürdigt
• Dennoch fällt nun die Entscheidung, Walter Brights D zu verlassen und mit OpenD einen eigenen Weg einzuschlagen
• Damit OpenD Erfolg haben kann, ist noch viel Arbeit nötig, und die Wahrscheinlichkeit des Scheiterns ist sehr hoch; die Verantwortung für ein mögliches Scheitern liege nun aber nur noch bei OpenD selbst

[GN⁺]

Meinungen auf Hacker News

• Zumindest Walter und vermutlich auch andere aus der D-Führung sind hier aktiv, daher ist die Wahrscheinlichkeit groß, dass sie diese Kommentare sehen
  Ich hoffe, man erinnert sich daran, dass auch sie Menschen sind, dass ihnen D wirklich am Herzen liegt und dass sie meiner Erfahrung nach im Grunde anständige Leute sind, die ihr Bestes geben wollen

  • Mehr als 20 Jahre sind vergangen, und tatsächlich hat sich kaum etwas geändert
    Ich weiß nicht, warum es diesmal anders sein sollte, und es fühlt sich an wie eine Wiederholung von Tango, Teil 2
    Nur mit dem Unterschied, dass der Zug inzwischen schon vor langer Zeit abgefahren ist
  • Das stimmt, und ich stimme zu, dass alle Menschen sind, aber Walter ist hier nicht der Einzige, dem D am Herzen liegt
    Wenn das Projekt unter einer anderen Führung besser laufen könnte, sollte man diese Möglichkeit prüfen
    Persönlich wünsche ich mir wirklich, dass D wieder auflebt; es ist bis heute meine Lieblingssprache
    Es geht nicht darum, Walter oder irgendwen sonst anzugreifen, sondern nur um Leute, die etwas retten wollen, das sie mögen

• Leider war so etwas am Ende unvermeidlich. Seit Jahren wurde einfach zu viel über einen D-Fork gesprochen
  Als 2010 Andrei Alexandrescus Buch erschien, wanderte fast alles, was an D gut war, in C#, Java und C++
  Die Umsetzung mag nicht so sauber sein wie in D, aber wenn man es in irgendeiner Form in einem besseren Tool- und Library-Ökosystem nutzen kann, ist dieser Unterschied nicht mehr besonders wichtig
  Zu viel Zeit ging bei der Jagd nach goldenen Features verloren, die Leute anziehen sollten, und diese Features wurden nicht einmal stabilisiert
  Andrei scheint heutzutage auch mehr mit C++ und CUDA beschäftigt zu sein als mit D
  Dazu kam in den letzten zehn Jahren noch die Renaissance nativ kompilierter Programmiersprachen, wodurch die Konkurrenz noch härter wurde
  Deshalb ist es umso bedauerlicher. In der Community selbst gibt es viele großartige Leute, mit denen man gut diskutieren kann

  • Wenn dadurch die Sprache wiederbelebt wird und die bisherige Arbeit nicht verschwindet, sehe ich das eher als Glücksfall
    Ich nutze täglich Python, und es gibt vieles, das ich aus D vermisse
    Von der Performance ganz zu schweigen

• Als Außenstehender, der sich D angesehen hat, habe ich etwas Ähnliches beobachtet
  Als Rust noch neu war, wurde das Konzept der Lifetimes in der D-Community vorgeschlagen, aber Walter hielt es für unnötig
  Einige Jahre später brachte Walter einen eigenen Lifetime-Vorschlag, der sich ausreichend von Rust unterschied und deshalb weniger erprobt war als der frühere Vorschlag aus der Community
  Inzwischen habe ich das Interesse an D verloren, daher weiß ich nicht, wie ausgereift das neue Lifetime-Feature ist, aber ich wäre überrascht, wenn es so nützlich wäre wie in Rust

  • Ich bin mit den Lifetime-Ansätzen von Rust oder D nicht besonders vertraut, aber nach einer schnellen Suche im Forum scheint es, als hätte man das Sprachdesign stark ändern müssen, um Rust-artige Lifetimes in D einzubauen
    Bei jedem Feature gibt es Trade-offs wie Interaktionen mit anderen Sprachfeatures, kognitive Belastung, langsamere Kompilierung, höhere Komplexität beim Design der Standardbibliothek und Brüche der Abwärtskompatibilität
    Ich halte es nicht für vernünftig, eine große Umgestaltung zu erwarten, nur um ein Feature zu unterstützen, das man aus einer anderen Sprache mag
  • Damit kann es nun ein Projekt geben, in das statt Walters Meinung die Meinung von jemand anderem einfließt

• Meine Forschungsgruppe ist vor einigen Jahren wegen mangelnder Reaktionsbereitschaft und einer schlechten Richtung in der Sprachentwicklung von D zu Rust gewechselt
  Ich hoffe, dass Adam und die anderen mit OpenD Erfolg haben, aber ich fände es gut, wenn sie diese Gelegenheit nutzen würden, um einen markanteren und einprägsameren Namen zu wählen

• Ein neues Governance-Modell beginnt nicht damit, eine Liste neuer Features zu verkünden oder festzulegen, dass einige gestrichen werden, sondern damit, dass ein Quorum interessierter Parteien über Governance diskutiert
  Das ist keine Änderung des Modells, sondern nur ein Machtwechsel
  Es kann berechtigte Beschwerden geben, und die Art, wie D sich auf Walter als Gatekeeper verlässt, kann für manche zu strikt sein
  Aber die Art, wie dieser Fork gestartet wurde, ist langfristig kein gutes Zeichen
  Damit der Fork erfolgreich ist, braucht er breite Unterstützung und muss am Ende nicht nur ein paar wenige produktive Beitragende mitnehmen, sondern nahezu eine Mehrheit der D-Community
  Sonst scheitert auch der Fork, und die Aufmerksamkeit für das Original wird weiter aufgespalten, sodass selbst die verbleibende Überlebensfähigkeit verloren gehen kann
  Außerdem braucht es die Fähigkeit und den Willen, das Ganze über Jahrzehnte zu unterstützen

• Offenbar wurde ein Update veröffentlicht: https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h... und es scheint auch ein gewisses Interesse geweckt zu haben
  Persönlich hätte ich es lustiger gefunden, den Namen Died zu wählen
  Dann wären coole Sprüche wie „It never Died“ möglich, es würde auch zeigen, dass es ein Fork ist, und später bliebe bei Bedarf Spielraum, die Sprache in eine neue Richtung zu führen
  OpenD erweckt den Eindruck vollständiger Kompatibilität
  Natürlich bin ich an der Sache nicht direkt beteiligt und wünsche ihr Erfolg

• Im D-Forum gibt es einen großen Thread zu diesem Thema: https://forum.dlang.org/thread/[e-mail]...

  • Der große Thread, auf den hier verwiesen wird, stammt von den Leuten, die den Fork vorantreiben; bislang haben ihn zwei Personen gestartet, und er enthält auch ziemlich viele ausführliche Antworten von D-Seite, die im obigen Beitrag fehlen
    Im ursprünglichen Beitrag geht es hauptsächlich um Beschwerden über zwischenmenschliche Konflikte, während dieser Link mehr technische Diskussion enthält
    Danach zu urteilen wollen die Leute hinter dem Fork im Grunde eine andere Sprache und sind dafür offenbar auch bereit, mehrere Breaking Changes in Kauf zu nehmen

• Persönlich finde ich es verwirrend, welche Nische D anpeilt, wenn es sich voll auf den Garbage Collector konzentriert
  Eine klare Nische gab es auch früher nicht wirklich. Im Kern war es „10 % besseres C++“, und ohne klar differenzierendes Killer-Feature war es schwer zu verkaufen
  Die meisten werden wegen bestehender Unterstützung, Codebases und industrieller Basis wahrscheinlich bei C++ bleiben, für neue Projekte Rust verwenden oder, wenn sie Einfachheit wollen, Zig nehmen
  Besonders seit C++20 gibt es im Grunde bereits ein „10 % besseres C++“
  Ich weiß auch nicht, ob der Fokus auf den Garbage Collector wirklich viel hilft
  Dann konkurriert man mit C# und Java; beide waren von Anfang an als Sprachen mit Garbage Collection, Sicherheit und Knappheit als C++-Nachfolger gedacht, und ich sehe derzeit nicht recht, wie man mit ihnen konkurrieren will
  Besonders C# bietet neben ziemlich guten Low-Level- und unsafe-Funktionen wie rohen Zeigern, Kontrolle über Referenztypen/Werttypen und Kontrolle über das Speicherlayout auch ein für eine ältere, objektorientierungszentrierte Sprache ordentliches Typsystem und Reflection und übernimmt weiterhin Features aus der ML-Familie
  Ehrlich gesagt war Ds Vision für mich immer verwirrend
  Ich habe Dokumentation zu bestimmten Sprachfeatures wie BetterC, dem safe-Modus und Lifetimes gelesen, aber sie war syntaktisch schwer zu lesen, und trotz vieler Detailerklärungen insgesamt nicht gut erklärt
  Ich konnte keine kohärente Designvision oder keinen klaren Zweck der Sprache wirklich erkennen
  Der Autor spricht dieses Problem zwar an, aber ihre Vision wirkt auch nicht wesentlich klarer
  Es ist gut, dass es einige konkrete mittelfristige technische Ziele gibt, aber es ist nicht klar, wofür diese Ziele da sind
  Ich bin Rust-Programmierer, daher ist klar, was ich für neue persönliche Projekte verwenden würde; müsste ich aber etwas anderes wählen, würde ich eher OCaml, C++ oder sogar C# nehmen

  • Lange Zeit wurde D als besseres C++ beworben, und das war aus zwei Gründen falsch
    Erstens ist D ein Ersatz für C++, aber nicht C++; viele C++-Entwickler waren von diesem Unterschied frustriert
    Zweitens kann D weit mehr leisten als nur ein C++-Ersatz zu sein
    Man kann es für Skripte, als universelle Programmiersprache und besonders für C-Interoperabilität wie ImportC und BetterC verwenden
    Eines der Ziele des Forks ist es, sich wegen des Garbage Collectors nicht mehr zu entschuldigen
    In der Standardbibliothek gibt es weiterhin auch Reference Counting, Unique Pointer usw.
    Wenn jemand Funktionen beitragen möchte, die den Garbage Collector vermeiden, werden sie meiner Ansicht nach akzeptiert werden
    Allerdings wird man in diesem Fork Adam vermutlich seltener dabei sehen, wie er sich übermäßig bemüht, den Garbage Collector zu vermeiden, wenn er der Standardbibliothek neue Funktionen hinzufügt
    Er glaubt, dass die Angst vor dem Garbage Collector übertrieben ist

• In den letzten zehn Jahren gab es viel darüber zu lernen, wie Governance bei Programmiersprachen funktioniert
  Wenn man sich aufstrebende Sprachen im Wandel ansieht, haben auch sie große Konflikte oder Fehler im Zusammenhang mit Governance erlebt
  Ich denke, dass Governance inzwischen ein zentraler Punkt ist, auf den man bei Programmiersprachen achten sollte
  Man sollte betrachten, wie sie über ihre Arbeitsweise sprechen, wie sie tatsächlich arbeiten, welche Ergebnisse es bisher gab und wie es voraussichtlich weitergeht

  • Ich stimme zu, dass das ein wichtiges Problem ist, sehe aber keine zufriedenstellende Antwort
    Die Weiterentwicklung von Programmiersprachen ist fast schon Komplexitätsmanagement und muss zugleich die Anforderungen mehrerer Stakeholder ausgewogen berücksichtigen
    Fast alle Governance-Konflikte sind dadurch entstanden, dass eine Interessengruppe Anforderungen beanstandete, die für eine andere Gruppe unverzichtbar waren, und man kann nicht immer beide Seiten zufriedenstellen
    Rusts async ist ein bekanntes Beispiel dafür und erklärt ein Design, das zwar funktioniert, insgesamt aber unbefriedigend ist
    Go ist eine seltene Ausnahme: Das Kernteam hatte keinen Grund, alle Stakeholder gleichermaßen zu berücksichtigen, und hatte genug Ressourcen und Willen dazu, dennoch gab es auch dort einige Konflikte
  • Besser ist die Lage nicht geworden
    Das Modell der Standardisierung aus den 1960er- bis 1980er-Jahren war deutlich besser und begrenzte politische Kämpfe auf kurze Zeiträume

• Mir ist nicht klar, welche Nachteile es haben soll, mehrere Compiler-Implementierungen zu geben
  Persönlich halte ich das für einen Hauptgrund, warum C so weit verbreitet ist
  Compiler können unterschiedliche Richtungen erkunden, und Spracherweiterungen, deren Wert sich gezeigt hat, werden schließlich auch von anderen Implementierungen übernommen und schaffen es manchmal in den Standard, ohne im Konsensprozess eines Komitees zu stark beschädigt zu werden

  • Ich bin verwirrt, weil ich dachte, es gebe bereits etwa drei
    Zumindest nahm ich an, dass es mit gcc und der dlang-seitigen Implementierung mindestens zwei gibt