While it's possible to fork VS Code, it is not possible to fork VS Code and provide a seamless onramp towards a Python editing experience that is fully open source, because users are used to the nuances of the closed-source Pylance experience in VS Code proper. You could use the minified/compiled Pylance plugin in your fork, but you'd have no way to expand its capabilities to new hooks your fork provides. Microsoft's development process would always be able to move faster than a fork, because it could coordinate VS Code internal API development with its internal Pylance team, and could become incompatible with forks at any time.
It's worth re-reading the quote from J Allard in https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... with this modern example in mind.
(Also worth mentioning https://github.com/detachhead/basedpyright?tab=readme-ov-fil... which is a heroic effort to derisk this, but it's an uphill battle for sure!)
After all that is what everyone claims about Chrome forks.
Embrace is the one you can fork.
Extend is the closed-source bits that connect to the open source stuff.
(For example, all the closed-source extensions to VSCode.)
For example: Pylance becomes a premium plugin, or VsCode is no longer downloadable and can only be run in the browser if you have a GitHub account, or VsCode only runs on Windows 11 machines, or VsCode requires an Office 365 account, or they fork VsCode and start adding heavy "telemetry" while simultaneously rapidly altering pylance and plugin APIs so free plugins and original VsCode can't keep up.
Extending open source software / standards with proprietary additions is the only aspect which is deserving of criticism.