Given the other replies in this discussion thread, I am inclined to believe that they are /Good Stewards/ of the design goals they have.
I believe a more proper examination of 'open-souce' or even Free Libre citizens might be found in examining the license selected for their works.
They chose the GNU LGPL 2.1+ license. Given their other stated beliefs, I read that they believe in allowing others to build off of this work, but would prefer those developers fork it and to begin a sister work that is more optimally coupled to another operating system.
That would be fine if they would standardise their APIs. But they only do that at the boundary; as more and more functionality moves into systemd that means more and more with no documented, supported API. Any port would have to implement systemd piecemeal, like GNU did with unix - but all the systemd interfaces are nonstandard and unsupported, making that impossible.
The internal ones, as I said. E.g. you can't write a drop-in replacement for logd, or even a reader of its files. IIRC systemd doesn't support non-kdbus dbus - or indeed older kernels at all.
systemd supports non-kdbus DBus, that is essentially what every deployed systemd system is using. Including this laptop, which is on latest systemd (227) with upstream kernel (4.2.5, kdbus not included).
Why is it important to be able to replace journald (assuming that is what you meant by logd)?
Being able to replace individual pieces is the heart of open source - the only reason the GNU project was able to get off the ground is because it could swap out individual parts of unix without having to write the whole thing from the ground up. More generally, forking only works if you can do it on a granular level. So if I have an idea for improving journald and for whatever reason the official maintainers won't accept my patches, I should be able to release my own fork of just journald and if people like it then it will become more popular and maybe be mainlined or maybe not. If I have to fork the whole of systemd to do that then it's too much overhead.
journald is a separate module in the systemd tree, so this is very likely possible. You have both the code implementing the daemon and the one using it available to study, so the interface.
The issue is that systemd might change that interface at any time, even in a minor or patch release. Because systemd's released as a single monolithic project, they don't have to commit to any standardization, deprecation cycle or the like for the interface between components.
Yep, no stable interface for journald. Someone is gonna have to prove to them it is needed, by implementing something useful that utilizes said interface.
but as documented previously in thread, for plenty of their components they have committed to stable, documented interfaces.
systemd supports 'older kernels', just not old ones.
systemd 227, released last month, requires Linux 3.7+. That version was release December 2012, or nearly 3 years ago.
