In this blog post, we explore the ecosystem of open-source forks, revisit the story so far with how Microsoft has been transforming from products to services, go deep into why the Visual Studio Code ecosystem is designed to fracture, and the legal implications of this design then discuss future problems faced by the software development ecosystem if our industry continues as-is on the current path…
It’s funny because, I’m probably the minority, but I strongly prefer JetBrains IDEs.
Which ironically are much more “walled gardens”: closed-source and subscription-based, with only a limited subset of parts and plugins open-source. But JetBrains has a good track record of not enshittifying and, because you actually pay for their product, they can make a profitable business off not doing so.
Agreed. Their business model is transparent: we give them money, they give us good products
I did not understand anything
“Its MIT open source and anyone can use it!”
- But Microsoft only publishes a not-MIT licensed one
- And if you DONT use that one, the extension store created by microsoft wont work
- And even if you make your own extension store (which people did for VS Codium) you legally wont be allowed to use any of the de-facto quality of life extensions (Python, SSH, Docker, C#, C++, Live Share, etc)
- And those extensions default to needing fully-closed-source tools develped by microsoft
- AND, unlike Chromium, anything that tries to fork and build on top of VS Code, (e.g. gitpod; a web-based dev environment) will die because none of the de-facto/core/quality-of-life extensions people are used to will be available. They’ll have to use the Microsoft alternative (e.g. Github workspaces)
The MIT codebase is just bait
