.NET开源决策者潘正磊：什么样的成功情境才是开源的成果

发表于2015-04-10 14:06| 4308次阅读| 来源iThome| 27 条评论| 作者王宏仁

潘正磊 开源 .net 开源软件 visual studio

allowtransparency="true" frameborder="0" scrolling="no" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-04-10%2F2824450&type=3&count=&appkey=&title=%E6%BD%98%E6%AD%A3%E7%A3%8A%E4%B8%80%E6%89%8B%E4%B8%BB%E5%AF%BC%E5%BE%AE%E8%BD%AF%20Visual%20Studio%20%E5%BC%80%E5%8F%91%E5%9B%A2%E9%98%9F%E5%AF%BC%E5%85%A5%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%EF%BC%8C%E6%8B%A5%E6%8A%B1%20DevOps%20%E6%80%9D%E7%BB%B4%EF%BC%8C%E7%94%9A%E8%87%B3%E5%A5%B9%E8%BF%98%E6%98%AF.NET%20%E5%BC%80%E6%BA%90%E6%8B%8D%E6%9D%BF%E7%9A%84%E5%85%B3%E9%94%AE%E4%BA%BA%E7%89%A9%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1429065199122" width="22" height="16"> 摘要：潘正磊一手主导微软 Visual Studio 开发团队导入敏捷开发，拥抱 DevOps 思维，甚至她还是.NET 开源拍板的关键人物。

微软全球开发平台事业部资深副总裁潘正磊是微软核心开发工具 Visual Studio 和.NET 平台开发团队的领导人，1992年加入微软，从一位工程师做起，历练过多项微软全球性技术和管理职务，3年前也兼任微软亚太研发集团服务器与开发平台事业部总经理，同时管理美国与中国两地的微软研发团队，就连 C# 之父 Anders Hejlsberg 都是她的部属。

潘正磊一手主导微软 Visual Studio 开发团队导入敏捷开发，拥抱 DevOps 思维，甚至她还是.NET 开源拍板的关键人物。

1. 为何微软需要这么大的变革？

潘：原本大多是新创公司拥抱开源，但现在有越来越多大企业将开源视为战略的一环。开源商业模式也越来越完善，可以透过提供服务的方式来建立获利模式。软件的代码只是软件其中一小部分的价值，更大的价值要靠服务（意指云端服务）来实现。

我们的市场竞争者 Java 也因开源而受到欢迎。相比只靠内部.NET 开发团队的脚步，大量开源社区参与的创新速度可以更快，我们也有类似 Java 社区规模的 .NET 开发人员在微软之外，只是我们没有善加运用。

2. 你如何说服老板，例如微软新任执行长 Satya Nadella?

潘：有次和我的老板也就是微软云端和企业部门执行副总裁 Scott Guthrie 一对一面谈时，我提出.NET 开源的计划，他也看到了上述类似的趋势相当认同我的决定，甚至要求我提前3个月完成.NET开源释出的工作。至于 Satya Nadella，我根本不需要说服他，他完全支持。

3. 决定开源之后，先做哪些事？

潘：没办法在决定的第一天就开源，因为不是将所有的代码开源，传统桌面代码还没有开源，这是很大的剥离工程。另外，改用开源 GitHub 来管理代码之后，如何确保全世界任何开发人员都可以使用，不论是编译、构建、测试等工作流程都要重新考虑，等于是整套微软软件开发工程的重建。所以，我们花了很多时间研究 Java 的做法，才发现 JDK 也不是完全开源，例如得和 Oracle 签署使用授权后才能取得代码。

微软第一个开源的程序是 TypeScript，从中开始学习开源经验，了解如何和社区共事，但还没真正学到释出后的商业模式。后续才将 C# 编译器（Roslyn）开源释出，然后再扩大到将.NET 核心释出。采取渐进式一步步开源的策略。

4. 在微软推动开源，最大的挑战是什么？

潘：一开始最困难的是跟所有人解释为何要这么做。例如得说服法务部门，如何避免微软的知识产权，得向市场部门解释，开源的必要性，什么样的成功情境才是开源的成果等。

另外，微软有一套严格的知识产权规范，这个规范结构不适合采取开源，因此也有很大的调整，让产品部门未来很容易可以开源。第一次想要释出 TypeScript 时的挑战最大，等到了.NET 开源时已经非常顺利了。在软件架构上也需要调整，把将要开源的代码单独抽离，若释出的代码还需要其他未开源的相依元件才能构建，就等于无法开源。

5. 会担心知识产权权的问题吗？

潘：早在2010年时，微软就开始尝试将开源软件放入自家产品中，但会尽可能采取最安全的方式，斥资进行知识产权来避免发生问题，甚至还会考虑，万一有问题，多快能把开源软件从产品中移除。但是，现在没有人会再担心这类的问题。倘若是在对外的服务中使用开源软件，部署在后台环境中就不会有任何知识产权的风险。但若要放入盒装软件还是会有风险，因此，我们不会考虑任何 Copyleft 的授权，如 GPL。

6. .Net 开源对微软工程师有什么影响呢？

潘：3年前，微软工程师若要看一眼开源代码，都得经过3道申请程序，得获得我的同意，他们才能看。因为微软经历过很多侵权官司，为了避免工程师犯错，因而设置了很多壁垒。现在微软工程师要“看”开源代码，不用获得任何人的同意。只有要将开源代码放入产品时才需要批准。

当我们第一次将代码放上 GitHub 时，工程师们都非常紧张，还将代码中所有的注解都看过一遍，深怕写过什么骂人的话或隐私要赶快删除，后来就习以为常了。

7. 开源对微软开发流程上又有什么影响？

潘：过去微软设计产品只需和内部沟通，现在得和社区合作，这是一个全新的工作模式。开源社区贡献的代码如何和套装产品整合，也需要新的流程。拥抱开源最需要的不是调整组织，而是要改变工作方法。因为这是一个全新的模式。倘若微软仍然采取传统的瀑布式开发流程，就不可能开源。瀑布式开发流程是一个全权控制的模式，可以自行决定代码开发完成的时间点，再来安排后续测试团队的工作排程。

过去，微软开发工作是计划性的，但在开源之后，无法预估有多少人有兴趣贡献代码。开发社区贡献的代码越多，就得投入愈多人力来审视提交出来的代码品质。代码开源之后，不论是谁贡献的哪一段代码，尽管是完成度很高的代码，几次开源经验来看，都需要进一步检查如代码一致性或相依性等。

8. 在这种非计划性的开源工作模式下，要如何确保产品的品质？

潘：开源释出的代码任凭社区使用，但是，要成为微软的产品，会有另一个我们认证过的发行版本，就像 RedHat Linux 也会发行不同的版本一样。或者像 Google 的 Chromium 和 Chrome 的作法一样，作为产品发布者，我们有权决定哪些社区贡献的代码能放入最终产品。

9. 代码开源后，对微软带来哪些好处？

潘：跨平台是未来的大趋势，能让 Runtime 跨平台，对所有开发人员都是福音，因为只要写一套代码就能在多个平台上使用。若.NET 没有释出，只有微软自己能进行跨平台支持，但微软不可能支持所有的 Linux 平台，开源释出后，可以让其他人针对不同平台修改。这也是一种变相的群众外包，让开发需求靠社区快速得到解决，而不用依赖厂商解决。

10. 微软长期开源策略是什么？会将所有产品都开源吗？

潘：我觉得，微软不需要将所有程序都开源，而应该是选择性地开源。首选是 Runtime 开源，其他则是要看需求程度来释出。例如.NET 开源之后，在 GitHub 上受欢迎程度比 C# 编译器高很多。

长远策略是来自当下所知，目前，我认为，开源最重要的是 Runtime 开源，从开发过程来看，工程师能够知道底层 Runtime 的代码怎么撰写，有助于调校代码，改善软件效能。但是，对于工具软件的代码，软件工程师不一定有兴趣。工程师倾向于使用一个好用的工具，而不一定会要求工具也要完全开源。就像小孩成长过程，要先会爬之后才会走，能走之后才会跑。在开源之路，微软才刚刚学会走路，但距离会跑能跳还有很长一段路。（来自IThome）