An Open Door, Not a Pitch

In the last post I left a sentence hanging on purpose: durability is a design question, and it matters who’s actually asking it. Here’s the honest version of why, and here’s where this whole run of posts actually lands.

The Thread So Far

Four posts back, I wrote about weighing up stepping back from Flickr, with no relief anywhere in it, because what mattered there was never really the company. Then about who I actually think this is for, people documenting a subject, a family, or their own past, using a photograph to hold onto something real, not to make it look better. Then where that actually happens, mostly a phone in the field, sometimes a desk with a scanner, same tool either way. And last time, what outliving actually takes, first at the scale of one person, where 82% of Flickr’s own members had thought about their legacy and only 12% had acted on it, then at the scale of a whole community, where I sat with the fact that even a well-resourced nonprofit built specifically for this problem still ran out of runway doing it properly.

That’s grief, audience, tool, and legacy, personal and shared both, in that order, because that’s honestly the order I worked through it in.

A Fact That’s True Today, Not a Promise

Here’s the thing I’ve been saving for the end, because it only means anything once the rest of this is on the record. FediFlick, the posting app I’ve actually built and shipped, already treats Flickr as a fully equal destination alongside Mastodon, Bluesky, Pixelfed, and Nostr. One composer, one photo, and it can go to all five at once if you want it to. Nobody using it has to leave Flickr to use it. That makes Flickr, from this project’s own architecture outward, a second source, not a thing to migrate away from. That’s not a plan for later. It’s what the app does right now, today, and has since before I started writing any of this series.

Not Asking Anyone to Change Anything

I want to be precise about what I’m not saying, because it would be easy to read the last four posts as building toward “Flickr should open itself up” or “SmugMug should hand something over.” That’s not it. I’m not asking Flickr or SmugMug to change a single thing about the product they run, and if the Content Mobility section of the last post read as a complaint about their choices, that wasn’t the intent, they’re allowed to make funding calls about their own programs. What I’m building is a separate thing entirely: a small, open-source, AGPL-licensed project, for a specific audience I’ve now spent three posts describing carefully rather than vaguely, that happens to sit close to a mission Flickr Foundation has already shown, in its own research and its own now-sunset program, that it cares about.

The Licence Is the Point, Not a Formality

What “open-source, AGPL-licensed” actually buys here is specific, and the phrase gets used loosely enough elsewhere that the specifics matter. GPL, the licence AGPL extends, was itself a legal hack: Richard Stallman using copyright’s own mechanism to protect the right to share rather than restrict it, a move I’ve written about at more length elsewhere https://gaggl.com/blogs/2026-07-14-what-the-commons-built/. AGPL adds the one clause plain GPL doesn’t have: a network-use trigger, so running modified code as a hosted service carries the same sharing obligation as actually distributing a copy would. That’s not a small technicality. Google’s own open-source policy states that AGPL code “MUST NOT be used at Google,” an outright ban rather than a case-by-case review, specifically because it could force parts of Search or Gmail open. A company that size building policy specifically around avoiding one licence is a fairly direct answer to whether the network-use clause actually does anything.

For FediFlick Archive, that means whoever eventually runs a hosted instance, including a possible future paid managed-hosting tier, has to keep sharing their modifications back. Nobody gets to take community-funded work, wrap it in a nicer interface, and sell it back as a closed competitor. That’s the structural version of “commons, not extraction,” not a slogan on a landing page, and it’s also, not coincidentally, exactly the kind of durable commitment an organisation built around digital permanence would want to see before backing anything.

The Open-Source Reflex Hasn’t Fully Left

There’s a shared history under this door. For years Flickr the company wrote about its own systems in the open and shipped its API clients on GitHub for anyone building on top of it. Not a Good Riddance Post tracked how quiet both have since gone: the engineering blog last posted in 2022, the SDK last took a commit in 2025. From outside, the reflex looks switched off.

I don’t think it is, and the reason is the Foundation. Flickr Commons, Data Lifeboat, Flickypedia: every one is built the collaborative way, public-domain material described by the crowd, a portable format anyone can read, a bridge into Wikimedia rather than a wall around Flickr. That is open source used as a way to build a community, not a thing you give away by opening it. None of this is a second ask hiding behind the first. It’s just the reason a conversation between a small AGPL project and the Foundation carrying Flickr’s name might start with more common ground than pitch language usually allows for. The hope, and it is only that, is that the instinct is still somewhere in the building, and that the Foundation is where it shows.

An Open Door

So: if anyone at Flickr Foundation reads this and it resonates, I’d genuinely like to talk. Not for funding, not for an endorsement, just a conversation between people who seem to have landed on the same problem from different directions. You’re on Bluesky at @flickrfdn.bsky.social, and on Mastodon too. I’m reachable in all the same places FediFlick already posts to.

If a conversation like that ever does turn into something that needs real funding, for the record, it won’t be a mystery how that would work. OpenCollective, a public ledger anyone can check, is the mechanism this whole project already leans on: no cap table to hide, no term sheet, just a running total of who gave what and where it went. A visible ledger doesn’t by itself fix the deeper problem I’ve written about before, that open-source funding has a long history of assuming unpaid labour is fine because reputation is its own reward, which quietly excludes anyone who can’t afford to work for free https://gaggl.com/blogs/2026-07-28-the-commons-has-no-ledger-for-this/, but it’s at least the honest version of that problem, argued about in public, rather than a hidden one. None of this is part of the ask above, it’s not on the table today, I mention it only so the option is on the record rather than something to explain later if it ever comes up.

That’s it. That’s the whole ask, if you can even call it one. The door’s open. No pressure on the other side of it.

Sources

• FediFlick project documentation (README.md), for the shipped, five-platform, Flickr-inclusive posting flow described above.
• Flickr Foundation on Bluesky.
• Google, AGPL Policy, opensource.google, for the “MUST NOT be used at Google” AGPL ban cited above.
• What the Commons Built, on the GPL as a legal hack and AGPL’s network-use clause as the fix for cloud-based enclosure.
• The Commons Has No Ledger for This, on why unpaid-labour funding models quietly exclude anyone who can’t afford to work for reputation alone.

Part five of five in the FediFlick & Digital Commons series. Previously: Archives That Outlive Their Contributors.

• FediFlick
• Flickr Foundation
• Digital Commons
• Digital Legacy
• Creative Commons
• Photography
• Open Source