Lets begin by taking a look at some facts.
Lennart Poettering and Kay Sievers who started the project to develop systemd in 2010 are both Red Hat employees.
Initially systemd was released as a new init system, but it has slowly grown into what Poettering describes as "a suite of software that provides fundamental building blocks for a Linux operating system." This is by design, not by coincidence.
The official reason for the development of systemd was described as: "They wanted to improve the software framework for expressing dependencies, to allow more processing to be done concurrently or in parallel during system booting, and to reduce the computational overhead of the shell."
Red Hats primary business is in embedded devices, and the primary concerns addressed by systemd by design is embedded devices, such as the work towards removing
In an interview with Red Had CEO Jim Whitehurst he states:
We partner with the largest embedded vendors in the world, particularly in the telecom and automotive industries where stability and reliability is the number one concern. They easily adapted to systemd.
Mentor Automotive has released their slides from a 2015 event In these slides the many benefits provided by systemd to the embedded automotive market is fairly well explained. The reason why they "easily adapted to systemd" is because systemd is specifically designed to suite their needs.
In 2012 Lennart Poettering changed the systemd license from GPL to LGPL in order to better suit the embedded market.
This is the secondary objective of Red Hat which is illustrated by Lennart Poetterings slides from FUDCON + GNOME.Asia Beijing 2014. Go to page 15 and scroll slowly forward to page 19.
Eventually you end up with the project objectives:
Combined with the next set of slides that display the market Red Hat want's to target:
Red Hat has "great" future plans for the Linux community.
If Red Hat was ever going to succeed in their long term plans for developing the "Internet's Next Generation OS" they needed to somehow influence the other major Linux distributions.
The reason for this is that if a major Linux distribution like Debian was going to reject systemd, Red Hat wouldn't be able to proceed with their plans because to many third party projects simply wouldn't care about how Red Hat would like things to work.
This is important because most Open Source projects develop software with POSIX compatibility in mind. As such they try to make sure that their project compiles and works on several UNIX-like operating systems.
Firstly, this isn't in the interests of Red Hat because POSIX complicates things a lot for embedded devices. And secondly, as long as you have to consider other operating systems such as Solaris, FreeBSD, OpenBSD, etc., Linux is "held" back when compared to functionality in Microsoft Windows. Functionality such as easy mounting and unmounting, simple privilege escalation, and much more.
The tactics deployed by Red Hat was to try to get as many "important" third party projects to cooperate very tightly with systemd, or even depend upon systemd. This way other Linux distributions are more easily persuaded into adopting systemd because of the easy integration of these third party projects.
The systemd developers addressed several third party projects and tried to convince them to make their projects either depend upon systemd, such as the attempts made by Lennart Poettering on the Gnome mailing list, and the attempt made by Red Hat developer "keszybz" on the tmux project.
Most of these attempts were originally "disguised" as technical issues, however when you read the long email correspondence on the Gnome mailing list and elsewhere, the real intent becomes quite clear.
Other "tactics" deployed by Red Hat was hiring developers from other Linux distributions, such as Debian, and then have these people promote systemd internally.
One of the results of all of the above was a huge uproar in the Open Source Linux community in which Debian Developer Joey Hess, Debian Technical Committee members Russ Allbery and Ian Jackson, and systemd package-maintainer Tollef Fog Heen resigned from their positions. All four justified their decision on the public Debian mailing list and in personal blogs with their exposure to extraordinary stress-levels related to ongoing disputes on systemd integration within the Debian and open-source community that rendered regular maintenance virtually impossible.
In December 2014 a group calling themselves the "Veteran Unix Admins" announced a fork of Debian called Devuan that intends to provide a Debian variant without systemd. Devuan 1.0.0 was released on May 26, 2017.
The main problem with systemd is that its continued development is motivated by a company's economic interests and not the Open Source Linux community interests. This results in, among other things, compatibility issues with what is normally considered POSIX.
As time goes by more and more "issues" will pop-up and the other major Linux distributions will eventually (most likely) regret the integration and adoption of systemd into their projects.
Several "issues" has already surfaced. What I mean by "issues" is not software bugs, but the way both software bugs, user concerns, privacy concerns, and very important security issues is dealt with.
In a September 2014 ZDNet interview, Linux kernel developer Theodore Ts'o expressed his opinion that the dispute over systemd's centralized design philosophy, more than technical concerns, indicates a dangerous general trend toward uniformizing the Linux ecosystem, alienating and marginalizing parts of the open-source community, and leaving little room for alternative projects. In this he found similarities with the attitude he found in the GNOME project toward non-standard configurations. On social media, Ts'o also later compared the attitudes of two key developers to that of GNOME's developers.
Hard coded Google DNS in systemd-resolved is another issue with privacy problems. Lennart Poettering explained that the hard coded values should be there in case of catastrophic failure of configuration files, and a lack of DHCP on the network (the DNS fallback is changeable but requires a recompile). However, that's the "embedded developer" speaking. If a bug is found in the application that makes these DNS servers run even though you have disabled them, you could be facing a serious privacy issue if you combine systemd-resolved with a public VPN provider. Futher more running with Google DNS servers hard coded into the systemd code is deeply problematic as the company is not only know for violating peoples privacy, but also because NSA has infiltrated Googles data centers, something revealed by the Snowden documents.
The way these "issues" is usually dealt with shows a complete disregard for the interests of the Open Source Linux community.
Another solution to the problems Red Hat pose with their management of systemd could be for a big distribution like Debian to actually fork systemd and make sure it's headed in the right direction - out of the main control of Red Hat. This is most likely the easiest solution as systemd has already been deeply integrated into many parts of Debian.
Currently Red Hat still treads carefully, but once they get much closer to their main objectives, they will most likely become more "aggressive" in their management style of systemd and the world of Linux will properly change dramatically as a result.
If you have any comments or corrections feel free to email them to me.