6 月 16 日，微软项目经理 Tim Heuer 公布了 VSCode C# 扩展的路线图更新，新的路线图引入语言服务器协议(LSP) 作为 VSCode C# 扩展的基础通信机制，并计划创建一个新的“LSP Tools Host”组件作为新版 C# 扩展的基础，以引入更多实用功能。但微软在公告中称 “LSP Tools Host”组件将不开源，该决定随即引发了大量批评。
八年前， OmniSharp 团队用当时的 API 和协议开发了 VS Code 中的 C# 扩展。如今语言服务器协议 LSP 已成为现代开发工具（编辑器、IDE 等）相互交流的标准机制，因此微软打算将 C# 扩展切换为完全使用 LSP 进行通信，并计划更新现有的 OmniSharp 组件，使它们也以 LSP 进行通信：
（这里要提一句，创建 C# for VSCode 扩展的 OmniSharp 团队虽然有很多微软的员工，但该团队由社区驱动，并不属于微软，也就是说微软正在收编由社区开发的 C# 扩展，把它的发展路径掌握在自己手中。）
利用 LSP ，将使我们能为 C# for VS Code 扩展带来创新的功能。包括提供高级功能，以及在某些情况下提供闭源体验，例如 IntelliCode。
我们计划创建一个新的“LSP Tools Host”组件，它将 Roslyn 和 Razor 等开源组件与闭源组件集成在一起，提供了更广泛的功能。
“LSP Tools Host” 将成为 C# for VS Code 扩展的默认体验，现有用户可以在现有的开源 OmniSharp 驱动系统和新的“LSP Tools Host”之间进行选择，后者将提供一些额外功能（比如闭源功能）的访问权限。
“LSP Tools Host”不会开源，但我们计划在此过程中与社区进行沟通，以帮助指导我们未来的计划。
简而言之，采用 LSP 通信机制之后，这个新的 LSP Tools Host 组件将是新的 C# for VS Code 扩展的默认功能包，会捆绑更多“开箱即用”的功能。也许是因为这个组件引进了一些闭源的功能模块，所以社区用户可以帮忙开发，但它不能开源。
这则公告毫无疑问地被冲了，用户纷纷质疑为什么新的组件不能开源，指责微软“回到过去那个封闭的、利益至上的微软”：
面对众人对闭源的质疑，微软项目经理 Tim Heuer 更新了公告，进一步解释了 “LSP Tools Host” 组件不开源的原因：
Razor 和 C# 的 LSP 实现将保持开源（Roslyn 和 Razor）。VS Code 的 C# 扩展 (ms-dotnettools.csharp) 本身也将保持开源。
这个新的 “LSP Tools Host” 组件只是开源和闭源功能之间的桥梁，让我们可以同时提供这两种功能。
但有一说一，这个说法似乎不太能服众，毕竟路线图写得明明白白： “LSP Tools Host” 将成为 C# for VS Code 扩展的默认体验，现在则称其只是一个“桥梁”......
前车之鉴
其实，在 C# 扩展之前，微软对 VSCode 的语言扩展就有过收编再闭源的操作 。用户 Pradyun Gedam 指出：此前 VSCode 的 Python 扩展在开源解决方案 Jedi 的支持下普及，然后微软将其收编，并构建了一个基于 LSP 的闭源 Python 扩展 pylance，承诺提供更好的用户体验。
然后微软就将闭源的 pylance 设为 Python for VS Code 扩展的默认方案（甚至推送提示，让用户切换到该扩展），同时不断地减少对开源部分的资源投入。如今，使用 Pylance 的 Python 扩展比 Jedi 多太多功能，以至于用户只能选择闭源的 pylance 扩展。
用户 Gerard Smit 对此进行了总结：“拥抱、延伸和熄灭。”这三个词指先拥抱开源，让社区力量为其提供更完善的功能；然后再对该功能进行“延伸、扩展和改善”，随后再闭源并强推“延伸”之后的新功能，“熄灭”原有的由社区驱动的开源功能。