It's almost like the company behind it wants to see some profit after pouring millions of dollars into developing these tools. Except, in 2020 you cannot just have a closed-source easy-to-use documented and supported product with a license fee. Not in the server market, at least. Everything must be free and open-source, and you are expected to make money by offering a hosted service. Except, good luck competing with Big Cloud.

It's extremely worrisome. The incentive to spend your early mornings, nights, and weekends building something awesome to free yourself from corporate life is fading away. They need to institute some kind of royalty program or at least dedicate engineers to helping maintain the projects they make into services.

Almost have to change gears and get into a scientific field that isn't computer science.

One of the Loki maintainers here (though I mostly work on other stuff now). I promise it's not difficult on purpose.

We've put a lot of effort into optimizing the Kubernetes experience that non-containerized installations haven't been getting as much attention. We'd be thrilled to have system packages for Loki that also set it up as a service, it's just not something we've been able to spend time doing ourselves yet.

Honestly I mostly throw out the Debian service definitions anyways - when clustering or interacting with Chef or Ansible or whatever, you end up building a lot of ‘smarts’ around a custom supervisor like Runit or skarnet or systemd

It isn't just loki, but the whole stack. Grafana is the only project mentioned that has a debian installer.

The expectation that someone doing greenfield development is going to jump into k8s just to use the software is kind of weird.

I’m deploying it (prom, alertmanager, pushgateway, grafana) on native hardware via ansible and it’s not difficult. Not Loki (yet). It’s all just go binaries you fire up with systemd with a single config file.

I find it harder to deploy reliably on kubernetes with persistent volumes etc.

All of those who have spent their free time contributing to Linux distributions are why 'apt install' is easy. You can contribute too.

As the co-founder of Apache Java and a 20+ year member of the ASF, creator and contributor to hundreds of projects over the years, I think I've contributed enough of my time to OSS. I'm more than happy to let the new kids jump in. Thanks for the 'advice'.

What percentage of ASF projects use 'apt install' at all? Did the Apache folks themselves make the packages? Should we complain about ASF for not making an 'apt install' for each of their projects?

Of a random sampling of install instructions for different ASF projects, the instructions generally are "1. Install java" then "2. Download this binary" and "3. Run the binary with java". Not quite 'apt install', is it?