Harbor Dock
July 27, 2026

Jellyfin lost three maintainers in a week. Your files should not care.

An open-source license gives you the right to fork an abandoned project. It does not hand you anyone to do the forking. The questions that decide how much a maintainer's bad year costs you are how long your setup can safely stand still, and whether a stranger could find your files with none of your software installed.

In the third week of July 2026, Jellyfin's project leader Joshua Boniface and long-time core team member Anthony Lavado both stepped down, effective July 19. Co-founder Andrew Rabert had left the organization two days earlier. The stated reasons were ordinary and human: burnout, personal circumstances, and a disagreement about development practice. Boniface said the project remains in capable hands, nothing suggests the repositories are being abandoned, and the software runs exactly as it did the week before. Still, for a household that has moved its films or photos onto a self-hosted stack, the week points at a risk the license on the code does not cover.

A license is a right, not a workforce

Jellyfin is GPL-2.0, and that license is doing real work. Anyone can read, build, audit, and fork it, and nobody can take that away retroactively. It is why a governance shock at the top of an open-source project is a different event from a vendor switching your paid-for software to read-only.

What a license cannot do is supply people. The right to fork is a legal permission, not a staffing plan. Forking a media server means somebody has to triage the issues, ship the security patches, keep the mobile clients in step with two app stores, and answer the forum on a Tuesday night. All of that is permitted by GPL-2.0. None of it is promised by GPL-2.0.

This is the failure mode household open source actually has, and it is not the one people brace for. Proprietary software tends to fail loudly, on a date, with an email. Open source fails quietly. Nobody sends a notice. The release cadence stretches, the issue tracker grows, and one day the thing you depend on has been standing still for a year without your noticing, because it kept working. Neither model is safer in general. They fail on different schedules and give different amounts of warning.

The useful question is how long it can stand still

"Unmaintained" is not a single severity, and that is the part this conversation skips. What an abandoned program costs you depends on how much of the outside world it has to keep up with. Some software has a moving contract with things it does not control. Anything reachable from the public internet is on the security treadmill: unpatched means exploitable, on a clock set by strangers. Anything that talks to a third-party API is one deprecation away from breaking. For software like that, unmaintained turns dangerous in months.

Other software has almost no contract with anyone. A program that reads a directory on a disk and shows it to you over your own private network is not negotiating with a platform. Its dependencies are a filesystem and a browser. Frozen at today's version on a network that is not exposed to the internet, it can be fine for years. Not forever, but the decay is slow and visible when it comes.

So the practical exercise is to give each piece of your stack a number: how long could it go without a single update before that became a problem? Weeks, months, or years. That number, not the license and not the star count, is your real exposure to somebody else's burnout. The internet-facing pieces earn the vigilance. The quiet file server in the cupboard mostly does not.

Could a stranger find the files without the software?

The second question is about layout, and it decides whether a project's bad month is an inconvenience or an emergency. Some software sits beside your files. It scans folders you arranged, and everything it adds is derived: an index, artwork, watch history, thumbnails, all held in its own database. Take the program away and the folders are untouched. Jellyfin works this way, which is worth saying plainly in a week when it is easy to be uncharitable. The film is an ordinary video file in an ordinary folder, and it plays in VLC on a laptop that has never heard of Jellyfin. Losing Jellyfin would cost you the interface, the posters, and where you were up to in season three. It would not cost you the season.

Other software sits under your files. The bytes go into a database, a chunked object store, or a folder tree whose names only make sense to the program that wrote them. That design usually buys something real, like deduplication or encryption at rest. It also means the software is not optional. If it stops, you do not have files, you have a restore job that needs a working copy of a program nobody is maintaining.

The test takes ten minutes. Plug the drive into a computer with none of your software installed and open the file manager. If you can find last summer's photos by clicking through folders, then the maintainers of everything above that layer can have as bad a year as they need to. If you cannot, you have a dependency, and it is worth knowing its export path before you need it. Photo libraries are where this bites hardest: the images are nearly always plain JPEGs, but albums, faces, and tags often live only inside the app's database, so the pictures surviving is not the same as the library surviving.

The honest tradeoffs

Plain files cost you features, and pretending otherwise would be dishonest. Fast search, deduplication, and resume-where-you-left-off live in an index, and an index is one more piece of software you depend on. The answer is not to refuse databases. It is to keep them derived, so anything that matters can be rebuilt from the files rather than the other way round.

Standing still is only safe under conditions, too. Freezing an internet-facing service is not opting out of maintenance, it is opting out of patches while keeping the exposure. And self-hosting moves maintenance risk rather than removing it: the person who has to notice the failing drive is now the one reading this.

Harbor Dock is subject to every word of the above. It has maintainers, they are people, and people leave. Its source is committed to opening and has not opened yet, so today its license is a promise rather than something anyone can check. Which is why the claim worth making is not about the company: the dock writes ordinary files to an ordinary filesystem on a USB drive you own. Pull the drive, plug it into any computer, and the folders are there with no Harbor software in the path. That survives its own maintainers walking out, which is the only kind of answer this question has.

Want a private cloud that does not phone home?

Reserve a Harbor Dock. No charge today, no spam, no surprises.

Reserve now