.NET的第三方软件问题

很多时候，.NET是我的首选平台。它通用，一致，工具齐全。是的，我们对于C#的创新很兴奋，并且时不时会有很好的技术出现（当前的Blazor或者久远的silverlight）。但是，如果一个NB的开发者说“.net是给在银行工作的人用的”，好吧，他们说的也没错。

有时候事情变得无聊并没什么错，毕竟业务程序遍布世界各地。但是，当企业使用微软的技术，并且这些技术成为一种阻碍的时候，就是一个问题了。并且这种问题在开源软件世界尤为明显。

问题是这样的。今年（2020年），微软成功地从闭源，以windows为中心的 .net framework，转移到了跨平台的.NET5，基本上是在飞的同时重建了他们的开发引擎。这是一个很有野心的宏大的计划，伴随着 .NET Core第一个版本的声明。

但是.NET5仍然生存在微软独裁的生态系统中，开源项目仍然被怀疑和观望，社区也只在边缘参与。相较于其他流行的平台，.NET是一个顽固的独苗。如果这种情况不改变，我们将为了短暂的安全牺牲未来。

文化问题

.NET生态脆弱的生态系统原因有很多，并且大部分指向微软。微软Principal Program Manager(应该是项目经理的最高级别) Immo Landwerth 汇总了一些问题：

历史上，我们教导用户期望所有的功能都来自微软。因为我们不能做所有的东西，尤其是无法跟上开源生态的步伐，所以 .NET受信程序集必须超越微软独立成长

如果你已经工作在 .NET平台上，你就知道这种愿景和当前的文化相去甚远。今天，大多数 .NET开发者仍然使用微软的组件和他们自己的轮子构建项目。他们使用微软规定死的技术栈而不是自己选择工具。这几乎是一个与生俱来的问题。

相较于JavaScript，即使是最简单的项目也可能使用一大堆第三方库，不同的构建框架相互竞争也能和平共处。这种混乱的情况确实会有一些成本，但是同样带来巨大的好处。因为JavaScript的开源项目生态不仅填补空白，也驱动开发者的热情、提高参与度、在参与者和使用者中传播专业知识。这与 .NET生态有着巨大的不同，每个开源项目都在为得到更多关注努力奋斗。

信任问题

当微软描述问题的时候，他们经常描述为一个信任问题，比如，“我们如何使人们信任第三方产品？”这个问题是一个核心的事实，但它也隐藏了一个真实的问题。开发者的信任不仅仅是质量的问题。大多数 .NET开发者不会因为质量位置而回避第三方解决方案。他们害怕今天看起来像是 .NET生态中的创新技术明天就会过时，因为微软经常改变方向。 在微软的强力控制和经常急转弯的臭名声（即使是他们自己的产品也一样）的双重裹挟下，业务开发者们为了规避风险变得异常保守。

对开源贡献者和捐献者最大的威胁是微软会突然抛出自己的解决方案。Paul Stovell，Octopus Deploy 创始人，指出：

如果微软想要构建一个文档数据库，一个消息框架，一个单元测试框架或者一个自动部署工具，他们只需要做到其他人的十分之一，对话就会立刻变为“我们为什么用你的产品而不是微软的？”微软变成了默认选项，及时他们是最后进场的。

这个问题不只停留在理论上，Stovell 就在Build大会上被问到过“为什么是你而不是微软”的问题，这样的转折发生在微软在几分钟前刚刚宣布了他们的竞品。另一个这样遭遇发生在AppGet身上，微软曾经支持它，然后又用自家的官方产品灭了它。

即使微软没有竞争者，仅仅是这种可能性就够开发者喝一壶。想想 .NET MAUI的处境，MAUI是微软用来整合桌面和移动app的一个项目。这个项目的发布至少要一年后，但是它仍然让对Uno Platform感兴趣的开发者犹豫了一下，因为一个解决相同问题的开源解决方案在当前是可用的。

即使是官方背景的解决方案也面临相当难的处境。看看有着高曝光率、被吹捧的很NB的Xamarin项目，直到它被微软收编都在艰难的活着。微软不可能收编整个生态，就算能，一个只有微软的世界也是“楚门的世界”。微软的解决方案不仅仅杀死了竞品，也扼杀了开源创造者的动力。他们觉得，在一个他们控制不了又或者充满未知的环境花时间是不值得的。仁慈的独裁者仍然是独裁者，可以随时弄死你。

这是真实存在的信任裂缝。它不是存在于 .NET开发者和开源软件间的，是存在于社区和微软之间的。这陷入了恶性循环，较少的确定性意味着较少的人愿意为开源解决方案贡献力量，也意味着这些项目进展缓慢，远远落后于整个社区，或者干脆消失不见了。

不要选择赢家或输家

一个好消息是微软认识到了问题。他们已经成立了一个工作组去讨论 .NET生态系统成长挑战的问题。他们也发布了一个有影响力的白皮书，声明这个问题“我们要使这种实践常规化，让应用开发人员使用非微软控制的第三方库。”

但是微软的阴影太大了，如何去管理生态系统，而不是拥有它再扼杀它？在过去，微软在成熟度阶梯上尝试了背书和认证的想法，试图从保证质量来提升信任，但是结果往往相反，这种做法使得不到关注的初创项目更加边缘化。

微软的最佳切入点是支持贡献者，而不是选出胜利者和失败者。微软应该更好的支持开源开发者，在文档方面提供支持，引导开发者关注质量问题，在开发者社区中支持他们。给与开发者更清晰的长期规划路线图。赞助雇员维护哪些流行的第三方库。不需要去创造成功的项目，给第三方提供一个通往成功的平台就好。

最后，社区项目会驱动平台开发者的热情，如果没有这种激情，开发者生态就没办法健康成长。微软现在的产品可能不需要开源软件，但是微软需要开源开发者赢得未来。

原文链接

https://medium.com/young-coder/net-has-a-third-party-software-problem-45d24cdc30c9