I know this post is about Noodle, but I want to talk about Immich.
I believe I've spent, perhaps, the most time of anyone on earth on digital photo management (hard to quantify, but since 2005 - 2 startups, one acquisition, and an ongoing open source project used by thousands).
I say that because I've refused to settle for most solutions in this space. Even when I adopted using Google Photos, it was as a read only viewer of my canonical photo library (I wasn't about to let Google take that responsibility). I have such high demands of whatever software I use for managing my photos and videos - they're really the only digital files I actually care about.
Immich is absolutely wonderful. It may have some shortcomings ... like partner sharing and sharing facial recognition between users. But man is it remarkable that an open source project can rival something from Google in terms of quality and experience.
And a soft fork like Noodle is precisely the way to handle it. I am perfectly happy with Immich so am not a user of Noodle. But it's open source flexing its strength.
As someone looking to exfiltrate my photos from Google, I'm about to trial Immich, and I really appreciate you sharing your experience. Sounds like it's a good next step for me.
>But man is it remarkable that an open source project can rival something from Google in terms of quality and experience.
I'd argue Google is always way worse than the open source alternative in both quality and ux. Their products are terrible. From Gmail to Youtube, the product itself comes second (or Nth), while in open source the product is always first.
The submitted title’s framing “alternative to Google Photos and Immich” is dodgy because this is a soft fork of Immich, adding certain features, described in https://opennoodle.de/noodle-gallery-vs-immich/.
I don't know if I'm getting more sensitive to Claudisms because I've been reading them everywhere (and I use Claude a fair bit myself), but I feel like the comparison page is full of them.
Thank you for that -- the workaround for multiple users sharing a set of photos plus their own stuff is the one thing that's kept my family away from adopting it.
Was there a reason these features were not accepted to upstream Immich and needed to be in a fork?
Looking at the latest commits, Noodle Galery has many signed with Claude, but Immich doesn't. Is LLM policy a reason for fork? (Just speculating, I don't know.)
UPD: Immich has this in CONTRIBUTING.md, seems like its LLM policy is more strict:
> We ask you not to open PRs generated with an LLM.
vs. Noodle Galery:
> We actively encourage the use of LLMs and AI coding tools.
My only issue with Immich is the partner sharing and face recognition overhead per account. It is a massive oversight. Looks like Noodle Gallery explicitly solves this (and more). I'm sold.
EDIT: hmm after reviewing the repo, I'm going to wait a bit to see how this works out. There's a difference between LLM-assisted software development and blindly vibe-coding things without review and this seems a bit like the latter. I see no contributors and hundreds of commits in a very short amount of time. That's a red flag for now.
Hey, I'm the main contributor to this repo. I do review the code - the reason why all of the commits are shown in a short time is just because of the way that I rebase on upstream Immich.
I have been working on this project for 6 months, and (contrary to what the Immich team posts every single time my project is mentioned) I do not blindly vibe code - or are folks saying that blindly vibe coding 40+ working features while staying in sync with upstream over 6 months is possible?
I really enjoy working on this project and have been building everything that I felt missing in my setup. If you try it out and aren't happy with it, every release ships with a script that reverts your db to Immich, so you're never locked in.
Is it possible to integrate Noodle into iOS, i.e. upload new photos into noodle automatically, browse them on the iPhone and if I delete them on my iPhone sync this deletion to the server? AFAIK iOS discriminates against non-Apple apps and does not let them run background jobs.
Immich has an app that just needs to connect to an Immich server, which this would effectively be. It does the background sync, though I don't think it does the delete part.
The one caveat here is that, because Apple only really allows certain apps the privilege of running in the background without being interrupted or killed, I could never get the iOS version of Immich to reliably sync photos without having to manually open it and leave the app open until sync finished.
This was a few years ago, and was one of several "iOS breaks our crucial workflows" problems that motivated switching our last device over to Android, so the situation might be better now...but I've never had that problem with the Android client, so I know it's not an Immich problem.
I read their "why use our fork" page, and it's very obviously AI-written, which causes me to distrust it.
As a happy Immich self-hoster, I'm not excited by the idea of switching to a fork written by folks who can't even be bothered to write their "why this fork exists" explanation themselves. It inspires very low confidence both in the quality of the many additions (because of the vibecoding) and the long-term sustainability of the project (because of the lack of any effort, and because vibe-coded one-offs tend to die faster than labors of love).
Buried at the very bottom of the wall of slop text on their "why our fork" page is this very last "FAQ" question:
>Why fork at all instead of upstreaming features?
>Several Gallery-exclusive features (Shared Spaces, Pet Detection, contextual filters) were either declined upstream, considered out of scope, or required architectural changes that wouldn't have fit Immich's roadmap. Forking lets us experiment without slowing down the upstream team — and rebasing means we never lose touch with their progress.
There's no mention there of "our vibe-coded implementations of these features were declined by upstream because we vibecoded them"; instead, they frame it as "upstream doesn't want these features for their users", with a dash of "upstream has made bad design decisions" (particularly the note about how upstream Immich "required architectural changes").
That's more than a little disingenuous on "Noodle Gallery's" part.
Of course. We have many big items on our roadmap[0], and just recently in our latest minor[1] we released a new search query API and the first piece of many sharing improvements.
Please no AI slop. I don't want another app that spams my server megabytes per second because my proxy failed and the programmer didn't acknowledge the server can ever go down (talking about Immich - their retry mechanism used to be a while true loop with no back off nor retry limit) or the app resets the upload whenever I bring the app to foreground (also talking about Immich).
I believe I've spent, perhaps, the most time of anyone on earth on digital photo management (hard to quantify, but since 2005 - 2 startups, one acquisition, and an ongoing open source project used by thousands).
I say that because I've refused to settle for most solutions in this space. Even when I adopted using Google Photos, it was as a read only viewer of my canonical photo library (I wasn't about to let Google take that responsibility). I have such high demands of whatever software I use for managing my photos and videos - they're really the only digital files I actually care about.
Immich is absolutely wonderful. It may have some shortcomings ... like partner sharing and sharing facial recognition between users. But man is it remarkable that an open source project can rival something from Google in terms of quality and experience.
And a soft fork like Noodle is precisely the way to handle it. I am perfectly happy with Immich so am not a user of Noodle. But it's open source flexing its strength.
I'd argue Google is always way worse than the open source alternative in both quality and ux. Their products are terrible. From Gmail to Youtube, the product itself comes second (or Nth), while in open source the product is always first.
The submitted title’s framing “alternative to Google Photos and Immich” is dodgy because this is a soft fork of Immich, adding certain features, described in https://opennoodle.de/noodle-gallery-vs-immich/.
Looking at the latest commits, Noodle Galery has many signed with Claude, but Immich doesn't. Is LLM policy a reason for fork? (Just speculating, I don't know.)
UPD: Immich has this in CONTRIBUTING.md, seems like its LLM policy is more strict:
> We ask you not to open PRs generated with an LLM.
vs. Noodle Galery:
> We actively encourage the use of LLMs and AI coding tools.
Their page: https://opennoodle.de
Their GitHub: https://github.com/open-noodle/gallery
EDIT: hmm after reviewing the repo, I'm going to wait a bit to see how this works out. There's a difference between LLM-assisted software development and blindly vibe-coding things without review and this seems a bit like the latter. I see no contributors and hundreds of commits in a very short amount of time. That's a red flag for now.
I have been working on this project for 6 months, and (contrary to what the Immich team posts every single time my project is mentioned) I do not blindly vibe code - or are folks saying that blindly vibe coding 40+ working features while staying in sync with upstream over 6 months is possible?
I really enjoy working on this project and have been building everything that I felt missing in my setup. If you try it out and aren't happy with it, every release ships with a script that reverts your db to Immich, so you're never locked in.
Cheers! Pierre
This was a few years ago, and was one of several "iOS breaks our crucial workflows" problems that motivated switching our last device over to Android, so the situation might be better now...but I've never had that problem with the Android client, so I know it's not an Immich problem.
It's not entirely clear to me what warranted a forked release, are the immich devs not open to accepting some of these new features?
As a happy Immich self-hoster, I'm not excited by the idea of switching to a fork written by folks who can't even be bothered to write their "why this fork exists" explanation themselves. It inspires very low confidence both in the quality of the many additions (because of the vibecoding) and the long-term sustainability of the project (because of the lack of any effort, and because vibe-coded one-offs tend to die faster than labors of love).
Buried at the very bottom of the wall of slop text on their "why our fork" page is this very last "FAQ" question:
>Why fork at all instead of upstreaming features?
>Several Gallery-exclusive features (Shared Spaces, Pet Detection, contextual filters) were either declined upstream, considered out of scope, or required architectural changes that wouldn't have fit Immich's roadmap. Forking lets us experiment without slowing down the upstream team — and rebasing means we never lose touch with their progress.
There's no mention there of "our vibe-coded implementations of these features were declined by upstream because we vibecoded them"; instead, they frame it as "upstream doesn't want these features for their users", with a dash of "upstream has made bad design decisions" (particularly the note about how upstream Immich "required architectural changes").
That's more than a little disingenuous on "Noodle Gallery's" part.
[0]: https://immich.app/roadmap [1]: https://immich.app/blog/v3.2.0-release