Erlaube mir, das auszuführen, was @Stephen gesagt hat.
Als Plugin-Entwickler kann ich dir sagen, dass es keine einfache Aufgabe ist, den Code stets aktuell und kompatibel mit dem Kern zu halten, und dies erfordert eine sorgfältige Strategie. Plugins werden normalerweise mit dem „tests-passed“-Zweig synchron gehalten. Du könntest einen langsameren Zweig wählen, aber das bedeutet, dass auch deine Kunden langsamer sind. Das ist in Ordnung. Du wirst jedoch Vorlaufzeit benötigen, um deine Anwendung nach jedem stabilen Release zu aktualisieren. Das wird viel Arbeit bedeuten und könnte zu erheblichen Verzögerungen bei den Updates für deine Kunden führen.
Wie bei Plugins besteht auch hier ständig das Risiko, dass nach einer signifikanten Änderung im Kern etwas kaputtgeht.
Du stellst fest, dass Discourse-Kern stabil ist. Vielleicht stabiler als am Anfang, aber wirf bitte einen genauen Blick auf das Repository – es bewegt sich durchaus (wobei ein Großteil davon die Web-App betrifft). Schau dir einfach an, wie viele Commits täglich erfolgen. Betrachte die Anzahl der offenen PRs. Nimm nur eine Datei, z. B. Topic.hbs, und überlege, wie du damit Schritt halten wirst? Selbst das Forken der Discourse-Kernbasis wird genau wegen dieser Herausforderung abgeraten. Und das soll eine native Neuentwicklung sein?
Wirst du nur deren API nutzen? Dann ist das in Ordnung, aber wie wirst du dann beliebte Plugins implementieren? Einige davon haben erhebliche visuelle Änderungen, die größtenteils auf Monkey-Patching mit z. B. JQuery oder Plugin-Ausgängen basieren, die du nicht wiederverwenden kannst, wenn du native Entwicklung wählst. wirst du diese mit nativem Code neu implementieren?
Plugins sind nur die Spitze des Eisbergs. Was du vorschlägst, umfasst vermutlich den vollständigen Umfang aller Frontend-Funktionalitäten für Benutzer. All das muss getestet werden. Und Testfälle. Einfach wow.
Und wie groß ist dein Team? Schau dir erneut an, wie viele Entwickler am Kern mitarbeiten. Addiere die Anzahl der Plugin-Autoren, die im Scope liegen. Das gibt dir eine weitere Metrik für die Größe der Herausforderung.
Du benötigst eine Geschwindigkeit, die mit Discourse-Release-Zyklen mithält (!), sonst werden alle deine Kunden das Gefühl haben, von neuen Funktionen zurückgehalten zu werden.
Du musst jede Stunde, die du verbringst, rechtfertigen und durch Einnahmen wieder einspielen (und das ist in Ordnung, du musst wie wir alle deine Rechnungen bezahlen).
Aber ich denke, du könntest es trotzdem versuchen, mit dem Ziel, eine Demo zu erstellen. Ich würde mit „nur“ der Kern-App beginnen. Das wird dir schnell ein Gefühl dafür geben, wie groß die Aufgabe ist. Oder zähle einfach alle API-Aufrufe zusammen, die du unterstützen musst.
Ich bin sicher, du hast über all das nachgedacht. Ich möchte dich nicht entmutigen, aber dies ist eine erhebliche Menge an Arbeit, die du vorschlägst, und das auf kontinuierlicher, gnadenloser Basis.
Wie wäre es, die offizielle App zu betrachten und zu sehen, was du damit erreichen kannst?