Hi Dominic,
Although I'm not going to contribute to the Trove project anymore, I disagree with what you said that using database containers is a bad example, especially considering the project situation in the open source community in the past several years.
I've explained this several times to different people when I was making the change, but I don't mind repeating myself.
Trove was supporting multiple datastores previously and maintaining a bunch of DIB image elements to build different guest images. However, the task of keeping those elements up to date is not easy, and needs the domain knowledge of the specific database, but most of the active contributors have left and the project itself was on the edge of death.
It was that time when I picked up the project because the database-as-a-service was on the service roadmap of our openstack based public cloud. Given this is such a complicated project with such a small team, it's impossible to maintain those different kinds of datastores. As a result, I made the decision to simplify the trove guest image build process and introduce container based database inside trove guest instance, so the project only needs to maintain a single common guest image but to support as more datastores as possible, offloading the database container image maintenance work to other upstream teams who specialize in the database technology area.
I don't think we had other better choices at that time.
Anyway, hope there will be more people could see my comment here and there will be someone raises his hand to lead this project forward. I'm glad to know Trove is deployed in your cloud, it's a pity that I didn't see any contribution coming from the team behind your cloud.