>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 Wel

>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-made-for-man-not-man-for-the-categories/ 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.