Milestone 1 — Core System¶
Podlibre is funded by the NLnet Foundation and Ad Aures, across six milestones totalling 100 person-days. Milestone 1 is the foundation every later milestone plugs into: 26 person-days, covering the database, the core system, the plugin architecture, internationalisation, packaging for three platforms, and documentation.
What this version delivers¶
| Deliverable | What it means here |
|---|---|
| Database | One SQLite file per show, beside its audio, with the layered field model |
| Core system | The workflow engine, the command registry, the supervisor and its task registry |
| Plugin architecture | The out-of-process plugin API, its permissions, its surfaces, and a template to start from |
| Internationalisation | Six languages from gettext catalogues; plugins translated independently |
| Packaging | One file to download, no installer and no Python needed. Linux is built and verified; see below |
| Documentation | This site, written before the code |
Plus one plugin written end to end against the public API: RSS import. It is not in the original project description. It earns its place by proving the plugin API carries real work, and by letting a podcaster with an existing show be useful inside a minute.
Where packaging actually stands¶
The Linux binary is built and verified: a script checks the entry point, the plugin host, all six catalogues, both themes, the window icon, and that a show opened in it is still in the library after a restart — nineteen checks, run against the binary rather than the source.
macOS and Windows have their icons and a spec that selects the right one per platform, and neither has been built, because building each needs a machine of that kind or a continuous integration runner, and the project has neither yet. Saying they are done because the configuration exists would be the same mistake as shipping a hollow transcription engine. The work left is the build and whatever it uncovers, not the groundwork.
What it does not deliver¶
Transcription and language models have their permissions and their place in the workflow, and no implementation at all. A plugin asking for one is refused when it is installed, with a message naming what this build cannot provide — rather than installing and silently doing nothing, which is what a stub would mean in practice.
The engines arrive in Milestone 3 and after, where the project description funds them. Naming their seams now is what stops the architecture being rewritten to accommodate them later; writing hollow versions of them now would only be a way of appearing further along than we are.
The same applies to audio filters (Milestone 2), the editor's deeper features (Milestone 4), chapter and metadata editing (Milestone 5) and publishing (Milestone 6). Each is an activity the workflow already knows about, greyed until its plugin exists.
Decisions on the record¶
- Plugins run out of process and describe their interface. The brief requires that the window never hang and that plugins ask permission for what they touch; both follow from this, and so does a plugin API with no toolkit in it.
- A show is a folder with one database file, so it can be moved and copied.
- The model is data. iTunes tags, Podcasting 2.0 tags and plugin-invented fields are rows in one table, so adding one needs no release.
- The workflow is the centre, and the command palette is how everything is reached.
- PySide6 rather than PyQt6 — Qt under the LGPL rather than the GPL, which is the kinder licence for anything a community might later want to reuse.
- Completion is derived, never stored. Asking the data is slower than reading a flag and always true; a flag can lie after a file is deleted or a show is copied.
- The permission gate is a guardrail, not a sandbox. It stops accident and overreach, confines a crash, and lets the user kill a plugin. It does not stop a determined one: a plugin is Python running as you. Saying so plainly is part of the design.
- Previous technical choices may be reused; no code is. This branch shares no history with the earlier implementation.
- The tutorial is executed, not proof-read. The screencast script for writing a plugin is pulled apart by the test suite, which assembles the plugin it dictates and runs it. A script that would waste a recording session fails the build instead.