微軟全球開(kāi)發(fā)平臺事業(yè)部資深副總裁潘正磊是微軟核心開(kāi)發(fā)工具Visual Studio和.NET平臺開(kāi)發(fā)團隊的領(lǐng)導人，1992年加入微軟，從一位工程師做起，歷練過(guò)多項微軟全球性技術(shù)和管理職務(wù)，3年前也兼任微軟亞太研發(fā)集團伺服器與開(kāi)發(fā)平臺事業(yè)部總經(jīng)理，同時(shí)管理美國與中國兩地的微軟研發(fā)團隊，就連C#之父Anders Hejlsberg都是她的部屬。
微軟全球開(kāi)發(fā)平臺事業(yè)部資深副總裁潘正磊
潘正磊一手主導微軟Visual Studio開(kāi)發(fā)團隊導入敏捷開(kāi)發(fā)，擁抱DevOps思維，甚至她還是決定.NET開(kāi)源的關(guān)鍵人物。
Q：你何時(shí)得知.NET要開(kāi)源？
A 這是我的決定，而不是被告知。
Q：為何微軟需要這么大的變革？
A 原本大多是新創(chuàng )公司擁抱開(kāi)源，但現在有越來(lái)越多大企業(yè)將開(kāi)源視為戰略的一環(huán)。開(kāi)源商業(yè)模式也越來(lái)越完善，可以通過(guò)提供服務(wù)的方式來(lái)建立獲利模式。軟件的程式碼只是軟件其中一小部分的價(jià)值，更大的價(jià)值要靠服務(wù)（意指云端服務(wù)）來(lái)實(shí)現。
我們的市場(chǎng)競爭者Java也因開(kāi)源而受到歡迎。比只靠?jì)炔?NET開(kāi)發(fā)團隊的腳步，大量開(kāi)源社群參與的創(chuàng )新速度可以更快，我們也有類(lèi)似Java社群規模的.NET開(kāi)發(fā)人員在微軟之外，只是我們沒(méi)有善加運用。
Q：你如何說(shuō)服老板，例如微軟新任執行長(cháng)Satya Nadella?
A 有次和我的老板也就是微軟云端和企業(yè)部門(mén)執行副總裁Scott Guthrie一對一面談時(shí)，我提出.NET開(kāi)源的計劃，他也看到了上述類(lèi)似的趨勢相當認同我的決定，甚至要求我提前3個(gè)月完成.NET開(kāi)源釋出的工作。至于Satya Nadella，我根本不需要說(shuō)服他，他完全支持。
Q：決定開(kāi)源之后，先做哪些事？
A 沒(méi)辦法在決定的第一天就開(kāi)源，因為不是將所有的程式碼開(kāi)源，傳統桌面程式碼還沒(méi)有開(kāi)源，這是很大的剝離工程。另外，改用開(kāi)源GitHub來(lái)管理程式碼之后，如何確保全世界任何開(kāi)發(fā)人員都可以使用，不論是編譯、組建、測試等工作流程都要重新考慮，等于是整套微軟軟件開(kāi)發(fā)工程的重建。所以，我們花了很多時(shí)間研究Java的作法，才發(fā)現JDK也不是完全開(kāi)源，例如得和Oracle簽署使用授權后才能取得程式碼。
微軟第一個(gè)開(kāi)源的程式是TypeScript，從中開(kāi)始學(xué)習開(kāi)源經(jīng)驗，了解如何和社群共事，但還沒(méi)真正學(xué)到釋出后的商業(yè)模式。后續才將C#編譯器（Roslyn）開(kāi)源釋出，然后再擴大到將.NET核心釋出。采取漸進(jìn)式一步步開(kāi)源的策略。
Q：在微軟推動(dòng)開(kāi)源，最大的挑戰為何？
A 一開(kāi)始最困難的是跟所有人解釋為何要這么做。例如得說(shuō)服法務(wù)部門(mén)，如何避免微軟的智慧財產(chǎn)，得向市場(chǎng)部門(mén)解釋?zhuān)_(kāi)源的必要性，什么樣的成功情境，才是開(kāi)源的成果等。
另外，微軟有一套嚴格的智慧財產(chǎn)權規范，這個(gè)規范結構不適合采取開(kāi)源，因此也有很大的調整，讓產(chǎn)品部門(mén)未來(lái)很容易可以開(kāi)源。第一次想要釋出TypeScript時(shí)的挑戰最大，等到了.NET開(kāi)源時(shí)已經(jīng)非常順利了。
另外在軟件架構上也需要調整，能將要開(kāi)源的程式碼單獨抽離，若釋出的程式碼還需要其他未開(kāi)源的相依元件才能組建，就等于無(wú)法開(kāi)源。
Q：會(huì )擔心智慧財產(chǎn)權的問(wèn)題嗎？
A 早在2010年時(shí)，微軟就開(kāi)始嘗試將開(kāi)源軟件放入自家產(chǎn)品中，但會(huì )盡可能采取最安全的方式，斥資進(jìn)行智慧財產(chǎn)權來(lái)避免發(fā)生問(wèn)題，甚至還會(huì )考慮，萬(wàn)一有問(wèn)題，多快能把開(kāi)源軟件從產(chǎn)品中移除。
但是，現在，沒(méi)有人會(huì )再擔心這類(lèi)的問(wèn)題。倘若是在對外的服務(wù)中使用開(kāi)源軟件，部署在后臺環(huán)境中就不會(huì )有任何智慧財產(chǎn)權的風(fēng)險。但若要放入盒裝軟件還是會(huì )有風(fēng)險，因此，我們不會(huì )考慮任何Copyleft的授權，如GPL。
Q：開(kāi)源后，對微軟工程師有什么影響呢？
A 3年前，微軟工程師若要看一眼開(kāi)源程式碼，都得經(jīng)過(guò)3道申請程序，得獲得我的同意，他們才能看。因為微軟經(jīng)歷過(guò)很多侵權官司，為了避免工程師犯錯，因而設置了很多壁壘。
現在微軟工程師要「看」開(kāi)源程式碼，不用獲得任何人的同意。只有要將開(kāi)源程式碼放入產(chǎn)品時(shí)才需要批準。
當我們第一次將程式碼放上GitHub時(shí)，工程師們都非常緊張，還將程式碼中所有的注解都看過(guò)一遍，深怕寫(xiě)過(guò)什么罵人的話(huà)或隱私要趕快刪除，后來(lái)就習以為常了。
Q：開(kāi)源對微軟開(kāi)發(fā)流程上又有什么影響？
A 過(guò)去微軟設計產(chǎn)品只需和內部溝通，現在得和社群合作，這是一個(gè)全新的工作模式。開(kāi)源社群貢獻的程式碼如何和套裝產(chǎn)品整合，也需要新的流程。擁抱開(kāi)源最需要的不是調整組織，而是要改變工作方法。
Q：為什么需要改變工作方法？
A 因為這是一個(gè)全新的模式。倘若微軟仍然采取傳統的瀑布式開(kāi)發(fā)流程，就不可能開(kāi)源。瀑布式開(kāi)發(fā)流程是一個(gè)全權控制的模式，可以自行決定程式碼開(kāi)發(fā)完成的時(shí)間點(diǎn)，再來(lái)安排后續測試團隊的工作排程。
過(guò)去，微軟開(kāi)發(fā)工作是計劃性的，但在開(kāi)源之后，無(wú)法預估有多少人有興趣貢獻程式碼。開(kāi)發(fā)社群貢獻的程式碼越多，就得投入愈多人力來(lái)審視提交出來(lái)的程式碼品質(zhì)。
程式碼開(kāi)源之后，不論是誰(shuí)貢獻的哪一段程式碼，盡管是完成度很高的程式碼，幾次開(kāi)源經(jīng)驗來(lái)看，都需要進(jìn)一步檢查如程式碼一致性或相依性等。
Q：在這種非計劃性的開(kāi)源工作模式下，要如何確保產(chǎn)品的品質(zhì)？
A 開(kāi)源釋出的程式碼任憑社群使用，但是，要成為微軟的產(chǎn)品，會(huì )有另一個(gè)我們認證過(guò)的發(fā)行版本，就像RedHat Linux也會(huì )發(fā)行不同的版本一樣。
或者像Google的Chromium和Chrome的作法一樣，作為產(chǎn)品發(fā)布者，我們有權決定哪些社群貢獻的程式碼能放入最終產(chǎn)品。
Q：程式碼開(kāi)源后，對微軟帶來(lái)哪些好處？
A 跨平臺是未來(lái)的大趨勢，能讓Runtime跨平臺，對所有開(kāi)發(fā)人員都是福音，因為只要寫(xiě)一套程式碼就能在多個(gè)平臺上使用。
若.NET沒(méi)有釋出，只有微軟自己能進(jìn)行跨平臺支持，但微軟不可能支持所有的Linux平臺，開(kāi)源釋出后，可以讓其他人針對不同平臺修改。
這也是一種變相的群眾外包，讓開(kāi)發(fā)需求靠社群快速得到解決，而不用依賴(lài)廠(chǎng)商解決。
Q：微軟長(cháng)期開(kāi)源策略是什么？會(huì )將所有產(chǎn)品都開(kāi)源嗎？
A 我覺(jué)得，微軟不需要將所有程式都開(kāi)源，而應該是選擇性地開(kāi)源。首選是Runtime開(kāi)源，其他則是要看需求程度來(lái)釋出。例如.NET開(kāi)源之后，在GitHub上受歡迎程度比C#編譯器高很多。
長(cháng)遠策略是來(lái)自當下所知，目前，我認為，開(kāi)源最重要的是Runtime開(kāi)源，從開(kāi)發(fā)過(guò)程來(lái)看，工程師能夠知道底層Runtime的程式碼怎么撰寫(xiě)，有助于調校程式碼，改善軟件效能。但是，對于工具軟件的程式碼，軟件工程師不一定有興趣。工程師傾向于使用一個(gè)好用的工具，而不一定會(huì )要求工具也要完全開(kāi)源。
就像小孩成長(cháng)過(guò)程，要先會(huì )爬之后才會(huì )走，能走之后才會(huì )跑。在開(kāi)源之路，微軟才剛剛學(xué)會(huì )走路，但距離會(huì )跑能跳還有很長(cháng)一段路。
