前段时间，微软从开源 .Net 6 删除一项功能特性，使得专业开发人员唯有改用昂贵但功能强大的 Visual Studio 2022。开源社区对此表示愤怒。
不但如此，就连微软公司内部的开发者都同样气愤，微软随后撤销删除行为的决定（https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/）并未能安抚他们，许多人担心，微软下次仍会将其短期财务利益凌驾于内部员工与开源社区的交互之上。
于是就有人写了一封匿名信（https://pastebin.com/RF6015kv）给微软管理层，作者直接指责微软公司为了保护管理层而撒谎。
他们指出，微软在 .Net 6 开发人员能够发表留言之前，故意试图透过紧急推送 Pull Request 来隐藏这个删除热加载的行为，此外，微软所讲的“他们无法对 .Net 6 和 VS 2022 的热重载功能同时保持注意力”实际上苍白无力空洞，没有迹象表明这两者无法同时做好。
尽管开源工具其实也在微软内部很受欢迎，但他们还是担心微软会进一步努力削弱 .Net 6 以便能够强力推进 VS 2022。
作者要求发起透明的调查，查清楚微软的管理层为何会作出这种删除热加载功能的更改决定，好让此类草率决定不再出现。
尽管有些尖锐的措辞让许多人怀疑这封匿名信不是真的，但已经有一些微软 MVP 站出来证实，这封信确实是由 DivDev 部门的一名微软员工所写的。
以下是匿名信全文（中文翻译版）：
致微软开发人员部门领导
我们这些在微软开发人员部门（DevDiv）工作的人希望针对近期围绕着 dotnet 6 的“dotnet watch”功能删完又恢复的争议作出回应。虽然我们庆幸冷静的头脑占了上风，“dotnet watch”功能保留了下来，但相对应的，我们并不觉得这种状况不会再次发生。
为了明晰这一点，我们来看看斯科特·亨特（Scott Hunter）最近的博客文章（https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/）。根据我们对近期事件所知，以及对开发者部门日常运作的了解，斯科特所写的内容只有一小部分是真的，文章内容跟发生过事情相矛盾。事先声明，这里并不是在攻击斯科特·亨特；恰恰相反，这表明了其他人愿意在多大程度上保护管理层。
「作为一个团队，我们致力于让 .NET 成为一个开放的平台，并在开放的环境中做着我们的开发。事实上，我们从一开始就决定默认在开放的姿态下开发热重载功能，就能证明这一点。」
这跟 Pull Request 删除代码的行为无关。我们在一篇博客文章中就已经提及过了（https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/），还有不透明地急忙推送 Pull Request 来躲避留言。明明根本就不透明，我们怎么能说我们是透明的呢？这就像是，我们明明全都知道这是错的，但无论如何还是得继续走下去。
「绝大多数 .NET 开发人员都在使用 Visual Studio，我们希望确保 VS 能给 .NET 6 带来最佳的体验。」
就算确实是这样，那是否意味着我们不关心不使用 Visual Studio 的用户？在开发过程中这么晚了才删除这项功能，又如何让 Visual Studio 拥有最佳的热加载体验？这简直是侮辱那些不怎么用 Visual Studio 做 dotnet 开发的人，这就是说，我们理解不了使用了我们产品的客户们、甚至理解不了使用了我们自家产品的微软员工。
我们既用 CLI，也用 VS Code。麻烦别再装了。
「我们在执行这个计划时犯了一个错误。在我们尽力的范围内，我们无意中删除了源码，而非仅仅不去调用这部分代码路径。」
坦白说，把这个"错误"归咎于工程师，这做法跟个懦夫没区别。删掉了该功能才是问题所在，跟代码如何执行并没有关系。那是不是说，如果我们仅仅是“关掉它”，而不是删掉它，我们就没必要撤回更改？这代码到底是会继续拿去用，还是放着让它烂掉？
「随着.NET 6和Visual Studio 2022 的发布日期越来越近，我们选择先把热加载引入到VS2022。」
为了表明这次"dotnet watch"事件跟“品控”无关，我们把它跟我们推迟的另一个产品作比较：MAUI。
MAUI粗糙简陋。从RC1就能清楚地看得出，在dotnet 6发布的时候，MAUI的品质仍然不够高：有太多的东西等着修复，但时间又不够。MAUI团队及其合作伙伴把这些问题告诉给了领导层，从而让这款产品推迟到明年年初。
到目前为止，仍然没有迹象表明“dotnet watch”的处境相同。无论是看遍 Github 的 Issue 页，又或者是 dotnet 团队的待办事项，都找不出任何有关“品控”方面的担忧。恰恰相反，其实是做得还好。如果真的存在质量问题，这些问题一早就会提出来了，而不会等到在发布前三个星期才说。
「其实跟许多公司一样，我们正在学习如何在开源社区的需求和成为 .NET 企业赞助商之间取得平衡。」
如果我们在字里行间咬文嚼字，那么可以认定这段声明说得没错。我们全身心投入 dotnet、Visual Studio 还有 Visual Studio Code，这都相互有冲突。让热加载功能以“增值功能”只存在于 Visual Studio 当中，锁死在付费产品当中，那么就没什么理由转而使用 VS Code。从冷冰冰、精打细算的角度来看，这完全说得通，同样也简直不合理。
如果专门给 Visual Studio 做热重载开发的团队成员把“dotnet watch”集成到他们的产品，该怎么办？如果领导层在发布前几周取消了这些功能，又怎么办？这又能够怎么样、从哪里可以改进得了 Visual Studio？难道我们继续从 CLI 中删除组件，因为我们害怕失去 Visual Studio 的收入？
我们得以构建出顶级的 Visual Studio，靠的是拥有地球上顶级的 runtime。每当 Visual Studio 团队给 dotnet 基础设施添加功能特性，我们就拥有一致的基础，让每个人都用上、贡献代码。我们可以透过 runtime 中的合作构建出顶级 IDE，而不是让我们的各种开源产品变得更糟糕。
那接下来呢？难道我们要让 Omnisharp 变成闭源产品？好让我们可以确保它无法获得取自 Visual Studio 的有“价值”的新功能？这样我们就不会把功能特性带给 Rider 了吗？这又哪能帮得了我们？跟市场上的其它产品相比，领导层的这些决定确保 Visual Studio 永远都是二流产品的地位。像这样的举动不但让我们和客户很受伤，还让我们内部构建产品很受伤。他们不仅仅利用“开源社区”伤害我们，还伤害了开发者部门和微软的每一个人。
如果对此我们想要真实的透明度，我们应该作出这些改变，让事情走向正轨：
我们需要完整的时间线，公开地发布，有关这一切是怎样发生的，还有那些直接负责人是怎样弄到这个地步的。
我们再也不应该急急忙忙地推送 Pull Request。从一开始就很清楚，删除代码的行为是错误的，如果我们确实想从社区得到反馈，那么我们必须愿意倾听，不是事后再听，而是事前就听。
如果这些决定是由领导层的人单方面作出的，那么我们需要防止这种情况再次发生。Visual Studio 的“需求”和 dotnet 的“需求”之间存在着明显的利益冲突。需要有这样的制衡，以防止任何人，无论他们的地位有多高，在没有来自部门内外的真实反馈的情况下做出这样的决定。
在这里，我们的目标并不是为了侮辱领导层中作出这种决定的具体某个人。相反，这是为了解决核心问题：谁也无权拥有如此大的权力去直接影响像 dotnet 这样的差不多要发布的产品。领导开发部门的随便某个人都可以做这种事，我们需要防止这种情况发生。构成 Visual Studio 的各个组成部分的基础产品，需要有明确的指导方针来保护，这不仅会让我们成为开源软件中的好管家，还可以帮助我们构建出我们能做得出的顶级 IDE。
