Ich bin mir nicht ganz sicher, woher diese 1 % Zahl stammt, aber bei 14 Millionen Benutzern wären das immer noch 14.000 Benutzer, die dadurch von Discourse ausgeschlossen würden. Nur um ein paar CSS- und Performance-Optimierungen hinzuzufügen?
Zu der Frage „Wie viele Benutzer sollen den verbleibenden Prozentsatz daran hindern, ihre aktuelle Software zu nutzen?“ … warum kann diese Zahl nicht weit, weit unter 1 % liegen, viel näher bei 0 % als bei 1 %? Ich würde argumentieren, dass Discourse den entgegengesetzten Ansatz verfolgen sollte, keine unnötigen abwärtskompatiblen Änderungen vorzunehmen, es sei denn, es gibt eine zwingende kritische Korrektur oder ein wichtiges Feature, das dies absolut erfordert, UND es gibt eine breite Benutzerforderung danach.
Das Gegenteil dieser Frage ist: „Wie viele Benutzer sind wir bereit auszuschließen, um geringfügige Annehmlichkeiten mit geringen oder keinen Auswirkungen auf den Benutzer zu erzielen?“ Lohnt sich ein kleiner Performance-Schub, der auf allem außer sorgfältigen Benchmarks kaum bemerkbar sein wird, um 14.000 Personen von ihren Communities abzuschneiden?
Welche Art von „aktueller Software“ fordern Forenbenutzer …? Es ist ein Forum. Leute lesen Text und antworten auf Textbeiträge. Es ist beängstigend, dass die Entwickler immer wieder sagen: „Wir müssen weitermachen“, während Ihre tatsächlichen Kunden sagen: Moment mal, warum, keines dieser Features bedeutet etwas und Sie schließen echte Leute aus.
Ich habe das Gefühl, dass dies genau der entgegengesetzte Ansatz ist, den man von stabiler, alter Forensoftware wie Discourse erwarten würde. Wenn Sie mit neuen Funktionen experimentieren möchten, sollte dies auf einem instabilen Canary-Zweig geschehen, zu dem sich die Benutzer explizit anmelden müssen, und der Hauptzweig sollte standardmäßig LTS sein. Sie bieten nicht nur keine progressiven Verbesserungen, sondern auch keine graceful degradations. Das ist eine Wahl, keine inhärente Eigenschaft der Softwareentwicklung. Sie entscheiden sich, schneller voranzukommen, als Ihre Benutzer mithalten können.
Und Ihre gehosteten Communities haben überhaupt keine Wahl. Diejenigen, die Sie für ihre Community bezahlen, nicht für eine technische Demo und ein JS-Spielzeug.
DAS ist, warum es ein kulturelles Problem und kein technisches Problem ist. Danke, dass Sie es zumindest laut aussprechen. Sie haben die Kosten dafür in Entwicklerstunden gegen geschätzte Auswirkungen auf die Benutzer abgewogen, und in Ihrer Rechnung sind die Benutzer weniger wert als die Kosten, die für die Erstellung einer grundlegenden Posting-Version anfallen würden. Es gibt keinen anderen Weg, es zu sagen: Sie schätzen Ihre echten Benutzer und Communities nicht so sehr wie Entwickler-Abkürzungen 
Entschuldigen Sie, dass ich dieses Zitat etwas aus dem Kontext gerissen habe, aber … wenn Sie aufhören würden, in Prozentzahlen zu denken, und über die Auswirkungen auf echte Einzelpersonen in ihren Communities nachdenken würden, sähe die Rechnung vielleicht anders aus?
Das Ganze ist ein bisschen stalinistisch, den Leuten zu sagen, dass sie im Grunde eine entbehrliche Statistik sind, weil sie zu arm sind, um ihre Hardware aufzurüsten, oder dass es ihre eigene Schuld ist, weil sie nicht bereit und in der Lage sind, Hürden zu überwinden, um ein anderes Betriebssystem oder eine Kompatibilitätsschicht oder einen Browser-Fork zu installieren … nur damit sie weiterhin Textnachrichten in einem Forum posten können, dem sie seit vielen Jahren angehören?
Dies ist die Art von Kosten-Nutzen-Abwägung, die ich von einer großen neuen Version erwarten würde, wie einer vollständigen Neufassung, nicht von einigen geringfügigen, unsichtbaren Entwickler-Features, die möglicherweise geringe Leistungsvorteile haben =/ Es ist wirklich bedauerlich, dass Ihr Unternehmen diese Haltung einnimmt, meiner Meinung nach, aber trotzdem … ich schätze die Transparenz wirklich.
OK. Jedenfalls genug Gejammer. Ich habe eine potenziell/hoffentlich konstruktivere Frage …
Wenn wir davon ausgehen, dass ein einfacher HTML-Modus für eine kleine Anzahl von Benutzern hilfreich wäre, aber Discourse nicht bereit ist, Ressourcen für die Erstellung selbst aufzuwenden … ist dies etwas, das die Open-Source-Community potenziell übernehmen könnte? Es scheint etwas zu groß zu sein, um etwas wie ein Plugin zu sein, aber immer noch zu klein für ein eigenes Projekt (wie Discorkie).
Wäre es denkbar, dies als ein alternatives Open-Frontend zu konzipieren, das mit den aktuellen APIs funktioniert, und wenn ja, gäbe es eine Chance, dass ein solches Ding (wenn es jemals gebaut und getestet wurde) „offiziell“ in die Hauptsoftware integriert/akzeptiert wird, sodass es auch auf gehosteten Discourse-Instanzen verwendet werden könnte (wo sich eine meiner betroffenen Communities befindet)?
In diesem Zusammenhang, haben Sie irgendein System zur API-Versionierung/-Stabilität, dem ein solches alternatives Frontend folgen könnte?
Vielleicht ist die Antwort dort immer noch eine Reihe von „Neins“ aus verschiedenen Gründen, und wenn ja, ist das in Ordnung, aber wenn es überhaupt machbar ist … vielleicht interessant darüber nachzudenken? Ich bitte nicht um eine vollständige Machbarkeitsstudie, vielleicht nur um ein paar Bauchgefühle?
Ich bin mir nicht sicher, ob so etwas jemals Anklang finden oder gepflegt werden könnte. Nicht viele Entwickler arbeiten gerne an alter Software mit HTML und minimalem JS (aber es gibt immer noch einige, wie die HTMX-Leute). Nur ein Gedanke.