"EEE" isn't a magic incantation, it's the name of an actual policy with actual tangible steps that their executives were implementing back when the CEO thought open source was the greatest threat to their business model.
Microsoft contributing to a project doesn't automatically make it EEE. For one thing, EEE was about adopting open standards in proprietary software. Microsoft during EEE didn't publish GPL code like this is.
Well, most of their extensions to VSCode are proprietary. When their dominance in software development becomes irreversible, it's obvious that they will close things down and create new sources of income. The incentives are clear.
VSCode is _their_ product. It doesn't make sense to say that they are EEEing their own product. EEE is when you take some existing open standard, support it in proprietary a product, and then extend it in proprietary ways, thereby taking over the standard. It doesn't apply for a product that you originally created.
So what? You can use VSCodium and the OpenVSX marketplace if you like, no one is stopping you. It DOES mean you won’t be able to use some extensions that are published exclusively on the VSCode marketplace but guess what? You’re not entitled to every extension being accessible from all the stores, and you’re even less entitled to demand that all extensions are open source.
If Microsoft want to develop some proprietary extensions for VSCode it’s fine, everyone has this right. It has nothing to do with EEE.
The fix described in this post have been submitted as a patch to the official Git project. The fix is improving a legitimate inefficiency in Git, and does nothing towards "embracing", "extending", or "extinguishing" anything.
Can you imagine their fork extending git with a feature which is incompatible to mainline git and then forcing user's to switch to their fork via github? I can, and it will give them the power to extinguish mainline git and force everything they want on their users (telemetry, licence agreements, online registration...). That might be the reason they're embracing git right now. The fork being open source doesn't help at all.
I'm not saying this shouldn't be merged, but I think people should be aware and see the early signs.
There is no fork. It's some new stuff they're working on and have sent patches to upstream git for (and will presumably get merged in due time – or at least, it's certainly written with the intent to get merged upstream).
The extend phase starts when they make extensions which only work in their proprietary version. Putting extensive work into contributing them back is not the same.
I note the conspicuous lack of examples, and it’s irrelevant in this case where they are working to get the changes merged upstream exactly the way, say, Red Hat might have something they work on for a while before it merges upstream.
VS Code is the most common example people have, but it’s not the same: that’s always been their project so while I don’t love how some things like Pylance are not open it’s not like those were ever promised as such and the core product runs like a normal corporate open source project. It’s not like they formed Emacs and started breaking compatibility to prevent people from switching back and forth. One key conceptual difference is that code is inherently portable, unlike office documents 30 years ago – if VSC started charging, you could switch to any of dozens of other editors in seconds with no changes to your source code.
I would recommend thinking about your comment in the context of the boy who cried wolf. If people trot out EEE every time Microsoft does something in open source, it’s just lowering their credibility among anyone who didn’t say Micro$oft in the 90s and we’ll feel that loss when there’s a real problem.
* Kerberos (there was a time you could use KRB4 with Windows because AD is just krb4 with extensions: now you have to use AD).
* HTML (activex etc)
* CALDAV // CARDDAV
* Javas portability breakage
* MSN and AOL compatibility.
“oh, but its not the same”. It never is, which is why I didnt want to give examples and preferred you speak to someone who knows the history more than a tiny internet comment that is unable to convey proper context.
No examples offered. And zero that I know of with respect to Git. This is how all open source development is done with big features - iterated on in a fork and proposed and merged in.
There are so many good things to criticize Microsoft for. When this is what people come with, it serves as a single of emotion-based ignorance and to ignore.
VSCode is a prominent one that is in everyones mind, its starting its journey into extinguish.
For more examples I would consult your local greybeard; since the pattern is broad enough that you can reasonably argue that “this time, its different” which is also what you hear every single time it happens.
A lot of new and popular features in VSCode are only available in the official MS version of VSCode. Using any of the forks of VSCode thus becomes a lesser experience.
Microsoft Embraced by making VSCode free and open source. Then they Extended by using their resources to make VSCode the go to open source IDE/Editor for most use cases and languages, killing much of the development momentum for none VSCode based alternatives. Now they're Extinguishing the competition by making it harder and harder to use the ostensibly open source VSCode codebase to build competing tools.
> Embrace: Development of software substantially compatible with an Open Standard.
> Extend: Addition of features not supported by the Open Standard, creating interoperability problems.
>Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors who are unable to support the new extensions.
As I see it, there no open standard that Microsoft is rendering proprietary through VSCode. VSCode is their own product.
I see your point that VSCode may have stalled development of other open source editors, and has proprietary extensions... but I don't think really EEE fits. It's just competition.
To add to this, there are also official Microsoft extensions to VSCode which add absurdly useful capabilities behind subtle paywalls. For example, the C# extension is actually governed by the Visual Studio license terms and requires a paid VS subscription if your organization does not qualify for Visual Studio Community Edition.
I'm not totally sold on embrace-extemd-extinguish here, but learning about this case was eyebrow raising for me.
C# extension is MIT, even though vsdbg it ships with is closed-source. There's a fork that replaces it with netcoredbg which is open.
C# DevKit is however based on VS license. It builds on top of base C# extension, the core features like debugger, language server, auto-complete and auto-fixers integration, etc. are in the base extension.
They will extend git so that it works extremely well with their proprietary products, and just average with other tools and operating systems. That's always the goal for MS.
