foss photo libraries: a generated table where a missing feature links to its issue

The page you read is generated from a template and a data file

The repository contains no hand-written comparison. The root holds a template, a JSON data file, a Python script and the page itself, plus a second script that tests the generator. In other words the table is a build product: the projects and their values live in the data file, the layout lives in the template, and the script renders one into the other. That is why the primary language here is Python even though nothing in the repository computes anything at runtime for a user. It also explains the shape of the page. Every criterion row links into a separate markdown file rather than expanding in place, so the table stays one screen wide and the detail lives elsewhere, and the criteria themselves are fixed:

Freeness
Automatic Mobile Upload
Web App
Android App
iOS App
Desktop App
LivePhotos
Videos

A test file sitting next to the generator is the quiet part. It means a change to the data or the template that breaks the render fails in continuous integration rather than shipping a mangled table.

Freeness is the one row where the table is almost unanimous

Most rows in this table are a spread. The freeness row is not. Fifteen of the seventeen columns carry a full score of ten out of ten, and the two that do not are the interesting ones. One sits at five, with a link to a write-up about that project going free, which reads as a date-stamped judgement rather than a permanent property. The other is marked as something that may exist but may not be practical or officially released, scored seven, and that project is the one with a commercial offering behind a free tier. The distinction the page draws between the two free-as-in-free-beer projects and the free-as-in-free-speech ones is stated in the introduction as a rule for submissions rather than as a scoring criterion, and it is also a workload statement: speech-free projects are welcome but are expected to need a pull request, because testing each project takes significant time. That single sentence explains a lot about how the rest of the table gets filled in.

Sixteen of seventeen projects have a demo you can click

The demo row is the cleanest signal of who is runnable by a stranger. One column is a plain negative, and it is the project with the highest subjective desktop score in the table. Every other project links to a live instance, and the scores on those links spread widely. Two sit at nine, two more at eight, and one sits at three despite having a demo at all, which is a reminder that the scale measures quality rather than existence. The one project with an instant trial rather than a public demo scores four. That pattern matters for anyone evaluating these projects: a demo link tells you an instance exists, and the number attached to it tells you how much the maintainer thought you would get out of it, which is a claim about the demo rather than about the software. The same distinction runs through the rest of the table, where a check mark means a feature exists at least in a limited fashion and a different mark means it may exist without being practical or officially released.

Mobile support is concentrated in three projects and one of them has no iOS app

Read the two app rows together and the field narrows sharply. On Android, the two projects that also top the demo scores are the ones with a first-class app, both at eight. Below them sit a project with a seven, several with fours and threes, and a cluster of plain negatives. Two entries are marked as possibly existing without being practical, one of them pointing at progressive web app documentation and the other at an upstream issue. On iOS the same two projects again score eight, and below them the spread is worse: one project scores four for iOS, one scores seven through the upstream project's mobile applications page, and two are marked as partial with links to their own issue trackers. The asymmetry worth noticing is Photonix, which has an Android score of four and an iOS score of nothing at all, and a desktop row that is a negative with an upstream issue attached. A project can be present on one mobile platform and absent from the other two without that being visible unless you read across.

Only four columns have anything at all in the desktop row

The desktop row is the sparsest in the table, and it is the one that most clearly separates photo libraries from photo servers. Four columns carry something. One has the highest single score anywhere in the table, a nine. Two more score eight. A pair of columns for two projects that share a desktop client are both marked as partial and both point at that client's repository, scored two, which is the honest reading since a desktop sync client is not the same thing as a desktop application. Everything else in that row is a plain negative, including the project whose own issue tracker is linked. Read together with the mobile rows, the shape of the field is a set of web applications with phone apps attached to some of them, and a small number of projects that also run on a computer. Anyone choosing on the basis of a desktop experience is choosing from four columns, and the table is honest about the other thirteen.

The negative cells carry the issue link, which is the most reusable part

The most valuable thing in this table is not a score, it is the convention for a negative cell. Where a feature is missing and the project tracks that gap in its own issue tracker, the cell links to the upstream issue rather than sitting empty. The pattern repeats across rows and columns: a mobile upload gap links to one project's issue, a missing mobile app links to another, a missing video feature links to a third, and separate issues cover desktop apps, live photos, video support and photo field capture in four more projects. That turns the table into a list of open questions with owners. It also means the table has a maintenance property worth knowing about: a cell that is a bare negative has no upstream to check, so it may be stale in a way a linked negative is not, and the repository's own freshness is bounded by its last push on 2026-04-18 rather than by anything in the projects it watches.

One demo cell runs two URLs together and the promised tooltips are not in the markup

Two details show the table is generated rather than curated by hand. The first is a single malformed cell. In the demo row, one project's cell contains two addresses run together, the project's own demo host followed immediately by a different project's demo path, cut off mid-word. A reader clicking that cell does not get a demo. The second is the legend. The instructions above the table say to hover over the symbols for additional information, with a link to a related issue or demo credentials among the things promised, but the cells themselves are ordinary markdown links around a symbol and a number, with no tooltip text anywhere in the source, so the extra detail the legend advertises is not in the markup a browser receives. The row anchors have a related smell, with one heading link written as a path containing a slash inside the fragment. None of this changes a single score, and all of it is the kind of thing a regeneration would fix.

Editorial conclusion

Use this as a map rather than a verdict. The columns are consistent, the negative cells point at the upstream tracking issues, and the criteria are the ones a self-hosted photo library is actually judged on, which makes it a fast way to see that most of these projects have no desktop app, that mobile support is concentrated in a handful, and that freeness is nearly universal. Do not treat the numbers as measurements. The quality figures are described on the page as subjective on a scale of zero to ten, they are assigned by one person, and the disclaimer says the owner reserves the right to change any pull request, so a score can move without a new release or a changelog entry. The repository has no releases and the default branch was last pushed on 2026-04-18. For a decision that matters, open the linked issue, read the project's own documentation, and treat the table as the list of questions worth asking.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. meichthys/foss_photo_libraries on GitHub
4. Project website
5. README