Jellyfin loses three core maintainers in a week and renumbers its releases
Within a single week, Jellyfin saw three of its most experienced maintainers leave, including long-time project leader Joshua Boniface, who stepped down citing burnout. The project then settled a long-running versioning question and will jump straight to 12.0 — here is what that means for your server.
August 2026. The most widely installed self-hosted media library in the world is going through a governance shake-up. Within a few days, Jellyfin saw three of its founding figures leave: project leader Joshua Boniface, co-founder Andrew Rabert, and administrative pillar Anthony Lavado. In the same breath, the project settled a long-running versioning question and announced the next major release will jump straight to 12.0.
The code itself is not in danger: your server will keep transcoding on Monday. But the episode says something deeper about the maintenance model of self-hosting, and it is worth looking at without either alarmism or naivety.
Three departures, three different reasons
On July 17, 2026, Andrew Rabert, one of the very first contributors, resigned. He had been building a new desktop client meant to fix the limitations of Jellyfin Media Player — HDR support, maintenance. The disagreements were over development approach, including pushback against his use of AI-assisted tooling. His application left the official project and became Jellium Desktop.
Two days later, on July 19, Joshua Boniface announced he was stepping down as project leader, a role he had held since the project began in 2018 as a fully open fork of Emby. The reason fits in one word: burnout. “I simply could no longer provide the effort (mental or time-wise) that the role demanded,” he wrote, pointing to risks to his mental health.
The same day, Anthony Lavado, the pillar of operations — app stores, outreach, releases, finances — announced his departure for personal reasons, committing to support the transition for as long as needed, “even if it takes a year.”
What came before: a signal already visible in May
These departures did not come from nowhere. The team’s “State of the Fin” post back in May 2026 already flagged burnout as a growing problem and named one specific cause: the flood of AI-generated pull requests that added review load without adding much value.
That is the crux of it. Jellyfin counts millions of users, but its maintenance rests on a handful of volunteers. When a tool becomes as central as the family media library, it is easy to forget there is no contract, no SLA, and no paid support team behind it — only people who can, one day, run out of energy.
A fork that became the reference
To grasp what three departures mean, you have to recall the trajectory. Jellyfin was born in late 2018 as a fork of Emby, when the latter began closing its code and moving to a paid model. Boniface said he initially expected a few hundred users. Seven and a half years later, the software is used by millions.
That gap is exactly what makes the current episode delicate: the user base grew far faster than the maintainer base. A community fork that gains millions of users without gaining contributors in proportion ends up concentrating knowledge and workload on a handful of people. Three of them have just stepped back — the problem is not their departure, it is the structure that made them irreplaceable.
The renumbering: the 10. prefix goes, 12.0 arrives
Amid the shake-up, the project settled a versioning question that had dragged on for years. 10.11.x will be the last branch of the old scheme. The next major release skips straight to 12.0, with release candidates already out.
The logic is sound: the permanent 10. prefix was reserving space for a major API break that never comes, and users kept misreading what counted as a major release. From now on the first digit means significant changes, the second means bug and security fixes. A version number that never changes is documentation that lies — now fixed.
The practical warning is for anyone automating: any rule pinned to 10.* stops matching once 12.0 ships. Check your Watchtower rules and Compose tags now, not during an upgrade.
What it changes for your server
In the immediate term, almost nothing. Jellyfin keeps running, the repositories are not abandoned, and a broad group of contributors — many with years of experience — maintains the project. Both departing members are helping transfer their responsibilities. Releases keep shipping, and the 12.0 release candidates are the proof that development is moving rather than stalling.
But the real risk is not the code: it is institutional knowledge. Three people who held a large share of the project’s memory just left. The succession — who picks up Boniface’s role, held for seven and a half years — will say more about the project’s next two years than any release note.
Two signals are worth watching over the coming weeks: whether the 12.0 release candidates land on schedule, and whether the project names a successor who can absorb the roles Boniface and Lavado held between them — releases, finances, and store operations. A quiet, orderly succession would say more about Jellyfin’s next two years than any changelog.
The answer is not to run back to Plex. It comes down to two reflexes: keep your library metadata portable and your configuration under version control, so your data is never held hostage by the project, whatever shape it takes in two years.
The practical checklist
In concrete terms, for a Jellyfin server you run, four reflexes neutralize most of the risk:
- Keep metadata portable — enable .nfo files next to your media rather than trusting everything to the internal database;
- Version your configuration — the
docker-compose.ymlor systemd units in a Git repo, so the server can be rebuilt identically; - Pin a major version —
jellyfin/jellyfin:10.11today, to be reconsidered for12once it goes stable; - Keep Watchtower cautious — never
:latestwithout reading the release notes.
None of these protect you from the project’s governance, but they guarantee one thing: your data will never be hostage to whatever shape Jellyfin takes in two years.
Verdict
The Jellyfin episode is the visible case of a broader trend, not an exception. The flood of AI-generated PRs has become a real operational burden on volunteer projects, and it surfaces as burnout in the people who review them.
If you use Jellyfin, do not panic: your server keeps working, and the project is not dead. But do not treat this dependency like a commercial subscription.
Check your version pins now: any automation pinned to 10.* needs rethinking before 12.0, and pointing Watchtower at :latest remains bad advice on an application that accepts schema changes with every major release.
And if Jellyfin genuinely matters to you, the useful response is not anxiety: it is contributing — time or money — to the projects you depend on. Self-hosting does not survive on the magic of millions of users; it survives on the few people who review pull requests in the evening. Three of them just stepped away. Whether that becomes a cautionary tale or just a rough quarter depends on how many others step forward — and on whether the users who depend on the project finally treat it as something worth sustaining.