I have a new project idea: cluster self-hosted solutions listed in say https://github.com/awesome-selfhosted/awesome-selfhosted by the dependencies they need. Basically, I want to be able to answer questions like, "I'm currently running X. What solution should I choose for y that minimizes my operational burden?" This seems obviously useful. But it's going to require a lot of tedious work to enumerate dependencies. Not just immediate ones but also transitive ones. There's lots of room for multiple people to work in parallel and at their own pace. Anybody else interested in joining in?

What counts as a dependency? Eg: Isn't the premise of Docker (etc) that you just need to be able to run Docker containers, and that's it. Or do you also consider the dev dependencies, like which language and libraries a project is built with? How about versioning — would you want to track at enough granularity to distinguish Perl 5 and 6, or Python 2 and 3? Where's the line?

Easy test: if there's a CVE in project foo, do I need to change anything in my computer? If so, foo is a dependency. Containers and whatnot are details. Some projects may not provide containers and yet be quite parsimonious and worth using. (Like Mu 👼) Good question about build-time dependencies. I obsess over those in Mu, but in this project I surprisingly don't immediately care about them. Assume projects distribute some post-source form (even if it includes source, like a gem or npm package) Versions are absolutely crucial. The fact that two projects both use Node or Python doesn't actually mean much in my experience. There may be wide divergence in their dependencies and therefore total cost of ownership. But maybe we can start small. For starters, cluster Python vs Node, etc. Then Python 2 vs Python 3. Then major versions of libraries on Python. Then minor versions. Then patch versions (because they're often abused).