Open Editor Platform: research and implementation plan

Scope. Software developers and book authors are equal priorities from the first release; web applications first, desktop and mobile afterward. Technology descriptions below link to primary sources. Architecture, targets, staffing and schedules are recommendations, not measured results or vendor commitments.

"Most powerful" should mean a published combination of capability, correctness, responsiveness, accessibility, interoperability and integration quality. No engine is best at every workload. Establish separate profiles and disclose their performance limits.

01What already exists and how to use it

Current maintenance nuance: CodeMirror and ProseMirror's archived GitHub repositories point to a move to code.haverbeke.berlin. The archive flags alone do not indicate abandonment. Follow the upstream locations and released packages. CodeMirror notice, ProseMirror notice.

02The product we should own

The SDK has three layers: minimal editing surfaces; optional capability packages; ready-made developer and author workspaces. Host products can adopt any layer. A customer embedding a code field should not download manuscript formatting and export features. A writing app should not load programming-language servers.

Treat a code workspace, a novel manuscript and a technical book containing code blocks as the three reference applications. Recruit at least two integration partners from each main audience; validate real author and developer tasks as well as SDK adoption.

03Recommended stack and responsibilities

Yjs's CodeMirror binding currently recommends stable Yjs v13 with y-codemirror.next while the next major integration remains unstable. Pin and test a compatible dependency set at implementation time. Hocuspocus is available under MIT. Binding guidance, Hocuspocus OSS status.

Lezer supplies syntax parsing within CodeMirror. LSP supplies semantic language services. Tree-sitter is an optional incremental parser for specific language coverage or structural features; avoid paying for two parsers for the same task without evidence. Language servers may run in a browser worker when compatible, a host process, or an isolated remote service. A browser cannot launch arbitrary native language servers. Lezer, LSP, Tree-sitter.

Rust is a later optimization tool, not a prerequisite for an advanced editor. A second mandatory text buffer would create synchronization, position mapping, undo and input complexity. Preserve the engines' proven editing paths until profiling identifies a specific replacement worth making. Likewise, WebAssembly does not supply native selection, input methods or accessibility. Tauri uses system WebViews; true native widgets would be a separate development track. Tauri architecture overview.

04Architecture contracts

Keep source text and structured documents as distinct models. Source files preserve text and supported encoding and line-ending metadata. Manuscripts use a versioned schema for paragraphs, headings, lists, footnotes, media and extensions. Share commands, lifecycle, identifiers, themes, permissions hooks, review metadata and persistence contracts. Engine-specific capabilities remain available through explicit extension interfaces rather than being flattened into a restrictive common API.

A book should be a manifest with stable chapter IDs, ordering, metadata and chapter documents. Load the active chapter and necessary neighbors. Search, counts, named versions and exports still operate across the complete manuscript. Capture a consistent set of chapter revisions for each book snapshot or export. Chapter moves and deletion must preserve or explicitly orphan references and comments. Specify recoverable operations for changes spanning multiple chapter documents.

Each document has one authoritative editing path. When collaboration is enabled, engine bindings project shared state and collaboration-aware undo owns undo behavior. Preserve collaboration state for continued synchronization; portable JSON and text snapshots serve export and recovery purposes. Do not repeatedly re-create the collaborative document from snapshots during normal edits.

Comments need stable anchors with explicit behavior when their target is deleted. Schema versions must be negotiated before clients collaborate; incompatible clients must upgrade or open read-only. Tiptap documents the risk of older schemas removing unfamiliar content. Schema compatibility guidance, Yjs anchors.

For mixed documents, embed CodeMirror in a ProseMirror node view with explicit selection and history bridging. An official example already demonstrates this pattern. Markdown source and manuscript JSON must never be independently editable sources of truth for the same document; conversion requires a declared supported subset. Embedded editor example.

05What "easy to integrate" must mean

• A plain JavaScript developer can embed either profile in under 15 minutes using the quickstart.
• Editing works without an account or mandatory backend. Hosts choose local storage, their own backend, or the reference collaboration service.
• Imports do not assume a browser exists; views mount client-side. Worker, style and language assets have documented loading paths that work with common bundlers and content-security policies.
• Small packages load only selected capabilities. Every instance supports disposal, cancellation and predictable resource cleanup.
• Hosts control themes, keyboard shortcuts, accessibility labels, focus, file access, authentication, telemetry and network providers.
• Stable public APIs use semantic versioning, migration guides and a tested support matrix. Keep engine-native escape hatches explicitly outside the portable API guarantees.
• Web Components are a packaging option; iframe embedding is an optional isolation route. Test focus, clipboard, composition and accessibility for each supported route.

An illustrative target API, not an existing package:

const editor = createEditor({
  mount: element,
  profile: "manuscript", // or "code"
  document: initialDocument,
  extensions: [comments(), namedVersions()],
  storage: hostStorage,
});

editor.on("change", handleChange);
editor.execute("find", { query: "chapter" });
editor.destroy();

06Reuse versus build

Reuse the editing engines, their parsers, collaboration bindings, language servers, sanitization libraries, conversion primitives and browser-test infrastructure. Prefer upstream contributions over a permanent fork.

Build the SDK contracts, cross-profile review experience, book model, reliable persistence integration, portable schema, conversion mappings, capability registry, performance harness and documentation. Build or adopt independently licensed open-source comments, named versions, and later tracked changes. Tiptap's commercial platform is a useful feature reference, but its managed history and commercial advanced features are not free dependencies. OSS and platform distinction.

AI should be an optional provider interface supporting completion, explanation and proposed edits for both audiences. Proposals carry a document revision and target range, show a reviewable diff, and reject or rebase stale changes. Host applications choose model providers and decide what content can leave the device. Normal editing remains available without AI.

07Authoring and format fidelity

Launch with a written manuscript format contract: paragraphs, headings, emphasis, lists, links, images, simple tables, footnotes, chapter order and book metadata. Implement DOCX import and export for that subset and EPUB export with navigation and metadata. Offer plain text, HTML and a documented Markdown subset too. Keep the original imported file and report unsupported constructs.

Mammoth targets semantic DOCX-to-HTML conversion and explicitly does not reproduce all formatting; evaluate its output against our schema and sanitize it before insertion. The docx library can generate DOCX in JavaScript and TypeScript. Neither dependency gives us faithful round-tripping automatically. Mammoth, docx, DOMPurify.

Validate EPUB output using EPUBCheck and inspect it in representative readers. Keep print and export layout separate from the interactive editing layout. Full Word compatibility, arbitrary imported tracked changes and professional book pagination require additional dedicated work. EPUB format, EPUBCheck.

Comments, named snapshots, comparison and restoration are v1 review capabilities. Attributed tracked changes with accept and reject, formatting edits, collaboration and DOCX interoperability are a separate expansion milestone. This boundary must be visible in the roadmap and product claims.

08Release gates and benchmarks

These are proposed acceptance targets to calibrate during the prototype; none has been measured in this project.

Compare alternatives using the same documents, hardware, enabled features and cold and warm conditions. Publish raw results and regression thresholds. Automated browser checks complement manual input and accessibility tests. Playwright documentation.

Untrusted paste and import, shared documents and optional extensions require specific controls: schema validation, sanitization, document-level authorization on the service, resource limits, and isolated conversion jobs where appropriate. Workers protect responsiveness but are not by themselves a sandbox for malicious plugins. Start with trusted plugins; add a separately designed restricted plugin environment before an open marketplace.

09Delivery plan

Planning estimate: 9 to 12 months for a credible scoped web v1 with 8 to 10 experienced engineers, a designer and dedicated QA and accessibility support. This assumes mature engines, constrained format support and no custom renderer. Both audiences participate in every milestone. A three-month prototype is feasible under these assumptions; worldwide leadership is a multiyear maintenance and ecosystem effort.

Suggested engineering allocation at ten: two code and language engineers; three manuscript, schema and conversion engineers; two shared storage, collaboration and review engineers; one SDK and integration engineer; one performance and accessibility engineer; one test-infrastructure engineer. At eight, combine related roles and use the later end of the schedule. Keep design and independent QA involvement outside those allocations. Funding estimates should use local staffing costs; there is no reliable universal budget from the information supplied.

If fewer people are available, preserve both audience workflows and reduce the number of languages, formats and optional features. Keep recovery, input correctness and accessibility release gates intact.

10Open-source and maintenance plan

Recommend Apache-2.0 for new platform code, preserving all upstream license notices; its express contributor patent grant is useful for a reusable SDK. The exact dependency set still needs a per-package license review, including language servers, grammars, dictionaries, fonts and converters. Apache license.

Keep the editor, advanced capability packages we develop, document formats and the self-hosted reference service open source. Optional managed hosting, support and integration services can fund maintenance. Establish public design proposals, contribution rules, maintainer ownership, security reporting, reproducible releases, a compatibility policy and funding for important upstream projects.

11First-month work package

1. Write two acceptance scripts: integrate a developer workspace; integrate an author workspace and edit and export a chaptered manuscript.
2. Gather licensed or synthetic benchmark fixtures and representative partner documents.
3. Run the engine comparisons and the hardest input, collaboration and conversion experiments.
4. Define the public document, command, storage and extension contracts and draft the manuscript schema.
5. Publish measured results, a precise v1 feature list, staffing responsibilities and the first alpha backlog.

The first investment decision should follow that evidence. The recommended starting stack is TypeScript + CodeMirror 6 + Tiptap OSS/ProseMirror + Yjs, with a shared integration and review platform that gives developers and authors equal standing.