In Linux everything is a file. So modifying files is all you really need. The hardest part is how to handle mobile endpoints like laptops, that don’t have always on connections. Ansible pull mode is what we were looking at in a POC, with triggers on VPN connection. Note we have a large Linux server footprint already managed by ansible, so it isn’t a large lift for us.

Tried this at work and discovered it only really works on vscode and probably eclipse. Other IDEs claimed support but it was found to be unusable.

I do agree mostly with your point here, but I think you can limit the scope a bit more. Mainly provide a working build environment via one of the mentioned tools, since you will need it anyway for a ci/cd pipeline. You can additionally have a full development environment that you use available for people to use if they choose. It is important that it be one regularly used to keep the instructions up to date for anyone that might want to try to contribute.

From my observations as a sys admin, people tend to prefer the tools they are familiar with, especially as you cross disciplines. A known working example is usually easy to adapt to anyone’s preferred tooling.

The lack of version is the problem. Syntax has changed over time, so when someone finds or has an older compose file, there is no hint it won’t work with the current version of docker-compose until you get errors and no graceful way to handle it.

Compose doesn’t have a versioned standard, it did for a bit iirc, which also means you can’t always just grab a compose file and know it will always just work.

Most self hosted works fine with giant all in one containers, even for complex apps, it’s when you need to scale you usually hit problems with an all in one container approach and have to change.