I am rather considering official repos as a means to keeping your Debian system in a "supported" state. Many users, including software developers, want to only install software (or sw versions) that would not put their system in an unsupported configuration.

> Debian DOES care about about both experience and ethics of what is allowed to be distributed in official repos

Podman is widely distributed in official Debian repos, so ethics is not a question in this particular case. We are only talking about Debian repos being conservative with the versions of the software in the repos - not limited to Podman. Debian does not encourage users to install software from 3rd-party repos just to get a newer version of an existing package because the stability of the system (and the ability to do major version upgrades) cannot be guaranteed otherwise.

Also, I moved about 10 repos to a private Forgejo installation with pretty average (non-trivial) GH actions workflows. Zero repos has workflows running oob (java, .net, node). The moat is a bit there.

Compare your npmx link to vue to https://npmx.dev/package/node-red-contrib-rtc-alert-node . This package uses deprecated and vulnerable deps and npmx correctly uses color to draw attention to it. And because the npmx page is normally monotone, the use of color actually draws your attention.

Regarding clutter - I agree.

I think for most business stakeholders it's not about the number of services but rather the coverage of business-critical needs. When you have access to Azure Entra, you know that you can cover 90%+ of your auth needs with that service. If you have access to AWS S3, you know that your various storage needs would be possible to cover with that. If a managed Postgres is available, you know that most of the IT systems you run would be able to take advantage of that. You look at Azure their IAM/audit/observability offerings and it's the same.

When you look at Hetzner as a business stakeholder, all you see are bare servers and and one object storage service that you are not sure of how battle-tested it is. And then you start thinking: "okay, I will need to run k8s or some other workload orchestration approach, my IT systems need Postgres/MySQL/SQL Server etc, I need auth, I need audit, I will need to build, operate, maintain all of that in-house". I am not saying that this is a wrong path for everyone, but Hetzner essentially leaves you no choice. And many business stakeholders who have been operating their own own-prem infra or colocated or rented IaaS plus a large dev team for decades and have since switched to one of the hyperscalers and reduced their dev/IT headcount - may not want to go back to the old model.

> limiting yourself to a smaller portion of AWS/Azure/GCP services can facilitate migrations to other cloud platforms.

Yes, which is why you insist (where possible/reasonable) on Postgres-compatible DBMS offerings, IdP solutions based on OIDC, observability on OpenTelemetry.

> Sure, smaller cloud providers don't usually have all those services, but this doesn't mean they are not cloud providers

Yes, it could mean that they are not cloud providers.

> but they can probably satisfy the needs of other users who are more than happy with a smaller feature set

Please see the linked article. This is essentially "users who are happy to build some of the furniture themselves".

*with a dark theme.

[1]: https://github.blog/news-insights/a-new-look-for-repositorie...

To be... more precise?

On a more serious note, cannot recommend enough "Exactly: How Precision Engineers Created the Modern World" by Winchester. While the book talks mostly about the precision in mechanical engineering, it made me appreciate _precision_ itself to a greater degree.