The headline of this is a bit counterintuitive: many people, when they see the word "fracture," might imagine an ecosystem in which different offerings can coexist. Someone not reading the full article might even think this implies that VS Code might even "break apart" into many open-source forks, which would be a good thing.
But the word "fracture" is very much meant in a different context here, in that Microsoft does not allow its proprietary extensions to VS Code to be used legally by any third-party fork, and thus can leverage the unique and unstandardized behavior of e.g. its closed-source Pylance Python language server to ensure that no fork can replicate the experience (glitches-as-features and all) that practically all users of VS Code will expect, thus giving forks a Sisyphean challenge to overcome.
https://visualstudiomagazine.com/articles/2021/11/05/vscode-... is linked in the OP and discusses the surprise the community felt when VS Code transitioned to Pylance. I'd venture to say that most users of VS Code have no idea how much of their Python editing experience is run by closed-source logic.
On one hand, it's a bit frustrating that many people, myself included, switched to VS Code from other IDEs because "if the community sees a problem, the community has the tools to fix it and will do so." But that ceases to be true when the bulk of the IDE's power comes from closed-source language servers that Microsoft could feature-freeze (or deallocate resources from them) at any time, and still have ~years before any community language server could begin to replicate all the edge-case behaviors of their closed-source extensions and gain notoriety as a better alternative to Microsoft's defaults.
Is this a bad status quo, though? Microsoft's invested incredible resources in a stellar user experience to date, and might not have done so if it didn't have this strategy in play - a strategy that ensures that no fork will ever be able to capture developer mindshare, and that ensures that the larger Microsoft ecosystem of services will never be disadvantaged or de-promoted by such a fork. As long as leadership desires to continue making this advantage larger and larger, and have Microsoft developers dogfood their own IDE, and thus continue to invest in their language servers, most users will benefit. And sure, some of us will need to keep typing "# type: ignore" into our codebases to work around a Pylance bug that nobody can see the code to submit a PR to fix... but we gain so much in return for that inflexibility. I'm more interested in how my IDE helps me to make my own visions into reality, than in the purity of whether it can truly be called "open source."
> the bulk of the IDE's power comes from closed-source language servers
Not sure that's so very true for most langs / stacks other than Python. Go LSP & vscode extension is Go-owned, C++ you have clang LSP+ext and can really skip MS' offering(s) there. TypeScript LSP+ext is most likely OSS (dunno) or else MS-owned anyway; dotnet same. Niche langs own their LSP+exts anyway. The builtin HTML / CSS stuff is bare-bones IIRC, if there aren't richer OSS alternatives out there yet there sooner-or-later will be. Python, I wouldn't know, but let's face it, if a lang is a big FOSS project it can and will mobilize their own owned and ever-more-excellent LSP + ext if and when necessary / desirable — and if it's niche and small-scale, MS won't anyway, proprietary or not.
But the word "fracture" is very much meant in a different context here, in that Microsoft does not allow its proprietary extensions to VS Code to be used legally by any third-party fork, and thus can leverage the unique and unstandardized behavior of e.g. its closed-source Pylance Python language server to ensure that no fork can replicate the experience (glitches-as-features and all) that practically all users of VS Code will expect, thus giving forks a Sisyphean challenge to overcome.
https://visualstudiomagazine.com/articles/2021/11/05/vscode-... is linked in the OP and discusses the surprise the community felt when VS Code transitioned to Pylance. I'd venture to say that most users of VS Code have no idea how much of their Python editing experience is run by closed-source logic.
On one hand, it's a bit frustrating that many people, myself included, switched to VS Code from other IDEs because "if the community sees a problem, the community has the tools to fix it and will do so." But that ceases to be true when the bulk of the IDE's power comes from closed-source language servers that Microsoft could feature-freeze (or deallocate resources from them) at any time, and still have ~years before any community language server could begin to replicate all the edge-case behaviors of their closed-source extensions and gain notoriety as a better alternative to Microsoft's defaults.
Is this a bad status quo, though? Microsoft's invested incredible resources in a stellar user experience to date, and might not have done so if it didn't have this strategy in play - a strategy that ensures that no fork will ever be able to capture developer mindshare, and that ensures that the larger Microsoft ecosystem of services will never be disadvantaged or de-promoted by such a fork. As long as leadership desires to continue making this advantage larger and larger, and have Microsoft developers dogfood their own IDE, and thus continue to invest in their language servers, most users will benefit. And sure, some of us will need to keep typing "# type: ignore" into our codebases to work around a Pylance bug that nobody can see the code to submit a PR to fix... but we gain so much in return for that inflexibility. I'm more interested in how my IDE helps me to make my own visions into reality, than in the purity of whether it can truly be called "open source."