转载

.NET开源关键决策者首度曝光

.NET开源关键决策者首度曝光

  微软全球开发平台事业部资深副总裁潘正磊:微软不会将所有程序都开源,而是会选择性地开源。首选是 Runtime,而工具则不一定需要开源。

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

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

  Q:你何时得知 .NET 要开源?

  A:这是我的决定,而不是被告知。

  Q:为何微软需要这么大的变革?

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

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

  Q:你如何说服老板,例如微软新任执行长 Satya Nadella?

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

  Q:决定开源之后,先做哪些事?

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

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

  Q:在微软推动开源,最大的挑战为何?

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

  另外,微软有一套严格的智慧财产权规范,这个规范结构不适合採取开源,因此也有很大的调整,让产品部门未来很容易可以开源。第一次想要释出 TypeScript 时的挑战最大,等到了 .NET 开源时已经非常顺利了。

  另外在软件架构上也需要调整,能将要开源的代码单独抽离,若释出的代码还需要其他未开源的相依元件才能组建,就等于无法开源。

  Q:会担心智慧财产权的问题吗?

  A:早在 2010 年时,微软就开始尝试将开源软件放入自家产品中,但会尽可能採取最安全的方式,斥资进行智慧财产权来避免发生问题,甚至还会考虑,万一有问题,多快能把开源软件从产品中移除。

  但是,现在,没有人会再担心这类的问题。倘若是在对外的服务中使用开源软件,部署在后台环境中就不会有任何智慧财产权的风险。但若要放入盒装软件还是会有风险,因此,我们不会考虑任何 Copyleft 的授权,如 GPL。

  Q:开源后,对微软工程师有什么影响呢?

  A:3 年前,微软工程师若要看一眼开源代码,都得经过 3 道申请程序,得获得我的同意,他们才能看。因为微软经历过很多侵权官司,为了避免工程师犯错,因而设置了很多壁垒。

  现在微软工程师要「看」开源代码,不用获得任何人的同意。只有要将开源代码放入产品时才需要批淮。

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

  Q:开源对微软开发流程上又有什么影响?

  A:过去微软设计产品只需和内部沟通,现在得和社群合作,这是一个全新的工作模式。开源社群贡献的代码如何和套装产品整合,也需要新的流程。拥抱开源最需要的不是调整组织,而是要改变工作方法。

  Q:为什么需要改变工作方法?

  A:因为这是一个全新的模式。倘若微软仍然采取传统的瀑布式开发流程,就不可能开源。瀑布式开发流程是一个全权控制的模式,可以自行决定代码开发完成的时间点,再来安排后续测试团队的工作排程。

  过去,微软开发工作是计画性的,但在开源之后,无法预估有多少人有兴趣贡献代码。开发社群贡献的代码越多,就得投入愈多人力来审视提交出来的代码品质。

  代码开源之后,不论是谁贡献的哪一段代码,儘管是完成度很高的代码,几次开源经验来看,都需要进一步检查如代码一致性或相依性等。

  Q:在这种非计画性的开源工作模式下,要如何确保产品的品质?

  A:开源释出的代码任凭社群使用,但是,要成为微软的产品,会有另一个我们认证过的发行版本,就像 RedHat Linux 也会发行不同的版本一样。

  或者像 Google 的 Chromium 和 Chrome 的作法一样,作为产品发布者,我们有权决定哪些社群贡献的代码能放入最终产品。

  Q:代码开源后,对微软带来哪些好处?

  A:跨平台是未来的大趋势,能让 Runtime 跨平台,对所有开发人员都是福音,因为只要写一套代码就能在多个平台上使用。

  若 .NET 没有释出,只有微软自己能进行跨平台支援,但微软不可能支援所有的 Linux 平台,开源释出后,可以让其他人针对不同平台修改。

  这也是一种变相的群众外包,让开发需求靠社群快速得到解决,而不用依赖厂商解决。

  Q:微软长期开源策略是什么?会将所有产品都开源吗?

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

  长远策略是来自当下所知,目前,我认为,开源最重要的是 Runtime 开源,从开发过程来看,工程师能够知道底层 Runtime 的代码怎么撰写,有助于调校代码,改善软件效能。但是,对于工具软件的代码,软件工程师不一定有兴趣。工程师倾向于使用一个好用的工具,而不一定会要求工具也要完全开源。

  就像小孩成长过程,要先会爬之后才会走,能走之后才会跑。在开源之路,微软才刚刚学会走路,但距离会跑能跳还有很长一段路。

正文到此结束
Loading...