Thing is that none of them have the backing of Red Hat's finances. Thus they can'ẗ keep up with the churn that systemd and other RH backed projects produce.
This is exactly why I've moved (and am in the continuing process of moving) more and more stuff over to BSD. Standards matter. Compliance with POSIX and other common standards and conventions are what made the success of Linux possible, and I find it disturbing that the new generation of RedHat developers are keen to tell us that it's old hat and is no longer important. But they are forgetting much of the history and the reasons for it.
Linux didn't get to where it is by throwing its weight around and dictating to others (at least, not much). Its success came from interoperability with everything, making it indispensable glue, and its adherence to standards was an integral part of that. As mainstream Linux becomes more insular and controlled by a single vendor, it becomes correspondingly less useful and less desirable. I don't want to be locked in to a RedHat world any more than I wanted to be tied to Solaris or HP-UX. I get occasional PRs for my software demanding that I add systemd-specific functionality, with the assumption that it's the only thing that matters, and people get annoyed when I refuse to compromise the portability of my already-standards-compliant software with Linux- and systemd-specific hacks.
In case you didn't notice, on iOS 11 and High Sierra the new network APIs are only available as Cocoa APIs there is no plan to support them at POSIX level, while on Google side there are these little things called Android and Android Things, both with a locked down NDK, with Fuchsia on the horizon.
So I know on which side I am betting as winner for this chess game, given that Apple and Google seem to getting all the pieces with their moves.
Proprietary stuff comes and goes. These are merely the latest in a long line of proprietary APIs. They were not so "little" in their time as well. This seems to come and go in cycles; maybe the new generation of developers will come to realise the folly of vendor-specific lockin just as the previous one did.
These new APIs will either stand the test of time and become standards in their own right (POSIX, after all, is codifying existing practice from multiple vendors). Or they will die with the end of life of the products using them.
It's worth noting that POSIX is the fundamental basis of all these products. It's not perfect, and there's certainly room for new revisions or even a complete replacement in the longer term. But open standards are worth fighting for any using, given the alternatives. We got the current open standards through it becoming a requirement that vendors provided them and supported them, and that came from grassroots developers pushing for it. The current big players will eventually have to do the same, and we can all play our part pushing them to do so.
That's a trifle unfair. A lot of this area was intentionally not addressed, for various reasons best laid out in contemporary writings on the subject, by the POSIX standardization effort.
I hate to point out that LOTS of Linux Distros did not and do not have Red Hats finances. People have been contributing to it for nearly 20 years just fine.
Not sure how you could even think that people need Red Hats finances to create something in linux that actually functions, and is worthwhile.
True for initial implementation of individual components. But RH employ developers that can sit full time and churn the interfaces (not necessarily nefariously) between the components such that only their components stay in sync.
