4 ms·

> MS is embedding themselves in the open-source community in such a way that it's almost unavoidable to make use of their proprietary tools without even realiz

> MS is embedding themselves in the open-source community in such a way that it's almost unavoidable to make use of their proprietary tools without even realizing it Try removing the word "proprietary" from that strategy, and see if it still fits the evidence you see. Or replace it with "paid". Look at their earnings reports (https://www.microsoft.com/en-us/investor/earnings/FY-2020-Q4/press-release-webcast https://www.microsoft.com/en-us/investor/earnings/FY-2020-Q4...). Licensing proprietary software is a small and shrinking piece of the pie, they don't even segment that way anymore in fiscal reports. They are (successfully) pivoting to become the Enterprise cloud service provider, and tightly integrated tools are an important part of that picture. Licenses simply aren't. So it's not "commercial office365", it's "commercial office365 and cloud", because o365 has tightly integrated Azure services and the revenue is tracked together. Which parts are OSS licensed is irrelevant, because that's not a primary revenue driver anymore. A good example is the fastest growing service on Azure, AKS. 100% open source, even the implementation down to bare metal. They don't care about keeping it proprietary, because they make the same money with it either way.

skohan 6y ago
Let's imagine that a few years from now, MS starts advertising Azure right inside VSCode, and they start releasing features which favor Azure integration, and actually cause problems when working with GCP. Now imagine I as a developer want to pick up shop and move to another editor, but it turns out my workflow depends on proprietary extensions which are only available on VSCode, and my velocity will be cut by 70% if I switch editors. If MS owns the interface most developers have to their code, there are all kinds of ways they could leverage that to your disadvantage.
- ta8594505930 6y ago
  In this scenario would you be relying on a proprietary extension to interact with GCP developed by Microsoft? Surely you would want to use a Google or Third-party developed extension to do that right? And in that case the developer of that extension would have a vested interest in making it available to you again, potentially in a forked version of VS Code. As long as the editor is open source extension developers can just fork it and create a new public directory of extensions. The only thing you potentially lose is Microsoft's proprietary extensions which are likely to always work well with Microsoft products and you really shouldn't use them to interact with Microsoft's competitors.

skohan 6y ago

Let's imagine that a few years from now, MS starts advertising Azure right inside VSCode, and they start releasing features which favor Azure integration, and actually cause problems when working with GCP. Now imagine I as a developer want to pick up shop and move to another editor, but it turns out my workflow depends on proprietary extensions which are only available on VSCode, and my velocity will be cut by 70% if I switch editors. If MS owns the interface most developers have to their code, there are all kinds of ways they could leverage that to your disadvantage.

ta8594505930 6y ago
In this scenario would you be relying on a proprietary extension to interact with GCP developed by Microsoft? Surely you would want to use a Google or Third-party developed extension to do that right? And in that case the developer of that extension would have a vested interest in making it available to you again, potentially in a forked version of VS Code. As long as the editor is open source extension developers can just fork it and create a new public directory of extensions. The only thing you potentially lose is Microsoft's proprietary extensions which are likely to always work well with Microsoft products and you really shouldn't use them to interact with Microsoft's competitors.