北京时间 6 月 16 日，微软首席产品经理 Tim Heuer 在 Github发布帖子称，微软将在 Visual Studio Code 中引入 C# 的闭源扩展，作为现有开源 OmniSharp 的替代方案。
Heuer 表示，语言服务器协议(LSP) 如今已成为现代开发人员工具相互交流的标准机制。将 C# 扩展迁移到 LSP 将有助于创建可扩展且灵活的工具环境，该环境可以轻松地将新体验集成到 VS Code 中的 C#。
“这是让人无法接受的平台管理者权力滥用行为”
众多开发者对微软“LSP 工具主机”封闭源代码的行为表示不解。“缺乏正当理由会加深问题，这种对开源项目的拉扯根本不受欢迎。”
目前，微软管理着当今两个最流行的开发环境：开源的 VS Code 和专有的 Visual Studio。虽然 VS Code 是完全免费的，但一些开发者认为产品的部分关键扩展却不是。
同样地，虽然 .NET 运行时和编译器平台是开源的，但 .NET 调试器不是。每当调试器运行时都会出现如下警告：“您只能在 Visual Studio 代码中使用 Microsoft .NET 核心调试器 (vsdbg) ，Visual Studio 或 Visual Studio for Mac 软件可帮助您开发和测试应用程序。”
以 Gnome、Mono 和 Xamarin 闻名业界的 Miguel de Icaza 对微软这一行为强烈反对，他在推特上表示，“微软为了继续封锁 .NET 而强行加入了一个专有扩展，从而颠覆一个活跃的开源项目，这真的很令人失望。这是让人无法接受的平台管理者权力滥用行为，也是对社区的背叛。”
开发者 Muhammad Azeez 表示，虽然 VS Code 中的加入 C# 扩展很受欢迎，但新的 LSP 不开源则是一个奇怪的决定。如果仅仅是关于 IntelliCode，那么可以使 LSP 服务器实现可扩展且开源，再加上可选的闭源组件，如 IntelliCode。正如 GitHub Copilot 作为一个独立的扩展，在任何地方都可以使用， VS Code 中的 IntelliCode 也可以使用类似方式。况且由于 Copilot 的存在，或许 IntelliCode 在 VS Code 中也并不那么重要。
“这种行为让我为有一个 100% 依赖 .NET 的开源项目感到尴尬。微软拥有非常好的技术，不要再用这些落后的商业决策来消耗它了。”有开发者表示。
但微软似乎下定决心要为其工具保留商业优势，同时又想利用开源来获得反馈、贡献和采用。正如 Heuer 在帖子里说的：“LSP 工具主机” 不会开源，但我们计划与社区持续沟通，来帮助和指导我们未来的计划。
“当微软试图通过做出不利于用户的决定，以便在短期内攫取权力，或从现有的市场份额中获利时，它是如此悲哀和短视。”开发者 nyeogmi 感叹道。
面对诸多争议，Tim Heuer 更新了帖子回应道，Razor 和 C# 的 LSP 实现将像现在一样保持开源（Roslyn 和 Razor），VS Code C#扩展 (ms-dotnettools.csharp) 本身也将保持开源。同时，已经开源的部分仍然保持开源，并且还在积极的 OSS 开发中，这确保了 VS Code 之外使用 LSP 的其他人继续有权访问 C#。
“这个新的主机组件是开放和封闭源代码功能之间的桥梁，我们可以同时提供两者。”Heuer 补充道。
不是第一次
尽管如此，但微软这一行为确实又败了一波“路人缘”。实际上，这也不是微软第一次这样”搞事情“了。
去年 10 月，微软在即将发布的.NET 6 中悄悄删除了 Hot Reload 中的一个关键组件。Hot Reload 功能旨在帮助开发者在创建项目时随时获取即时反馈，并在更改代码后可以立即查看结果。相较于谷歌推出的竞争性 Dart 编程语言与 Flutter 工具包， Hot Reload 无疑颇具卖点，微软也一直希望能把这项功能推向.NET 与 Visual Studio。
但就在成果即将发布的最后一刻，微软突然决定把受众范围缩小至 Windows 与 Visual Studio 开发人员、不再开放跨平台版本。荒谬的是，微软之前一直在测试，并且非常接近最终版本的.NET 6 候选版已经允许开发者通过 donet watch 在各类环境及平台上灵活使用 Hot Reload 功能，其中包括颇具人气的 Visual Studio Code 开发环境。
根据媒体掌握的情况，该决定来自微软开发部门负责人 Julia Liuson。微软明显觉得这不是什么大事，却没想到激起了社区的愤怒回应。虽然微软最后迫于形势更改了决策，并给予了道歉，但依旧无法平息大家的愤怒。最后，.NET 开发者们 Fork 了一个开源分支。
创建者们表示希望能有一个不受微软控制的“Open.NET”社区，能让 .NET 完成向开放编程语言的过渡。他们强调，其它开源编程语言都是在开放环境中开发的，而不是像.NET 这样隔离大量开发人员进行黑箱操作。
当时，微软公司前 F# 团队雇员 Phillip Carter 坦言，“在查看源代码后，情况更加令人失望。相关支持代码共有 1000 到 2000 行，但却在发布前最后一刻被撤掉了。这显然是在开历史的倒车，Hot Reload 功能在设计之初也压根不属于 Visual Studio 独占。恐怕未来还会有更多类似的情况出现。”一语成谶，类似情况 8 个月后再次发生。
对业务收益的担忧
这一系列决定的背后，是微软对业务收益的担忧。开发者 Dustin Moris Gorski 分析道，微软的每个部门都需要有现金。DevDiv（开发者部门）的主要收入来源是 Visual Studio。.NET、VS Code、ASP.NET 等都是免费的，也不赚钱。支付 .NET 团队薪水的主要是 SQL 和 Visual Studio 许可证。
“出于这个原因，微软永远不会让一个免费、开放的 .NET 扩展为 VS Code 提供足够好的体验，来满足绝大多数 .NET 开发人员的需求。尽管微软拥有 C#、.NET、VS Code 和 OmniSharp，但与任何其他编程语言相比，VS Code 上的 C# 体验是同类中最差的，这并非偶然。这是为了推动开发人员使用 Visual Studio 的结果。”
另外，微软还需要紧紧抓住他们的 .NET 开发人员，因为 .NET 是 Azure 采用的主要驱动力。Azure 对任何其他开发社区来说没有什么吸引力，如果对标 AWS 或 GCP 的功能，成本几乎是其两倍之多。.NET 开发人员被巧妙地推送到了 Azure，并与微软其他产品隔离开来。
如今，世界在云上运行，而云基于 Unix 环境。微软已经感受到了传统以 Windows 为中心的开发人员逐渐迁移到 macOS 和 Linux 上。为阻止用户流失，微软试图给剩余的 Windows 开发人员提供足够的糖衣，让他们永远走不出 Windows/Azure 的藩篱。WSL、Windows 中新的类 unix 终端、Windows 容器等都试图让 Windows 人员使用 Windows，从而更接近 Azure。
“讽刺的是，如果你是一名软件开发人员，如果选择任何非 .NET 的编程语言，你会对微软的产品（GitHub, VS Code 等）有更好的体验，因为至少现在他们不会试图把你锁定在基于 Windows/Azure 的领域。”Gorski 说道。
微软备受争议的商业决策，甚至引来了内部开发人员的强烈反对。据悉，当初“删除 Hot Reload”一事也激怒了微软公司内部大批开发人员，以至于上峰下达了“禁止抱怨”的命令。当然，这种命令不仅无助于缓解事态、反而将大家的情绪推向高点。
实际上，微软虽然严格控制 .NET 平台的某些部分可能会有利于其开发工具（Visual Studio 和 VS Code），但也可能会减少大家对 .NET 的使用。
参考链接：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 1 条评论