¿What do you think we could do to address this issue?

In my opinion codegen is the way to go, as you said, maintaining a client lib against a target that is changing all the time is a ton of effort for a single person, which means that most of the time we just hook up a small wrapper with the needed methods for our project, it works pretty well for a single project, but is tightly coupled and makes no sense to release it since it will be useless outside of a very small and well defined scope.

A couple weeks ago @wojtekmach created this proof of concept, and I think that expanding on his ideas could be a nice starting point.

https://forum.elixirforum.com/t/lets-try-to-get-officially-supported-elixir-libraries-for-stripe-braintree-and-paddle/37924/42?u=thomas.fortes

That is a great approach, but I don’t believe it’s generalizable.
For example Brod and Kafka_ex uses code generation techniques for the Kafka Protocol, but all the behaviour (for producing and consuming messages) has a ton of work behind. Erlkaf just uses the NIF for librdkafka, and works great, but then we depend on C libraries.
Then TDS has a well implemented binary protocol, but now they have to handle SSL, Active Directory, etc.. a ton of work again.
I was thinking more on how founding these projects.

I also stand behind code generation – it’s the best way to go if we want to cover a lot of surface with limited amount of humans behind keyboards to support the projects.

If the protocol has an OpenAPI machine-readable file then a lot of the work can be done by the computer and not by the human.

Failing that – or in addition to that – and if the service is SaaS and if it has a sandbox environment (loads of “if”-s, I’ll admit that) then an integration testing suite running once a week that asserts that the endpoints are still there and are working as expected is a reasonable compromise. I’ve done it in the past with other languages.