The major problem right now if one decides to use a systemd alternative is that most packages are shipping with systemd unit files, but will obviously lack support for other init implementations.
I like dmd, implemented in Scheme, which is part of the GuixSD distribution.
1. The solution to this is to write a translator from systemd units (those of .service type) to the desired kind of unit. I haven't looked into dmd, but this should be possible at least for the majority of units.
2. This was going to be a problem in any case i.e. had most distros switched to openRC one would still have been faced with the task of producing a suitable collection of service configuration files for dmd and then adapting them to dmd's specfic featureset.
Yeah, well, if it's to go from unit files to Guile code, that's not what I'd consider an improvement. Having configuration files for use cases where the requirements are simple enough is nice.
Of course, when they're not, you end up with an abomination like MSBuild, but that's not the case here.
True, but if that is the case you won't be running dmd in the first place. And automated conversion/runtime translation will be a possibility even with different service managers, e.g. systemXVI.
I'm not really convinced by the second, in that I believe that nothing in the article proves that service management is something too complex to be done via configuration files.
I like dmd, implemented in Scheme, which is part of the GuixSD distribution.