Фаза 4: Продукт и стандарт

Превратить протокол в массовый продукт и формальный стандарт. Десктоп-приложение для не-разработчиков, RFC-драфт FSS, 1000+ активных узлов, экосистема сторонних имплементаций.

Зачем нужно отдельное приложение

Фазы 1-3 покрывают технических пользователей: плагин Obsidian + CLI. Но 90% целевой аудитории (исследователи, аналитики, продвинутые PKM-пользователи) не хотят ставить Obsidian и плагин, не хотят работать с CLI. Им нужно «скачать приложение, нажать кнопку, получить семантический граф». Tauri-приложение — этот мост.

Tauri выбран осознанно: он даёт нативный опыт (как у Obsidian) без тяжести Electron (Tauri-приложение ~10 МБ против Electron ~150 МБ). Веб-фронтенд на SvelteKit или React даёт быструю разработку UI. Rust-ядро даёт производительность для операций с большим графом. Cross-platform: одна кодовая база для macOS, Windows, Linux.

Что в приложении

Приложение выглядит как Obsidian, но с тремя ключевыми отличиями. Первое — типизированные свойства встроены в редактор: при создании заметки пользователь выбирает тип (фильм, книга, человек, проект), и редактор предлагает релевантные поля. Второе — граф-визуализация: отдельная панель, где видно триплеты как граф узлов и рёбер, с фильтрами по типам. Третье — чат с локальным LLM, который понимает граф и отвечает с provenance.

Мобильное приложение

Минимальное мобильное приложение для iOS и Android — в первую очередь для чтения и запросов, не для редактирования. Сценарий: в дороге вспомнить, что я читал про экзистенциализм, посмотреть оценки книг от друзей, задать вопрос графу. Редактирование на мобильном — отдельная задача, которая требует продуманного UX и не входит в v1.

Технически — React Native или Expo, с доступом к локальному узлу через HTTPS (узел запущен на домашнем компьютере или VPS). Это проще, чем полноценная локальная имплементация на мобильном, и достаточно для целевого сценария. Полная мобильная имплементация — вопрос будущего, не фазы 4.

RFC-драфт

Спецификация FSS v1.0 (из фазы 2) перерабатывается в формат RFC и подаётся в IETF или W3C. Цель — не получить немедленное одобрение, а начать формальный процесс стандартизации. Это даёт несколько преимуществ: публичное review от экспертов по протоколам, защита от захвата одним вендором (если FSS — стандарт, любой может имплементировать), фундамент для долгосрочной устойчивости.

Выбор между IETF и W3C: IETF больше подходит для сетевых протоколов (как HTTPS, DNS), W3C — для веб-стандартов (как HTML, RDF). FSS — гибрид: сетевой протокол, но с веб-семантикой. Возможно, начать с W3C Community Group, потом подать в IETF как Individual Submission. Решение принимается в начале фазы 4 совместно с Foundation.

10+ сторонних имплементаций

К концу фазы 4 протокол должен иметь 10+ сторонних имплементаций на разных языках. Это и метрика зрелости протокола, и условие его живучести: если reference-имплементация прекращает развитие, другие продолжают. Целевые языки: Rust (для production), Go (для серверов), JavaScript (для браузера), Elixir (для real-time), Swift (для iOS), Kotlin (для Android).

Стимулирование сторонних имплементаций: гранты на имплементацию (через Foundation), хакатоны с призами, публичные тестовые серверы для проверки совместимости, «совместимые с FSS» бейдж для репозиториев. Цель — чтобы любой разработчик мог за неделю написать базовую имплементацию на своём любимом языке.

FSS Foundation

К фазе 4 проект перерастает формат «команды разработчиков» и требует формальной структуры для управления IP, торговыми марками, пожертвованиями, грантами. FSS Foundation — это non-profit организация (по образцу Linux Foundation, Eclipse Foundation, Software Freedom Conservancy), которая владеет торговой маркой FSS, управляет пожертвованиями, выдаёт гранты на разработку, защищает проект от юридических угроз.

Выбор юрисдикции: ЕС (NLnet, Software Freedom Conservancy Europe) или США (Software Freedom Conservancy, Open Source Collective). Предпочтение — ЕС, потому что философия проекта ближе к европейскому open-source (NLnet уже финансировал похожие проекты через NGI Zero). Решение принимается в начале фазы 4.

Долгосрочное финансирование

Модель финансирования — сочетание нескольких источников. Гранты: NLnet, NGI Zero, Mozilla MOSS, Sovereign Tech Fund (Германия). Пожертвования: Open Collective / GitHub Sponsors, индивидуальные и корпоративные. Контракты на поддержку: организации, использующие FSS в production, платят за приоритетную поддержку и консультации. Курсы и сертификация: платные курсы для разработчиков и администраторов (опционально, не основной источник).

Целевой годовой бюджет Foundation — $300-500k, что покрывает 3-4 full-time разработчиков + операционные расходы. Это скромно по сравнению с коммерческими стартапами, но достаточно для sustained open-source разработки. Бюджет публикуется публично, отчёты — ежеквартально.

Что после фазы 4

Фаза 4 — формальное завершение «стартап-фазы» проекта. После неё нет жёсткого плана: развитие идёт через Foundation, RFC-процесс и сообщество. Возможные направления: улучшение производительности для больших графов, интеграция с enterprise-системами, поддержка новых типов данных (медиа, time-series), расширение на мобильные и embedded-сценарии. Решения принимаются через governance-процесс Foundation, а не core-командой.

Главный показатель успеха — проект продолжает жить без оригинальной core-команды. Если Foundation, RFC-процесс и сообщество достаточно сильны, чтобы развивать FSS после ухода основателей, миссия выполнена. Это и есть настоящее определение «открытого стандарта» — не лицензия, а устойчивость.

Риски фазы 4

Четыре риска. Приложение не набирает аудиторию: если 1000 узлов не достигается, проект остаётся нишевым. Смягчение: активный outreach, партнёрства с PKM-сообществами, бесплатное приложение с premium-фичами (но не SaaS). RFC-процесс затягивается: IETF может рассматривать драфт годами. Смягчение: параллельно развиваем Community Spec (как ActivityPub сделал изначально), формальный RFC — long-term цель. Foundation бюрократизируется: вместо поддержки разработчиков занимается governance-войнами. Смягчение: явные bye-laws с минимизацией власти board, maximum 2 срока для любого должностного лица. Форк проекта: кто-то форкает FSS и пытается увести сообщество. Смягчение: это нормально для open-source, лучшая защита — качество reference-имплементации и активное сообщество.

← Назад к фазе 3 · Назад к обзору плана