Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's not how EEE worked. From wikipedia

1. Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.

2. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard.

3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.

Systemd is part of "Extend", and what they're extending is the linux ecosystem. Sure, those extensions might make things better in the short term and for some uses cases, but they're now owned by IBM so good luck!



Did you even read what you've quoted there?

Redhat didn't embrace a competing product, redhat has been a Linux distribution from the start.

They extended it by adding systemd, yes. I said as much before too.

They didn't extinguish Linux as their extension continues to be open source and ready to fork.

If you're going to argue from the perspective of sysvinit instead then neither embrace nor extend happened. Whatever redhats goal were, it wasn't EEE


> Did you even read what you've quoted there?

Yes, and I think it's pretty obvious to anyone who is familiar with the history. EEE is about a set of anti-competitive practices, ones that are definitely and obviously being used here. Whether they do that with malice aforethought is unknown, and nothing there is illegal by itself, but it is a pretty clear thing they're doing.

Microsoft didn't embrace office document editing software, microsoft word was one of the first document editing suites. And yet that is one of the examples in the wikipedia article: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

Did microsoft extinguish document editing software? No, they just used their market position to make sure that their implementation was the most dominant.

Another key example is "Breaking Java's portability". Do you want to talk about how the move to systemd has effected the various BSDs? Here's a talk about it: https://papers.freebsd.org/2018/bsdcan/rice-the_tragedy_of_s...


> extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors.

But the one qualifying bit for the EEE strategy to work is to remove the open source option, replacing it with something that can only be provided by them. And systemd is open source as far as I know, So the extinguish phase isn't possible in that sense.


>But the one qualifying bit for the EEE strategy to work is to remove the open source option, replacing it with something that can only be provided by them

Well if that's the definition you're using, why are we even talking? 6 comments deep and you're only now bringing up that by the definition you're using only proprietary software can use EEE? That's a pretty big point, and probably should have been brought up in comment number 1.

Like what are you even talking about if you're just bringing that up now?

And I mean sure, define EEE in a way so that it can only apply to proprietary software. However in my first comment I said this: "The fact that the underlying code is open source apparently doesn't matter too much."

Personally, I think you can use the techniques of EEE to get control of an open source project, and whether your alternative is open source or not doesn't really matter since what it's actually about is control. Making sure the open source community treats your solution as the de-facto standard, making sure that your solution with all it's eccentric little commands is the one taught in schools, selling ad-on projects like log-collections daemons and making it harder for your competitors to do the same.

https://slatestarcodex.com/2014/11/21/the-categories-were-ma...

EEE is descriptive of what's happening, it's not prescriptive. If you'd like I can say that "redhat is doing stuff that looks a lot like EEE except for this list of caveats which make it slightly different from these other cases, but not different from these cases". But if we're done debating definitions we can talk about the actual behavior I find objectionable, but that's all pretty well documented in other places.


That definition was quoted from the first paragraph of your source, Wikipedia.

And no, it's not descriptive of what is happening. Systemd was disruptive, yes. But not all disruptive things are EEE.


>but not all disruptive things are EEE.

I'd agree with that, there are no rock solid definitions we're going to agree on. Still, there are a number of places where a small concession from Redhat would have made other people's lives a lot easier. See also, this very thread and support for server-side-decorators. A decision made by someone directly employed by Redhat.

Innovation without compromise that significantly impacts downstream software, and where patches aren't accepted. That looks a lot like using a market position to unduly influence other projects to me, and they'd get a lot more sympathy if they at least said "pull requests welcome" or if Redhat paid an engineer to make libdecor less awful. (Note that redhat is also paying developers for libdecor development work)

There are a lot more examples like that floating around.


> Still, there are a number of places where a small concession from Redhat would have made other people's lives a lot easier.

And I completely agree with that. I just took an issue with the EEE reference




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: