I'm sure it doesn't feel very good to have someone criticize it, I get that. But, this person cared enough about the thing you made to use it, troubleshoot it, and post a comment about it on HN.
At the end of the day, it's valuable user feedback :)
Valuable user feedback (which I absolutely love) is someone pulling the server logs, filing a bug on GitHub and following through till it gets fixed. Or, even attempting to see what parts are slow and reporting it. Worse but still very helpful, providing a link to an affected instance that might help "see" what might be happening.
Spending a few hours trying random things and then complaining loudly like a know-it-all is NOT valuable feedback; it's bullshit. Nothing here is helpful, at all. There's absolutely zero indication of what could be fixed and why this particular person's deployment is broken while thousands of others on much slower hardware work just fine. None.
The other comments you posted are also a bit odd without you disclosing you're the author. just saying
In this case I was rather annoyed since the original comment was very offensively worded and the person obviously had zero intention of helping out. Their only goal was to stroke their own ego by shouting out how something they couldn't get to work is crap.
This is part of the reason for open source maintainer burnout -- useless comments about how something is broken with zero intention of helping to fix it. Hey, it's free -- if you don't like it then either help, or stop crying and move on to something else.
Your work has given me reminders to memories I long forgot about, and nothing can come close to the importance of recalling good memories.
You are doing great stuff with Memories. Community building skills need some work though.
That is my feedback. Which you asked for.
If something doesn't work—regardless of how unhelpful the report or oddly configured the deployment machine is—I would love to hear about it so I temper my own expectations before trying it myself.
While I sympathize with the developer whose product is popular enough to collect 1000 issues as of two days ago, some of your many thousands of users can also get fatigued by spending resources (time, money, mental effort) on deployments that fail because the machine and network running Docker is still different enough from yours that issues arise.
My Hetzner Photoprism bug report has been sitting unanswered for two weeks. Getting the log data and trying out different DNS configurations and writing the bug report took a few hours, because I had to SSH into the Docker image and run curl verbosely and figure out which of the five docker-compose elements was causing problems; running Docker and setting up servers isn't my day job. I don't feel like paying 25 bucks a year for an IPv4 address and don't really want to figure out how to get Let's Encrypt to work on Hetzner's IPv6 by manually adjusting the Docker Compose configuration. I thought that's the point of Docker Compose: that you wouldn't need to dick around with it to get it working. I'll probably delete the thing and replace it with something else—potentially Nextcloud as there's no preconfigured Immich image. So, you know... expect my Memories bug report in a few days.
I can't imagine this user's complaint was fabricated from thin air. Rude or not, they are having problems with the thing you made. Make a mental note, "at least some small percent of users are still having issues, in this case no clear root cause, probably a small enough population to ignore, maybe one day further reduce the friction for reporting bugs or find a way to gather more detailed info." Maybe put them in their place if they actually attack you personally or actually have no useful information e.g. "Product Sucks!!" but beyond that, I (as a potential fellow user) find these not-very-dev-helpful reports insightful, as there are two dozen competing FOSS photo storage programs and I want to efficiently figure out which application has features I prefer, is actually stable and easy to deploy, not likely to switch licenses going forward, has a clear goal and steady progress, documentation is well-written and not just a "Brothers Karamazov" dump of one developer's stream of consciousness, etc.
Should I take two or three hours to file bug reports for each of the 20 photo albums I'd consider testing instead of spending time with family or practicing music? Maintainer fatigue is no joke, but it's also a burden on users if the software does not run, and they've already sunken some opportunity cost, and then not every user knows how to be kind and helpful through their frustration.
Anyway, your reaction is valid. I hope you keep working on the project, but I'd also be okay with not having so many different FOSS options and still no clear winner.
I got done loading a Nextcloud image and it works fine. It's also a different base server and configured differently, and it has IPv4 without extra cost. The only issue so far is that ffmpeg is not detected by Memories so transcoding cannot be enabled, even if I install the only app related to ffmpeg, "Automated media conversion." I'll have to keep reading to see if that's the right app. The server is managed in a way that I can't ssh or change anything Docker-related. I can only log in to Nextcloud at a given URL, so I don't know how run commands from the documentation such as "occ ..." With enough time, I can search if this is usable or not.
It will take probably 20 or 30 minutes to figure out running commands and if ffmpeg can be installed/accessed. I've already committed an hour to this platform even before uploading a single ARW, although I'm already farther along than I was with Photoprism...
EDIT: 24 minutes. I can run occ commands. I can't install ffmpeg. Many others have the same well-known problem: no video thumbnails. Oh well, not a dealbreaker.