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.
Nobody was willing to maintain consolekit, the logind folks stepped up to provide a replacement and the gnome folks started depending on it. Everyone could have prevented that lock-in by maintaining consolekit or providing another replacement. Nobody did. To this day, tons of folks complain that gnome depends on logind.
E.g. Debian went systemd because they don’t have the resources to fix everything they get from upstream that requires it.
Being the primary developer of important system software does have benefits.
But keep your lame conspiracy theory, it will surly get you much open-source street cred.
> 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.
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.
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.
It was never incompatible with MIT or Heimdal. Those systems didn't use the group information in the optional field, but you could kinit and get a Kerberos ticket from a DC.
I know I'm not going to change your mind, but Kerberos isn't a good example.