I think it is matter of contract between author and users. Some authors just do not provide services like "background compatibility".

"Shipping" requires a lot of work, and some people just refuse to do that. Some of my popular programs are just repos on Github. To use them you have to run build script and execute from source code.

It elimites people who would require a lot of support, and would not give a meaningful contribution. Less work for me...

And if you desperately need my software, I always provide consulting...

I fail to see what is won by not providing clear, simple, standardised installation instructions in a README.

I make a habit of providing these for myself and they are great, both when I enter a new domain and need to remind myself of best practice, and when I return to a domain after a long time.

The lack of such instructions is a strong indicator to me that a project hasn’t reached maturity.

Yes. Yes yes yes. Configuration files with standardized contents tend to ossify into an appendage of the application written in what is effectively a domain-specific language. (See sendmail, for instance.)

There's a nice spec for this by the UAPI group: https://uapi-group.org/specifications/specs/configuration_fi... , with the most common implementation called libeconf. The tl;dr is that an application / OS vendor can ship the default configuration in a path like /usr/etc, some dynamic runtime component can then override it in a path like /run, and a sysadmin can override that in a path like /etc. Each location is searched for a main config file or dropin patches under a `.d` directory or both (depending on the software's choice), and then considered in a defined order - later search directory roots have priority over earlier ones when the filename is the same, and dropins are considered in lexicographical order of filename regardless of which search directory they were found under.

That said, it unfortunately doesn't go on to specify local-user overridability via $XDG_CONFIG_HOME etc, which might limit its adoption.

> (hello Matrix / Synapse)

Synapse also supports using a drop-in directory for configuration

Nice. That was some time ago, it probably improved since then. I edited my post to reflect this.

The downside of this is that if the author changes a configuration key, you configuration will probably be invalid (thus refusing to come back online), or worse, ignored and the warning buried in systemd logs.

At least if the maintainers version and your version require review, you have a fighting chance to update the configuration with your customizations, without downtime or unexpected behavior.

You can't rely on this stuff if you want to avoid downtime.

If you want to avoid downtimes, you need to read changelogs and plan upgrades, and maybe test the upgrades before upgrading the production, in any case.

That works for an enterprise or business. When you are doing this stuff for fun and/or hobby, being halted during the upgrade is a MUCH better UX than deleting all my data or whatever undefined thing might happen.

Of course, I'm not advocating for such adversarial behaviors like the upgrade process deleting your files.

But you have a point, and maybe a solution to this issue ought to be found.