One existing technology Red Hat leveraged to achieve this was Gnome. A few years ago, the Gnome developers (many of whom were employed by Red Hat) decided to create a hard dependency on logind which was part of systemd. Other distros were mollified by being told that logind didn't really depend on systemd and they could just take it out and use it. Then, once that was safely ensconsed, Poettering declared that actually using logind without systemd wasn't supported, they shouldn't have done it, and he was going to completely break it. All the desktop distros were forced to abandon their own init systems and switch to systemd, with all the headaches and bugs that entailed.

Another technology they're using is to some extent the Linux kernel itself. The API used to create device nodes when drivers are loaded is undocumented and the only supported way to use it is udev; anyone else can expect to have their code broken by new kernel releases. That, in turn, is now part of systemd and using it outside of systemd is no longer supported. In effect, the only supported way of using the Linux kernel is with systemd and anyone else is on their own dealing with undocumented, backwards-incompatible changes that the developers have no interest in helping them with.

When upstream packages depend on systemd then other distros are forced to adopt systemd, which is a moving target. The goal is for everyone to just use RHEL to avoid the hassle.

E.g. Debian went systemd because they don’t have the resources to fix everything they get from upstream that requires it.

What's being embraced here is Linux and its standing as a preferred OS for running F/OSS itself, by wrapping everything into Windows-y abstractions (and .INI files even).

Yup. Reminder that RHEL 6 uses upstart. If this were a Red Hat conspiracy, why would they have switched from sysvinit to an incompatible competitor to systemd?

While not arguing IBM/RH is actually doing EEE.

> they simply hired the guy who first developed it

If so, they aren't the originators, but it doesn't preclude them from using systemd to do EEE.

> open source and GPL, anybody can fork

While being OSS and GPL limits attainable power, controlling the development on ever changing software with increasing scope does yield quite significant power and makes practical forking quite hard if you with to remain compatible.

> out-competing alternatives

I remember distributions being forced to use systemd due to software dependencies and ensuing debacles. I think this might be classified as extend and extinguish.

> it being open source and GPL, anybody can use it or fork it

The entire point of the EEE strategy is to capture protocols or standards, such as software developed by other companies or free software developed under the GPL. Forking isn't a relevant option, because the other parties software is not changed (it's expected to not be able to change).

From Microsoft employee Ronald Alepin's sworn expert testimony[1] in Comes v. Microsoft:

    Q. Okay. And now, again, for the Jury, what does embrace mean in
       this context as used by Microsoft employees?

    A. It's used to indicate a strategy where Microsoft will embrace
       the standards or the specifications and interfaces of another
       company's software.

    Q. Okay. And what does extend refer to?

    A. Once the specifications have been embraced, then Microsoft will
       extend them and add additional interfaces proprietary to Microsoft.

    Q. Okay. When you say add additional proprietary interfaces that
       are Microsoft's, what impact does that have technologically to
       other ISVs and OEMs?

    A. Well, the result is or the impact is that what was once sort of
       community development property, the work of the industry and
       industry participants is appropriated essentially, is taken over
       by Microsoft.

       And then Microsoft takes it and with its proprietary extensions,
       makes it essentially unavailable on a going-forward basis to the
       industry participants who were responsible for first developing
       the specifications and the standards.

    Q. Okay. And when Microsoft makes those APIs unavailable to certain
       ISVs and OEMs, what's the impact to those ISVs and OEMs of their
       ability technologically to create products?

    A. It reduces their ability to create products, especially products
       that will interoperate with Microsoft's products.

Examples of this strategy include Mirosoft's attempts to capture the Kerberos protocol and Java. In both examples Microsoft first embraced existing software outside their control by writing their own implementation, then added non-standard features that were only available in their implementation and a clause in their EULA that forbid anybody that used their implementation from re-implementing the features in other (original) software. The GPL doesn't help here, because Microsoft never touched the original free/open implementation, which continued to exist but was now incompatible with Microsoft's software.

While the systemd situation is a little different (it isn't trying to take over "another company's" software, systemd de facto IS somewhat similar to the EEE strategy. They initially embraced existing open standards common in Linux distros, and then extended various parts of their implementation intentionally[2] incompatible changes that had the de facto effect of "reduc[ing] [the] ability to create [non-systemd distros], especially [distros] that will interoperate with [systemd]"[3]. It's not exactly EEE, but there are strong similarities with new features used as a barrier to interoperability.

[1] http://www.groklaw.net/articlebasic.php?story=20070108020408...

[2] e.g. GNOME depending on the systemd-specific version of existing features that made running GNOME without systemd very difficult.

Without having much opinion on systemd, hiring the developer sounds very much like “embrace”. Continuing developing sounds like “extend”.