一个早在多年前就已经“开源”的项目，如今却又宣布要“真正开源”？微软这是玩了个什么梗？
一直以来，微软都高举着「微软 ❤️ 开源」的大旗，，其确实放出了不少成果。但这回惹出争议的，却是那个本就已经挂在 GitHub 上多年、定义为Windows 系统现代 UI 框架的WinUI。
事情的起因要从微软首席软件工程师 Beth Pan 最近在 GitHub 上发的一条公告谈起，其表示 WinUI 正在“逐步迈向真正的开源协作”。这话一出，不少开发者困惑地表示：“你不是早就开源了吗？怎么现在又来一次？”
更有些讽刺的是，紧随着这条公告的是一则 17 个月前某位开发者发起的讨论帖，标题就写着：“WinUI 3 已死，我们什么时候能等到公告？”这条帖子至今已经累积了超过 580 条评论，成了社区对项目进展停滞的不满集中出口。
说到底，开发者对 WinUI 的失望情绪早已堆积多年。如今微软喊出“真正开源”的口号，是要真诚转身拥抱社区，还是自己已无暇顾及以此呼吁更多的外部开发者投入进来？这个问题，也许比 WinUI 本身还值得关注。
简单来看，WinUI 是微软推出的现代原生 UI 框架，主要用于构建 Windows 10 和 11 上的桌面应用界面，也延续了过去 UWP 的一部分技术路线。它提供了完整的控件库和样式支持，遵循 Fluent Design 设计体系，让开发者能打造更现代、统一的 Windows 应用界面。
微软将其定位为“Windows 的现代原生 UI 平台”，并将其集成进部分系统级应用中，如“设置”界面等。它还支持 React Native for Windows 等新式开发方式，是微软推进 Windows 应用生态现代化的重要工具之一。
打开 WinUI 的 GitHub 地址（），我们发现，其连 Star 数量都有了 6.8k——那微软现在说的“未来将真正开源”到底是什么意思？
其实此番Beth Pan 发布的公告在标题中写道——“WinUI 开源更新：逐步推进开放合作”，在外界看来，他们是想改变WinUI 的开发流程，尤其是如何管理他们自己的 GitHub 仓库（repo）。
目前这个仓库只是他们内部代码的一个“定期同步副本”，也就是说微软的工程师实际上还是在内部仓库开发，GitHub 上的只是他们不定期更新出来给人看的。
而他们接下来想做的是：让 GitHub 上的仓库变成主要开发仓库，所有开发者（包括微软内部和外部）都能直接在上面提代码、做贡献。
至于何时能兑现这个承诺，微软首席软件工程师 Beth Pan 坦言自己也说不准，其只是表示：「关于“真正开源这个代码库”的问题，很多人都提出了疑问。虽然我们现在还无法承诺完成所有里程碑的具体时间表，但可以明确告诉大家，我们正在积极推进中。这不会是一个“一键切换”的瞬间，而是一个循序渐进的过程。」
正如上文所述，大部分 WinUI 代码只是定期镜像同步到 GitHub，主仓库仍是微软内部私有的。在公告中，Pan 列出了开放这个仓库的四个阶段：
在 Windows App SDK 1.8 发布（8 月底）之后，微软将开始更频繁地把内部提交同步到 GitHub，以提升透明度，并展示项目的最新进展。
外部开发者将可以克隆仓库并在本地进行构建，我们也会提供文档来指导环境配置和依赖项管理。
贡献者将可以提交 PR，并在本地运行测试。微软正在努力剥离私有依赖，并将测试基础设施向社区开放。
GitHub 将成为开发、问题追踪和社区互动的主要平台。内部仓库镜像将逐步淘汰。
她表示，“这一过程之所以复杂，WinUI 与 Windows 系统有着深层次的耦合。部分代码直接依赖于无法公开的专有底层组件。我们正在努力将可共享的部分与不可共享的部分拆分开来——这项工作仍在进行中，需要一定时间。”
Beth Pan 还指出，“这项工作是与其他重要职责并行推进的，例如安全保障、平台稳定性和对现有产品的支持。目前我们的重点是在打牢基础，让贡献者真正能参与进来，同时提升整个项目的透明度。我们也在确保这项工作与微软更广泛的业务战略保持一致，从而获得长期的支持与影响力。”
与此同时，她还呼吁，对 WinUI 3 有热情的开发者可以积极参与其中。“我们知道这可能还不是你们最想听到的全部内容，但希望这能表明我们是认真的，愿意把这件事做好。”
对于此番声明，也有不少开发者并不买账。有人觉得微软在开发 UI 的技术路线上太过“善变”。
Win32（1985）：是 Windows 的内置 API。使用它可以创建按钮、窗口、滚动条、调用系统 shell、通用对话框等，而且生成的界面看起来和行为上都像原生窗口。虽然年代久远，但它可以用 C 语言访问，至今依然可用。
MFC（1992）：是对 Win32 的一个 C++ 封装，使 API 使用起来稍微简单一些。微软目前仍然对 MFC 进行小幅更新，它至今依然被广泛使用。
WinForms（2002）：是 Win32 的封装，供 C# 等 .NET 语言使用。目前处于维护状态，不再计划加入新特性。
WinUI 3（2021）：与 WinUI 类似，但将 UI 框架从操作系统中剥离，变为独立库。也就是说，你的应用即便运行在未更新的系统上，也能使用它。
每隔几年，微软都会推出一门新技术，用来取代旧有方案，但很多最终被部分或完全放弃。他们更换了名字，改了做法，让不少开发者一头雾水。当然，“善变”只是其中一层因素。
另一方面，基于 WinUI 3，当年微软还搞了个整合项目，叫 Project Reunion，用来打破开发者之间的“代沟”，不管你是老派的 Win32 派，还是押宝 UWP 的“新势力”，都能在这个框架下使用。
然而近来不少开发者涌入社交媒体，吐槽 WinUI 3的不开放， 甚至有人直言：“连微软自己的都不用，还指望社区用。”
我的建议是：别碰 WinUI 3.0，现在体验还是很烂，比以前的 UWP 还差，而 UWP 本来就没比 WPF 好用到哪儿去。
当初那些社区里关键的大佬们，现在不是跳槽去竞争对手了，就是被调去微软其他部门了。
你可以自己去看看微软在 GitHub 上公开的项目仓库，看看里面的问题报告和提交活跃度，啥情况一目了然。
或许是看到了大家的反馈，Beth Pan 在此次公告中也写道，“感谢你们的所有反馈、问题和建议。我们已经充分听到了大家的声音，并且正在认线 个月，我们将进入一个专注改进的新阶段，包括产品层面的优化和一些基础性变更，以支持一个更加开放和协作的未来。”
Pan 的开源声明引得部分开发者的认同——“欣慰 WinUI 依然活跃，并且背后有人关注”，但更多的人对微软是否会真正投入足够资源、建立开发者信心持保留意见。
坦白说，我不认为微软意识到了他们对布道者、广大开发者社区，甚至那些投入使用 WinRT→UWP→WinUI/WASDK 的公司所造成的伤害。持续不断的停滞和虚假承诺已经令人筋疲力尽。到现在我们连输入验证都还没有一个可用方案，像模态对话框这种最基础的东西依然有各种 bug——这样的限制之下，企业级应用（LOB）到底要怎么运行？
我们公司从 Windows 3.0 时代就开始做 Windows 客户端了。现在我们已经不再优先考虑 Windows 平台开发了，原因很简单：缺乏透明度、缺乏进展、缺乏责任感、缺乏明确方向。
如果从 Win8 时代的初始形态算起，WinUI 也有将近 15 年历史了（我甚至怀疑它的一些部分可以追溯到 XP 时代的 DirectUI），而它与 Apple 的操作系统相比，已经落后了几个数量级。为什么 Apple 能快速迭代并持续带来新功能，而 WinUI 却仍然充满缺陷和 bug？。
到现在差不多 18 个月过去了，开发者对微软的不透明和失联状态已经彻底失望。大家都在说：“WinUI 3 真的已经死了！” 这个问题是在 2024 年 3 月提交的，下面已经有 580 条评论了，为什么拖到现在才有人回应？
这次所谓的“方向转变”到底和过去几年说过的那些“我们会有所不同”有什么不一样？又会不会真的带来实际进展？
请原谅我有些愤世嫉俗——我真心希望这个项目能够成功，但就我这些年看到的情况而言，我实在不抱太大希望。
另一位开发者甚至表示：“整个 WinRT（包括后续的 WinUI）从一开始就是个错误。”他提到，Windows 开发生态的分裂始于微软在 Windows 8 中引入 WinRT，以及通过“语言投影”让 C++ 和 .NET 语言互操作的做法。
说实话，这看起来就像是把 WinUI 剩下的部分外包出去，而我只能祝那些仍然相信微软对 WinUI 是认真的人好运了。你们从来没有认真对待过，自 Windows 8 以来，那一整套工具链和重写的成本到底有多高，而这也彻底耗尽了 Windows 开发者社区原本对微软的好感。现在几乎没有任何理由，能让一家企业愿意把 WinUI 作为其新应用的基础。到今天为止，它甚至还没能达到 UWP 当年的功能水平。
WinUI 开源虽然是一个积极的信号，但更关键的还是微软愿意投入多少资源来真正支持它。“到底有多少人是专职在做 WinUI 或 WinAppSDK 的？”另一位开发者提出质疑，“现在给人的感觉是，微软的重心已经完全放在 Web 上了，其它东西都只是维持现状而已。”
业务咨询
扫码，关注我们
