Roadmap¶

This page says what we are doing next and what we have decided against. What works today is the companion page: it describes the present; this one describes the intent.

Nothing here has a date. The project is small; the things at the top are the things being worked on.

Now: the first installs¶

Nothing in the build stands in the way any more. The payload origin is up, both Flatpak bundles are published, the wheel is on PyPI, and one command installs it on each platform. People are the missing piece: Libera Suite has not yet been installed by anyone outside the project, on their own machine, against their own documents.

That is the next piece of work, and none of it is engineering. The first few real installs will find things no amount of testing here would, because every check in this repository runs on a machine that built the thing.

Installing the payload without a terminal is what used to be here. Every channel that can ship the editors now does: the Flatpak has them inside it, and curl … | sh fetches them without the user naming a directory. The one channel that cannot is PyPI, whose users are at a prompt already. A window that offers to download still has a place as a fallback, though it gates nothing.

Next¶

Signing and notarisation on macOS. Everything is already ad-hoc signed, because Apple Silicon refuses to run a binary with no signature at all and the toolchain applies one for free. The absence of a Developer ID therefore does not stop Libera Suite running. It leaves Gatekeeper's quarantine prompt in the way, which on macOS 15 and later right-click ▸ Open no longer dismisses. That is a poor first five minutes.

A .flatpakref. Both bundles are built, hosted and installable today, and a document converts inside the sandbox on each. The one-URL install is still missing: a .flatpakref on a server, and Flathub after that.

Windows, after the first installer. 0.3.0 ships a Windows installer, for x64. Three things are missing. The installer is not code-signed, so SmartScreen warns about the download. Windows on ARM runs the x64 build under emulation, as there is no native one. And the payload origin holds no Windows core, so pip install libera on Windows has no editors to fetch; the installer brings its own.

Keyboard shortcuts on Linux and Windows. The menu bar is there and every item on it works. None of them has a key equivalent. On Linux that is because pywebview's GTK menu has none: giving the bar shortcuts means reaching past it to Gtk.Application.set_accels_for_action, and then deciding which keys the page has to stop handling. What the same keys do on Windows has not been measured yet.

An update path. Nothing tells a tester that a newer version exists. Saying so in the release notes is enough for a beta. A version check that mentions it once is better. Automatic updates are their own project.

A redistributable application bundle. Libera.app today is a launcher around the interpreter it was built with. It embeds no Python and no payload, so it runs from your own checkout and is not something you can hand to somebody else.

Later¶

Tabs. One window per document today. Windows exist and the Window menu lists them; merging them into one needs real support: newWindowForTab:, and moving a document between windows. Turning the tab bar back on does not do it.

File locking. Two copies of Libera Suite editing the same document will not notice each other, losing one set of changes.

Editing PDFs and diagrams. The payload contains an editor for PDF that nothing routes to yet. Diagrams opens .vsdx and shows it; the converter refuses every Visio output format, so there is nothing to save and no blank to start from. Both are upstream capabilities we have not wired up.

Password-protected documents, digital signatures, mail merge. Upstream features, none of them reachable today.

Your name in documents. Tracked changes and comments are attributed to your account's full name, which you cannot yet change.

Personal dictionaries. Add to dictionary does not persist, so a word you add comes back next session.

More fonts, particularly CJK. The shipped set is 7 MB and renders ordinary documents faithfully; the full set is 248 MB. Where the line goes is an open decision, with CJK the case that most obviously argues for moving it.

In-application help. Upstream ships a manual, but it documents ONLYOFFICE and weighs 84 MB in eight languages, so Libera Suite does not ship it. Help comes back when there is documentation of our own to point at; these pages are the substitute.

Not now¶

These are outside the current product. Each could arrive one day, in the shape described here. None is being worked on.

Collaboration, cloud storage, accounts. Libera Suite edits files on your disk. The engine underneath it is collaborative-first with that switched off. Some form of shared editing may come back, as a mode or as a product of its own. Nothing in the local application waits on it.

Telemetry, analytics, crash reporting. There is none today. The beta adds none. Anything of the kind would be opt-in and off until you turn it on. What leaves your machine would list it beside everything else the application does on the network.

Changing the document engine. Not something we do today. The patch queue is 37 patches across three repositories. Twenty-one make it build on macOS and eight on Windows. Seven more are configuration, branding and build fixes, and one fixes an upstream UI bug. None touches the editing engine (see the patch queue). That is what keeps a pin bump a rebase of build configuration. It is a discipline, so if we ever do need the engine to behave differently, the change goes in the same way: one reviewable patch, offered upstream first.

How to influence this¶

The most useful thing you can send is a document that renders wrongly, attached. The layout engine is upstream's and mature, so where output is wrong it is far more likely to be our packaging than the engine: a missing font, a missing resource. Those are quick to fix and invisible to us until somebody sends one. Feedback says where to send it.