4 ms·
I know it's a meme at this point but you just explained Embrace in 5 lines.
by abhinavk 3y ago
I know it's a meme at this point but you just explained Embrace in 5 lines.
- pjmlp 3y agoIt is not embrace when you can fork it. :)
- nix0n 3y agoThe steps are Embrace, Extend, Extinguish. 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.)
- rdudek 3y agoWhat would be Extinguish?
- DangitBobby 3y agoRemove, restrict, irrevocably alter, or up the price to your service which users have come to depend on now that free alternatives cannot compete. 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.
- pjmlp 3y agoTime to contribute another plugin for VSCodium.
- karmakaze 3y agoIs this any/substantially different than the open-core licensing models that seem to be fairly well received by many?
- margorczynski 3y agoSo basically like open-core OSS where you hook in people in on the open source part and then start adding bit by bit proprietary extensions until the OSS offering is noticeably subpar to the closed one.
- btown 3y agoOne of the things that comes to mind here is the fact that the default Python extension for VS Code is, perhaps surprisingly to many, not open source. https://github.com/microsoft/pylance-release https://github.com/microsoft/pylance-release 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_extinguish 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-file#re-implementing-pylance-exclusive-features 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!)
- pjmlp 3y agoThere are other Python plugins, freedom of choice, isn't what FOSS is all about? After all that is what everyone claims about Chrome forks.
- orbital-decay 3y agoThere's a vast difference between a technical fork and a meaningful fork.
- pjmlp 3y agoIf it goes for Chrome with Google, also goes for Microsoft.
- dralley 3y agoWhich is meaningless. Embracing open source software is a _good_ thing. Extending open source software / standards with proprietary additions is the only aspect which is deserving of criticism.
- oneplane 3y agoThat's all fun and games until you find out the final stage is extinguish.
- dralley 3y agoExtinguish isn't a thing you do, it's the intended consequence of step 2.
- bguebert 3y agoI feel like that's already happening with the integration of the issues tracker and the CI/CD actions into github. A lot of newer developers just see github as git instead of realizing there is git outside of it that can be run locally without needed a cloud service backing it. They might not even see a reason why they would want to have control over their own code hosting until microsoft starts squeezing them hard.