Permíteme ampliar lo que ha dicho @Stephen.
Como desarrollador de plugins, puedo decirte que mantener el código actualizado para que sea compatible con el núcleo no es una tarea trivial y requiere una estrategia cuidadosa. Los plugins suelen mantenerse al día con la rama tests-passed. Podrías optar por una rama más lenta, pero eso significa que tus clientes también lo estarán. Eso está bien, pero necesitarás un margen de tiempo para actualizar tu aplicación después de cada versión estable. Eso implicará mucho trabajo y podría provocar retrasos significativos en las actualizaciones para los clientes.
Al igual que con los plugins, siempre existe el riesgo continuo de que algo se rompa tras un cambio lo suficientemente importante en el núcleo.
Afirmas que el núcleo de Discourse es estable. Quizás más que al principio, pero echa un vistazo cuidadoso al repositorio; sí evoluciona (aunque gran parte de ello puede deberse a la aplicación web). Solo observa cuántos commits hay a diario. Mira el número de PR abiertos. Toma un solo archivo, por ejemplo Topic.hbs, y considera cómo vas a mantener el ritmo solo con eso. Incluso se desaconseja hacer un fork de la base del núcleo de Discourse precisamente por este desafío. ¿Y esto será una reescritura nativa?
¿Usarás solo su API? Entonces bien, pero ¿cómo implementarás alguno de los plugins populares? Algunos de ellos tienen cambios visuales significativos, la mayoría de los cuales utilizan monkey-patching con, por ejemplo, JQuery o plugin outlets, los cuales no podrás reutilizar si te vas por la vía nativa. ¿Vas a reimplementarlos con código nativo?
Los plugins son solo la punta del iceberg. Lo que propones es presumiblemente el alcance completo de toda la funcionalidad del frontend para el usuario. Todo esto necesitará pruebas. Y casos de prueba. Simplemente, wow.
¿Y qué tamaño tiene tu equipo? De nuevo, echa un vistazo a cuántos desarrolladores están haciendo commits al núcleo. Añade la población de autores de plugins que estén dentro del alcance. Eso te da otra métrica para dimensionar la magnitud del desafío.
Necesitarás una velocidad que iguale las versiones de Discourse (!), o todos tus clientes empezarán a sentir que se les está frenando el acceso a nuevas funciones.
Tendrás que justificar cada hora que dediques y recuperar eso en ingresos (y eso está bien, necesitas poner comida en la mesa como el resto de nosotros).
Pero, en cualquier caso, creo que podrías intentarlo con el objetivo de hacer una demostración. Yo empezaría con «solo» la aplicación principal. Eso te dará rápidamente una idea de lo grande que es la tarea. O simplemente cuenta todas las llamadas a la API que necesitarás soportar.
Estoy seguro de que ya lo has pensado todo. No quiero ser negativo al respecto, pero estás proponiendo una cantidad seria de trabajo, y de manera continua y brutalmente implacable.
¿Qué tal si miras la aplicación oficial y ves qué puedes hacer con ella?