微軟全球開發(fā)平臺事業(yè)部資深副總裁潘正磊是微軟核心開發(fā)工具Visual Studio和.NET平臺開發(fā)團隊的領導人，1992年加入微軟，從一位工程師做起，歷練過多項微軟全球性技術和管理職務，3年前也兼任微軟亞太研發(fā)集團伺服器與開發(fā)平臺事業(yè)部總經理，同時管理美國與中國兩地的微軟研發(fā)團隊，就連C#之父Anders Hejlsberg都是她的部屬。

微軟全球開發(fā)平臺事業(yè)部資深副總裁潘正磊

　　潘正磊一手主導微軟Visual Studio開發(fā)團隊導入敏捷開發(fā)，擁抱DevOps思維，甚至她還是決定.NET開源的關鍵人物。

　　Q：你何時得知.NET要開源？

　　A  這是我的決定，而不是被告知。

　　Q：為何微軟需要這么大的變革？

　　A  原本大多是新創(chuàng)公司擁抱開源，但現(xiàn)在有越來越多大企業(yè)將開源視為戰(zhàn)略的一環(huán)。開源商業(yè)模式也越來越完善，可以通過提供服務的方式來建立獲利模式。軟件的程式碼只是軟件其中一小部分的價值，更大的價值要靠服務（意指云端服務）來實現(xiàn)。

　　我們的市場競爭者Java也因開源而受到歡迎。比只靠內部.NET開發(fā)團隊的腳步，大量開源社群參與的創(chuàng)新速度可以更快，我們也有類似Java社群規(guī)模的.NET開發(fā)人員在微軟之外，只是我們沒有善加運用。

　　Q：你如何說服老板，例如微軟新任執(zhí)行長Satya Nadella?

　　A  有次和我的老板也就是微軟云端和企業(yè)部門執(zhí)行副總裁Scott Guthrie一對一面談時，我提出.NET開源的計劃，他也看到了上述類似的趨勢相當認同我的決定，甚至要求我提前3個月完成.NET開源釋出的工作。至于Satya Nadella，我根本不需要說服他，他完全支持。

　　Q：決定開源之后，先做哪些事？

　　A  沒辦法在決定的第一天就開源，因為不是將所有的程式碼開源，傳統(tǒng)桌面程式碼還沒有開源，這是很大的剝離工程。另外，改用開源GitHub來管理程式碼之后，如何確保全世界任何開發(fā)人員都可以使用，不論是編譯、組建、測試等工作流程都要重新考慮，等于是整套微軟軟件開發(fā)工程的重建。所以，我們花了很多時間研究Java的作法，才發(fā)現(xiàn)JDK也不是完全開源，例如得和Oracle簽署使用授權后才能取得程式碼。

　　微軟第一個開源的程式是TypeScript，從中開始學習開源經驗，了解如何和社群共事，但還沒真正學到釋出后的商業(yè)模式。后續(xù)才將C#編譯器（Roslyn）開源釋出，然后再擴大到將.NET核心釋出。采取漸進式一步步開源的策略。

　　Q：在微軟推動開源，最大的挑戰(zhàn)為何？

　　A  一開始最困難的是跟所有人解釋為何要這么做。例如得說服法務部門，如何避免微軟的智慧財產，得向市場部門解釋，開源的必要性，什么樣的成功情境，才是開源的成果等。

　　另外，微軟有一套嚴格的智慧財產權規(guī)范，這個規(guī)范結構不適合采取開源，因此也有很大的調整，讓產品部門未來很容易可以開源。第一次想要釋出TypeScript時的挑戰(zhàn)最大，等到了.NET開源時已經非常順利了。

　　另外在軟件架構上也需要調整，能將要開源的程式碼單獨抽離，若釋出的程式碼還需要其他未開源的相依元件才能組建，就等于無法開源。

　　Q：會擔心智慧財產權的問題嗎？

　　A  早在2010年時，微軟就開始嘗試將開源軟件放入自家產品中，但會盡可能采取最安全的方式，斥資進行智慧財產權來避免發(fā)生問題，甚至還會考慮，萬一有問題，多快能把開源軟件從產品中移除。

　　但是，現(xiàn)在，沒有人會再擔心這類的問題。倘若是在對外的服務中使用開源軟件，部署在后臺環(huán)境中就不會有任何智慧財產權的風險。但若要放入盒裝軟件還是會有風險，因此，我們不會考慮任何Copyleft的授權，如GPL。

　　Q：開源后，對微軟工程師有什么影響呢？

　　A  3年前，微軟工程師若要看一眼開源程式碼，都得經過3道申請程序，得獲得我的同意，他們才能看。因為微軟經歷過很多侵權官司，為了避免工程師犯錯，因而設置了很多壁壘。

　　現(xiàn)在微軟工程師要「看」開源程式碼，不用獲得任何人的同意。只有要將開源程式碼放入產品時才需要批準。

　　當我們第一次將程式碼放上GitHub時，工程師們都非常緊張，還將程式碼中所有的注解都看過一遍，深怕寫過什么罵人的話或隱私要趕快刪除，后來就習以為常了。

　　Q：開源對微軟開發(fā)流程上又有什么影響？

　　A  過去微軟設計產品只需和內部溝通，現(xiàn)在得和社群合作，這是一個全新的工作模式。開源社群貢獻的程式碼如何和套裝產品整合，也需要新的流程。擁抱開源最需要的不是調整組織，而是要改變工作方法。

　　Q：為什么需要改變工作方法？

　　A  因為這是一個全新的模式。倘若微軟仍然采取傳統(tǒng)的瀑布式開發(fā)流程，就不可能開源。瀑布式開發(fā)流程是一個全權控制的模式，可以自行決定程式碼開發(fā)完成的時間點，再來安排后續(xù)測試團隊的工作排程。

　　過去，微軟開發(fā)工作是計劃性的，但在開源之后，無法預估有多少人有興趣貢獻程式碼。開發(fā)社群貢獻的程式碼越多，就得投入愈多人力來審視提交出來的程式碼品質。

　　程式碼開源之后，不論是誰貢獻的哪一段程式碼，盡管是完成度很高的程式碼，幾次開源經驗來看，都需要進一步檢查如程式碼一致性或相依性等。

　　Q：在這種非計劃性的開源工作模式下，要如何確保產品的品質？

　　A  開源釋出的程式碼任憑社群使用，但是，要成為微軟的產品，會有另一個我們認證過的發(fā)行版本，就像RedHat Linux也會發(fā)行不同的版本一樣。

　　或者像Google的Chromium和Chrome的作法一樣，作為產品發(fā)布者，我們有權決定哪些社群貢獻的程式碼能放入最終產品。

　　Q：程式碼開源后，對微軟帶來哪些好處？

　　A  跨平臺是未來的大趨勢，能讓Runtime跨平臺，對所有開發(fā)人員都是福音，因為只要寫一套程式碼就能在多個平臺上使用。

　　若.NET沒有釋出，只有微軟自己能進行跨平臺支持，但微軟不可能支持所有的Linux平臺，開源釋出后，可以讓其他人針對不同平臺修改。

　　這也是一種變相的群眾外包，讓開發(fā)需求靠社群快速得到解決，而不用依賴廠商解決。

　　Q：微軟長期開源策略是什么？會將所有產品都開源嗎？

　　A  我覺得，微軟不需要將所有程式都開源，而應該是選擇性地開源。首選是Runtime開源，其他則是要看需求程度來釋出。例如.NET開源之后，在GitHub上受歡迎程度比C#編譯器高很多。

　　長遠策略是來自當下所知，目前，我認為，開源最重要的是Runtime開源，從開發(fā)過程來看，工程師能夠知道底層Runtime的程式碼怎么撰寫，有助于調校程式碼，改善軟件效能。但是，對于工具軟件的程式碼，軟件工程師不一定有興趣。工程師傾向于使用一個好用的工具，而不一定會要求工具也要完全開源。

　　就像小孩成長過程，要先會爬之后才會走，能走之后才會跑。在開源之路，微軟才剛剛學會走路，但距離會跑能跳還有很長一段路。