Permettez-moi de préciser ce que @Stephen a dit.
En tant que développeur de plugins, je peux vous dire que maintenir le code à jour pour qu’il soit compatible avec le cœur du système n’est pas une tâche triviale et nécessite une stratégie minutieuse. Les plugins sont généralement maintenus en phase avec la branche « tests-passés ». Vous pourriez opter pour une branche plus lente, mais cela signifie que vos clients aussi le seront. Ce n’est pas grave, bien sûr. Mais vous aurez besoin d’un délai pour mettre à jour votre application après chaque version stable. Cela représentera beaucoup de travail et pourrait entraîner des retards significatifs dans les mises à jour destinées aux clients.
Comme pour les plugins, vous courez toujours le risque qu’un élément se rompe après un changement suffisamment important dans le cœur du système.
Vous affirmez que le cœur de Discourse est stable. Peut-être plus qu’au début, mais jetez un œil attentif au dépôt : il évolue (même si une grande partie de ces changements concerne l’application web). Regardez simplement le nombre de commits quotidiens. Examinez le nombre de PR ouvertes. Prenez un seul fichier, par exemple Topic.hbs, et réfléchissez à comment vous comptez suivre uniquement cela ? Même le fork de la base du cœur de Discourse est déconseillé précisément à cause de ce défi. Et vous parlez d’une réécriture native ?
Utiliserez-vous uniquement leur API ? Dans ce cas, très bien, mais comment allez-vous implémenter n’importe lequel des plugins populaires ? Certains d’entre eux comportent des modifications visuelles importantes, dont la plupart utilisent du monkey-patching avec, par exemple, jQuery ou des emplacements de plugins que vous ne pourrez pas réutiliser si vous passez au natif. Allez-vous les réimplémenter avec du code natif ?
Les plugins ne sont que la pointe de l’iceberg. Ce que vous proposez couvre probablement l’ensemble des fonctionnalités frontales destinées aux utilisateurs. Tout cela devra être testé, avec des cas de test. Juste wow.
Et quelle est la taille de votre équipe ? Encore une fois, regardez combien de développeurs contribuent au cœur du système. Ajoutez-y la population d’auteurs de plugins concernés. Cela vous donne une autre métrique pour évaluer l’ampleur du défi.
Vous devrez avoir une vélocité qui correspond aux versions de Discourse (!), sinon tous vos clients commenceront à avoir l’impression d’être freinés dans l’accès aux nouvelles fonctionnalités.
Vous devrez justifier chaque heure passée et la rentabiliser en revenus (et c’est normal, vous devez mettre de la nourriture sur la table comme nous tous).
Mais dans tous les cas, je pense que vous pourriez essayer de l’implémenter dans le but de le démontrer. Je commencerais par « simplement » l’application de base. Cela vous donnera rapidement une idée de l’ampleur de la tâche. Ou comptez simplement toutes les appels API que vous devrez prendre en charge.
Je suis sûr que vous avez déjà réfléchi à tout cela. Je ne veux pas jeter un froid, mais ce que vous proposez représente une quantité de travail considérable, et ce de manière continue et implacable.
Que diriez-vous d’examiner l’application officielle et de voir ce que vous pouvez faire avec ?