meichthys/foss_photo_libraries: A Comparison Table for Self-Hosted Photo Software
Free and Open Source Photo Libraries
At a glance
- What is it?
- This repository is not a photo library. It is a Python-rendered comparison of seventeen open source photo projects, and its value depends entirely on how you read the subjective scores it publishes alongside the objective ones.
- Who is it for?
- Adopt this repository as a shortlist generator, not as a verdict. If you are choosing between Immich, PhotoPrism, Lychee, Piwigo, Nextcloud Photos and the rest, the matrix narrows seventeen candidates to three or four in an afternoon.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 151 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the Repository Actually Is
The name suggests a photo library. The repository is a comparison document. Its stated aim is to track and compare the feature set between free and open source photo libraries, with a focus on gratis software, meaning free as in free beer. Libre projects are also welcome, but the README says they will likely need to be submitted via a pull request because the time spent testing each different project is significant. That sentence tells you the maintenance model: a single owner does the testing and merges contributions. The repository is written in Python, licensed MIT, and the homepage points at a GitHub Pages site generated from the same content. There are no releases retrieved, so the published matrix on the default branch is the artifact. The audience is narrow and specific: someone who has decided to self-host photo management and now has to pick from a field of seventeen projects, each with its own Docker compose file, database requirement and mobile app situation.
Reading the Comparison Matrix
The core of the project is a Markdown table with seventeen columns, one per project, and rows for features. The README names Chevereto, Damselfly, Ente, Foldergram, HomeGallery, Immich, Librephotos, Lychee, Nextcloud Photos, Nextcloud Memories, Photonix, Photofield, PiGallery2, Photoprism, Photoview, Piwigo and Snapcrescent. Cell values are symbols, not prose. A check mark means the feature exists in at least a limited fashion. A construction sign means the feature may exist but may not be practical or officially released. A cross means the feature does not yet exist. The distinct part is the hash symbol, which the README defines as a subjective measure of feature quality on a scale of 0 to 10. Hovering over the emoji reveals additional information, which the README describes as a link to a related issue or demo credentials. That hover layer is where the real evidence lives. The visible table is a summary; the tooltip is the citation. If you copy the table into a spreadsheet without the tooltips, you lose the part that can be checked.
The Subjective Score Is the Point and the Problem
Most comparison tables pretend to be neutral. This one does not. The README carries a disclaimer stating that the repository displays both objective and subjective measures of feature quality, and that the owner reserves the right to make changes to any pull request. A star count or a contributor count is objective in the sense that it is a number someone else computed. A 7 out of 10 for a feature is a judgement. The disclaimer is honest, and it is also a governance statement: contributors can propose, the owner decides. For a reader, that means the matrix is one person's working notes made public, not a consensus document. The practical consequence is that you should treat the numeric scores as a filter for further reading, not as a ranking. If Immich scores higher than PhotoPrism on a row, the useful next step is the linked issue in the tooltip, not the number itself.
How the Site Is Built and How to Run It
The primary language is Python and the homepage is a GitHub Pages site, which is the standard shape for a static generator that turns Markdown into HTML. The README does not document a build command, a requirements file or a Makefile in the material provided, so the exact invocation cannot be confirmed from what is available. What can be confirmed is the contribution path: the README states that Libre projects will likely need to be submitted via a pull request. That means the workflow is fork, edit the Markdown table, open a pull request, and wait for the owner to merge or amend. There is no plugin API, no database, no service to deploy. If you want to run the published site locally, you would need to inspect the repository for the generator configuration, because the README does not name it. That absence is worth noting: a project whose output is a table should document how the table becomes a page, and this one leaves that to the repository layout.
Where the Matrix Breaks Down
A symbol table compresses. That is its function and its failure mode. A check mark for a feature does not tell you whether the feature works at 50,000 photos or 500. The construction sign is even more ambiguous: may exist but may not be practical or officially released covers a wide range, from a merged pull request behind a flag to an abandoned branch. The subjective 0 to 10 score has no published rubric in the material provided, so two rows scored 8 and 6 cannot be compared arithmetically. There is also a staleness risk. The last push is dated 2026-04-18, which tells you the repository was touched recently, but individual cells can be older than that date because a single push can update one row. If you are choosing a library for a ten-year archive, a cell that was accurate eighteen months ago may not describe the current release. The matrix is a starting point for evaluation, not a substitute for installing the two or three candidates that survive the shortlist.
What to Compare It Against
The obvious alternative is the Awesome-selfhosted list, which catalogs self-hosted software by category and links to each project. The difference in approach is the unit of information. Awesome-selfhosted tells you a project exists and gives you a one-line description. This repository tells you, for a fixed set of seventeen projects, which features are present, partially present or absent, with a quality score attached. That is a denser artifact for a narrower question. The trade-off is maintenance: a link list survives a project going dormant because the link still resolves, while a feature matrix goes stale the moment a project ships a release that changes a cell. A second alternative is to read each project's own documentation and release notes, which is slower but authoritative. The matrix is useful precisely because it front-loads that work: it tells you which projects are worth reading about in detail.
Licence, Maintenance and the Cost of Trusting It
The repository is MIT licensed, which permits reuse and modification with attribution and without a copyleft obligation. That applies to the comparison document, not to the seventeen projects it describes, each of which carries its own licence that you must check separately before deployment. The maintenance cost here is low for a reader and non-trivial for a contributor. A reader pays nothing and gets a shortlist. A contributor who wants a Libre project added pays the cost the README names: the time to test that project, because the owner will not do it on your behalf. The owner's stated reservation of the right to change any pull request is the governance mechanism, and it means the matrix reflects one maintainer's judgement even after community input. For an engineering team, the honest framing is that this repository is a well-organized opinion with citations attached, and the citations are the part you should verify.
Editorial conclusion
Adopt this repository as a shortlist generator, not as a verdict. If you are choosing between Immich, PhotoPrism, Lychee, Piwigo, Nextcloud Photos and the rest, the matrix narrows seventeen candidates to three or four in an afternoon. Do not adopt it if you need per-feature evidence, because the README states the owner reserves the right to change any pull request and the quality scores are explicitly subjective. Before trusting a row, open the linked issue from the hover text, check the last commit date of the project you are considering, and confirm the feature against that project's own documentation rather than this table.
Community notes