Rationale for building new project rather than collaborating with existing OSS note-tools

[theopaolo]

Salut, l'équipe de docs !

I’m a front-end dev/designer working on accessible, neurodivergent-friendly digital tools, and I’ve been exploring the Docs project. Great work, very interesting capabilities and strong alignment with open-source and self-host-friendly values.

I’m curious about the project’s strategic decision to build a new collaborative editor rather than collaborate with or adapt existing open-source note/wiki tools (e.g. AppFlowy, Logseq, Affine, Anytype, etc.).

Questions

1. Was there a formal evaluation of existing OSS tools, and if so, what were the major gaps or constraints (technical, licensing, governance, scalability, sovereignty) that justified starting a new project?
2. In the future, is there a pathway or interest in merging modules, contributions, or interoperability with existing OSS ecosystems to avoid duplication of effort?
3. For context, what are the unique requirements (public-sector scale, identity/ODA, offline + sync, granular access control, compliance) that were found missing in other tools?

Technical stack & sovereignty
I also noticed that the current stack uses Next.js, Yjs, and BlockNote.js, all excellent technologies, but primarily U.S. led ecosystems.

Given that Docs is part of La Suite Numérique and aims to promote digital sovereignty, could you share the reasoning behind these choices (e.g. maturity, maintainability, accessibility, ecosystem support)?

For example, was a comparison made with lighter or more European alternatives such as Nuxt, SvelteKit, or even web-native options like Web Components, which might align more closely with goals of sustainability, simplicity, and autonomy?

Having a short “Technical Rationale” or “Architecture Decisions” section in the documentation could be very valuable, both for transparency and to inspire other public actors who wish to adopt or build on similar principles.

From a contributor/community perspective, understanding these choices helps newcomers decide whether to contribute directly, build adjacent tools, or explore interoperability.

Thanks for your work and openness, happy to contribute or help document these topics if useful.

Théo G.