As someone who has spent the better part of the last decade working on "just works" deployment (for Heroku) I've got some insights as to why this is https://twitter.com/searls/status/1344277289840873472

To support "zero config deploys" as a library author you've got to coordinate with other library authors. For instance Rack provides a "handler" interface that servers can extend. This interface allows other libraries like Rails use Puma with zero config.

But...that's not good enough.

It turns out that some of the defaults of Puma and Rails interact in surprising ways, so integration work needs to be done between the two.

While this makes for a seamless deploy and use experience, it's expensive (time and effort) and means that other features aren't being worked on.

Heroku was created on a "zero config" ethos, which was largely based on the values of Rails: Convention over Configuration.

. @steveklabnik pointed out one fatal flaw in "convention over configuration", which is...no one bothered to write down the conventions. Conventions change and managing change is expensive and difficult. It means that things like stability and speed of development are trade offs.

Many (most) other language communities do not have this same value. Python famously takes a contrarion opinion here "explicit is better than implicit" which could effectively be translated to "config over convention". I.e. "Set it and forget it".

I believe that's a false choice, as anyone who's had to upgrade to "v2" of some CI providers "config" can tell you. But the choice is rooted in values.

"just works" deployment means coordination and cooperation. It's easier for Ruby and Rails because there's a heirarchy already developed. Heroku is already the dominant PaaS for Ruby here, so if you're writing new tooling, you use the interfaces that we support and provided

(think postgresql, DATABASE_URL, `rake assets:precompile` etc.)

Even then it took years of work to get support for some interfaces like DATABASE_URL supported upstream in libraries like Rails.

Heroku doesn't have as much tenure or traction in all other languages, so it's a harder sell. If someone opens a PR against Puma to support some PaaS i've never heard of my response would be "why don't they work around me instead?"

But it's also unrealistic for <N> products/services to provide custom support for <M> libraries. "Just works" means someone must make decisions for you.

This also involves relinquising control. Users must relinquish some control to library authors, and library authors must give up control to both other libraries and platforms. Everyone wants to define their own standards, but no one wants to use someone else's standards.

At the end of the day it comes down to:

1) Language ecosystem values shape what developers find valuable to work on. For many, "just works" on <product x> is not a goal or value.

2) "Just works" requires coordination and collaboration. It also requires devs to have capacity to see the larger picture and care about that integration. Maintaining a buildpack is a full time job, and while it gets some tooling closer, it's not enough.

Standards can help here. The Cloud Native Buildpacks project takes the monopoly of "just works" deploys, and democratizes it.

It's a much easier sell to say "hey library author, can you do work to integrate with this tool" when it's a tool they can use, even when they're not using a specific product.

But standards aren't enough and integration work is tough. Will the future be more plug and play than today? Hard to say.