Позвольте мне подробнее раскрыть то, что сказал @Stephen.
Как разработчик плагинов, я могу сказать, что поддержание кода в актуальном состоянии и совместимости с ядром — задача не из легких, требующая тщательной стратегии. Плагины обычно синхронизируются с веткой tests-passed. Вы можете выбрать более медленную ветку, но тогда и ваши клиенты тоже будут отставать. Это нормально. Однако вам потребуется время на обновление вашего приложения после каждого стабильного релиза. Это потребует значительных усилий и может привести к существенным задержкам в обновлениях для клиентов.
Как и в случае с плагинами, всегда существует риск того, что что-то сломается после существенных изменений в ядре.
Вы утверждаете, что ядро Discourse стабильно. Возможно, оно стало стабильнее, чем в начале, но внимательно посмотрите на репозиторий: он активно развивается (хотя значительная часть изменений касается веб-приложения). Просто посмотрите, сколько коммитов делается ежедневно. Посмотрите на количество открытых Pull Request’ов. Возьмите хотя бы один файл, например Topic.hbs, и подумайте, как вы будете успевать за изменениями только в нем? Даже форк ядра Discourse не рекомендуется именно из-за этой проблемы. А вы планируете делать нативную переписку?
Будете ли вы использовать только их API? Тогда хорошо, но как вы реализуете популярные плагины? Некоторые из них вносят значительные визуальные изменения, большинство из которых используют monkey-patching (например, с помощью JQuery) или plugin outlets, которые вы не сможете переиспользовать, если перейдете на нативную разработку. Вы будете переписывать их на нативном коде?
Плагины — лишь верхушка айсберга. То, что вы предлагаете, предположительно охватывает весь фронтенд-функционал для пользователей. Всё это нужно будет тестировать. И писать тест-кейсы. Просто вау.
И насколько велика ваша команда? Снова посмотрите, сколько разработчиков вносит вклад в ядро. Добавьте к этому количество авторов плагинов в вашей области интересов. Это даст вам ещё одну метрику для оценки масштаба задачи.
Вам понадобится скорость разработки, сопоставимая с темпом релизов Discourse (!), иначе все ваши клиенты начнут чувствовать, что их ограничивают в доступе к новым функциям.
Вам нужно будет обосновывать каждый потраченный час и компенсировать эти затраты выручкой (и это нормально, вам, как и всем остальным, нужно зарабатывать на жизнь).
В любом случае, я думаю, вы могли бы попробовать реализовать это с целью создания демонстрационной версии. Я бы начал «просто» с основного приложения. Это быстро даст вам понимание масштаба задачи. Или просто посчитайте, сколько вызовов API вам потребуется поддерживать.
Уверен, вы уже обдумали всё это. Я не хочу вас расстраивать, но вы предлагаете серьёзный объём работы, который придётся выполнять постоянно и безжалостно.
Как насчёт того, чтобы посмотреть на официальное приложение и попробовать сделать что-то с его помощью?