django-photologue: a photo gallery app that needs a new maintainer

The maintainer note is the most important line in the README

django-photologue is described as a customizable plug-in photo gallery management application for the Django web framework. The feature summary is brief: upload photos, group them into galleries, apply effects such as watermarks.

But the README opens with a project status section, and it is not boilerplate. The current maintainer writes that they no longer need django-photologue for their own projects, so they have stopped working on it, and that they will occasionally update it to run with current Django releases, but that is all. The note closes by saying any help in running the project is welcome.

Read carefully, that is a specific offer and a specific limit. Compatibility maintenance against new Django releases will happen. Feature work will not, unless someone else picks it up.

This is the situation that distinguishes a mature package from a neglected one, and it is worth seeing it as such. The library is on PyPI, it has a CI badge, a codecov badge, a ReadTheDocs documentation build, a changelog, a contributors file and a security policy. Those are the artefacts of a project that was maintained properly for a long time and then handed over, not of one that was abandoned.

The last push to the repository was on 2026-10-11, and the repository is not archived, so the occasional compatibility updates are real. The gap between a recent commit and a project with no feature roadmap is the thing to plan around.

The audience is a Django developer who needs a gallery this week, and who is either willing to take on the project or able to work around the parts that are frozen.

What the package actually gives you

The dependency list is short and tells you what the app is built on. It requires Django in the range 5.2 up to but not including 6.1, Pillow at 12.0.0 or newer, and django-sortedm2m at 4.0.0 or newer.

Pillow is the imaging layer, which is what makes the effects such as watermarks possible. django-sortedm2m handles many-to-many relations with an explicit ordering, which is the mechanism behind gallery membership and album ordering, where a plain many-to-many field would leave the order of photos inside a gallery undefined.

The Django version range is deliberately narrow, and that is worth noting. It is a modern app, not a legacy one that has been left to rot. The classifiers list Django 5.2 and Django 6.0 specifically, and Python 3.10 through 3.14, with the development status recorded as Production/Stable. Requiring Python 3.10 or newer is the other boundary, and it means the package will not install on an older interpreter at all.

The repository layout shows a full development setup rather than a single app module. The photologue directory is the application itself, the example_project directory is a working site, the docs directory is the documentation source, the scripts directory holds management commands, the release directory holds release tooling, and there is a tests directory alongside tox.ini, setup.cfg, dev-requirements.txt and a .coveragerc for coverage measurement. The .isort.cfg and .tx directories for translation files show that the app is prepared for translation.

The size of that scaffolding is itself information. This is a project with a test suite, a documentation build and a translation pipeline, which is exactly the kind of codebase a new maintainer can pick up.

Installation is documented on ReadTheDocs, not in the repository

There are no install commands in the repository README. The README points to the online documentation at ReadTheDocs for instructions on installing and configuring the application, and that is where a first-time user has to go.

That is normal for a Django reusable application rather than a sign of missing work, since a plug-in has to be added to an existing project's settings, installed as an app, and its migrations run, and the exact steps depend on the host project. The documentation build is configured in the repository through a .readthedocs.yml file, so the published docs are generated from the same tree.

The package itself is built with setuptools, requiring setuptools 77.0.3 or newer, with the version read dynamically from the photologue package's __version__ attribute rather than hardcoded. The packages found and included are photologue* and scripts*, and the package data is included with include-package-data set, which is what allows templates, static files and fixtures to travel with the distribution.

The README also points to a demo website and to a wiki page collecting examples of sites using Photologue, which is the fastest way to judge whether the feature set matches what you need. A gallery application looks simple in a screenshot and turns out to have opinions about sizing, cropping and ordering, and a live demo settles that faster than reading about it.

For support, the README points to a Google Groups mailing list, and that remains the place to take questions. A mailing list is a reasonable channel for a project of this size and age, and it also means the answers live in an archive you can search.

Amazon S3 storage works through the standard BOTO package

Storage is the one place where the README goes outside Django, and it does so in a way that keeps the choice open.

The README states that S3 also works with the standard BOTO package. That sentence is short but it is a real architectural decision. It means the app does not hardwire an AWS SDK and its own configuration format; it works with whatever BOTO-compatible interface the host project already has, so a project that already stores files in S3 through BOTO can point Photologue at the same bucket and credentials without introducing a second, conflicting storage stack.

For most self-hosted installations the default is the local filesystem, and S3 is the option you turn on when images need to live outside the application server. That ordering is the right default. A photo gallery that requires object storage before it will start is a bad first experience, and the fact that S3 is mentioned as a compatibility statement rather than a prerequisite supports that reading.

What the README does not document is the configuration keys for enabling it, the credential handling, or the URL generation for stored images. Those details are in the ReadTheDocs documentation, and they are the details to check before committing, since a gallery that stores images locally and one that stores them in S3 differ in more than a config flag, particularly around resize derivatives and the URLs the templates emit.

One caution: the S3 support statement is brief and undated relative to the rest of the the documentation, and BOTO has changed shape over the years. Treat it as something to verify against the current documentation rather than assume it works with the version of BOTO your project already has.

Where django-photologue is the wrong tool

The first wrong-tool case is a project that needs gallery features to evolve. A watermarked gallery with upload and grouping covers a lot of ground, but anything beyond it, a new filter, a different storage backend, a bulk import with mapping, a front end that is not Django templates, requires code changes. Since the maintainer has said feature work is stopped, those changes are yours to write, in a codebase you did not design.

The second is a team that cannot take on maintenance. This package is a functioning dependency with a narrow Django range and a Pillow floor that has moved up recently. Both of those will need attention over the life of a product, and the README's offer of occasional Django compatibility updates does not cover Pillow, the Python versions or anything else in the stack.

The third is a project with a modern gallery already in its stack, or a need that a hosted service or a static site generator handles better. If the requirement is a portfolio site rather than an application with an admin interface, a Django app with a database model per photo is the wrong shape.

The fourth is an image-heavy product with real processing requirements. The app applies effects such as watermarks through Pillow, but nothing in the README describes background processing, thumbnail queues, on-the-fly resizing or storage deduplication. The scope is upload, group, effect. A product that needs a media pipeline needs something else, and retrofitting it onto a plug-in whose feature work has stopped is a fight.

The fifth is anyone unwilling to read the documentation. That sounds harsh, but with no install commands in the repository and the substantive configuration living on ReadTheDocs, the documentation is a prerequisite rather than a convenience.

Assessing the risk of a package whose maintainer has stepped back

The honest way to evaluate this project is to separate what is genuinely finished from what is genuinely open.

What is finished: the packaging, the test suite with tox and coverage configuration, the documentation build, the translation setup, the security policy, the changelog and the contributor records. The example_project directory means a new contributor has a working site to run against, which is the single most useful thing in a repository like this.

What is open: everything that the last maintainer declined to do. Compatibility with Django releases as they arrive, since the maintainer has explicitly kept that promise. Dependency floors, since Pillow 12.0.0 and Django 6.1 are moving targets. And the security posture, given a SECURITY.md file exists in the repository, which means reports have somewhere to go.

The dates help. The last push was on 2026-10-11, and the repository is not archived, so the promise of occasional updates is being kept. A package whose last commit is months old and whose README says development has stopped would be a different assessment entirely, and one that would deserve more scepticism.

The repository also carries an AGENTS.md file at the root alongside the development configuration, which suggests the project has been set up for automated tooling contributions, and the presence of a security policy and a .coveragerc means the operational hygiene is in place. If your organisation needs a component with a named owner, the only realistic route is for someone in your organisation to become that owner, and the README asks for exactly that kind of help.

Editorial conclusion

django-photologue fits a Django team that needs a gallery with upload, grouping and watermarking now, and is prepared to own the code and the dependency upgrades going forward. It is the wrong choice for a product that needs new gallery features, for a team that cannot take over maintenance, and for a project whose other dependencies move faster than this one. Before adopting it, read the maintainer note at the top of the README, check that your Django version falls inside the declared range of 5.2 up to but not including 6.1, and read the online documentation on ReadTheDocs for the install steps, which are not in the repository.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. richardbarran/django-photologue on GitHub