I promise I understand what I’m talking about, building for scale on a global level is what I do for a living. I also know something about open source projects, having co-founded Rocky Linux and the Rocky Enterprise Software Foundation and serving as its Director of Operations.
I’m not calling into question your qualifications. I do think you have misunderstood how lemmy works.
The lemmy.ml website could go dark tomorrow, completely offline, and lemmy would continue to exist and the software would continue to need maintenance and optimization. Those GitHub issues are for improvements that will help everyone, not only people using lemmy.ml specifically.
If you persuade lemmy.ml’s admins to deploy a load balancer and whatever else, that doesn’t help me. It doesn’t help anyone who’s hosting an instance that isn’t lemmy.ml, which is most of them. It’s arguable whether it even helps the admins and users of lemmy.ml itself, since half the point of federation is to not funnel users into one massive canonical instance that everyone is using. But if you write documentation or share automation tools that guide anyone on making their other federated instances more scalable, or if you contribute to lemmy’s source code to make improvements there, then that helps everyone. It improves lemmy the federated network as opposed to improving only the single inconsequential instance that is lemmy.ml.
Yes, I understand all of that. I know that it helps all the various instance owners. But that’s a problem that has already been solved. Building for scale is not specific or special to Lemmy. There are already entire automation toolsets—things like K8s or Docker Swarm, Terraform and Ansible, and endless documentation and examples on how to use and implement all of this. You’re talking about the greater whole, and what I’m trying to talk about is Lemmy.ml.
I do agree we’re probably talking past each other, though, and that’s alright, that’s how it goes on the Internet sometimes.
I’m not calling into question your qualifications. I do think you have misunderstood how lemmy works.
The lemmy.ml website could go dark tomorrow, completely offline, and lemmy would continue to exist and the software would continue to need maintenance and optimization. Those GitHub issues are for improvements that will help everyone, not only people using lemmy.ml specifically.
If you persuade lemmy.ml’s admins to deploy a load balancer and whatever else, that doesn’t help me. It doesn’t help anyone who’s hosting an instance that isn’t lemmy.ml, which is most of them. It’s arguable whether it even helps the admins and users of lemmy.ml itself, since half the point of federation is to not funnel users into one massive canonical instance that everyone is using. But if you write documentation or share automation tools that guide anyone on making their other federated instances more scalable, or if you contribute to lemmy’s source code to make improvements there, then that helps everyone. It improves lemmy the federated network as opposed to improving only the single inconsequential instance that is lemmy.ml.
Yes, I understand all of that. I know that it helps all the various instance owners. But that’s a problem that has already been solved. Building for scale is not specific or special to Lemmy. There are already entire automation toolsets—things like K8s or Docker Swarm, Terraform and Ansible, and endless documentation and examples on how to use and implement all of this. You’re talking about the greater whole, and what I’m trying to talk about is Lemmy.ml.
I do agree we’re probably talking past each other, though, and that’s alright, that’s how it goes on the Internet sometimes.