現在微軟工程師要「看」開源程式碼,不用獲得任何人的同意
q:決定開源之後,先做哪些事?
長遠策略是來自當下所知,目前,我認為,開源最重要的是runtime開源,從開發過程來看,工程師能夠知道底層runtime的程式碼怎麼撰寫,有助於調校程式碼,改善軟體效能但是,對於工具軟體的程式碼,軟體工程師不一定有興趣工程師傾向於使用一個好用的工具,而不一定會要求工具也要完全開源
程式碼開源之後,不論是誰貢獻的哪一段程式碼,儘管是完成度很高的程式碼,幾次開源經驗來看,都需要進一步檢查如程式碼一致性或相依性等
但是,現在,沒有人會再擔心這類的問題倘若是在對外的服務中使用開源軟體,部署在後臺環境中就不會有任何智慧財產權.net程序员的風險但若要放入盒裝軟體還是會有風險,因此,我們不會考慮任何copyleft的授權,如gpl
a? 這是我的決定,而不是被告知
微軟全球開發平臺事業部資深副總裁潘正磊是微軟核心開發工具visual studio和.net平臺開發團隊的領導人,1992年加入微軟,從一位工程師做起,歷練過多項微軟全球性技術和管理職務,3年前也兼任微軟亞太研發集團伺服器與開發平臺事業部總經理,同時管理美國與中國兩地的微軟研發團隊,就連c#之父anders hejlsberg都是她的部屬
q:你如何說服老闆,例如微軟新任執行長satya nadella?
另外在軟體架構上也需要調整,能將要開源的程式碼單獨抽離,若釋出的程式碼還需要其他未.net程序员開源的相依元件才能組建,就等於無法開源
q:為何微軟需要這麼大的變革?
若.net沒有釋出,只有微軟自己能進行跨平臺支援,但微軟不可能支援所有的linux平臺,開源釋出後,可以讓其他人針對不同平臺修改
a? 跨平臺是未來的大趨勢,能讓runtime跨平臺,對所有開發人員都是福音,因為只要寫一套程式碼就能在多個平臺上使用
a? 有次和我的老闆也就是微軟雲端和企業部門執行副總裁scott guthrie一對一面談時,我提出.net開源的計畫,他也看到了上述類似的趨勢相當認同我的決定,甚至要求我提前3個月完成.net開源釋出的工作至於satya nadella,我根本不需要說服他,他完全支持
當我們第一次將程式.net发展碼放上github時,工程師們都非常緊張,還將程式碼中所有的註解都看過一遍,深怕寫過什麼罵人的話或隱私要趕快刪除,後來就習以為常了只有要將開源程式碼放入產品時才需要批准
q:微軟長期開源策略是什麼?會將所有產品都開源嗎?
微軟第一個開源的程式是typescript,從中開始學習開源經驗,了解如何和社群共事,但還沒真正學到釋出後的商業模式後續才將c#編譯器(roslyn)開源釋出,然後再擴大到將.net核心釋出採取漸進式一步步開源的策略
過去,微軟開發工作是計畫性的,但在開源之後,無法預估有多少人有興趣貢獻程式碼開發社群貢獻的程式碼越多,就得投入愈多人力來審視提交出來的程式碼品質
a? 原本大多是新創公司擁抱.net组件開源,但現在有越來越多大企業將開源視為戰略的一環開源商業模式也越來越完善,可以透過提供服務的方式來建立獲利模式軟體的程式碼只是軟體其中一小部分的價值,更大的價值要靠服務(意指雲端服務)來實現
a? 3年前,微軟工程師若要看一眼開源程式碼,都得經過3道申請程序,得獲得我的同意,他們才能看因為微軟經歷過很多侵權官司,為了避免工程師犯錯,因而設置了很多壁壘
這也是一種變相的群眾外包,讓開發需求靠社群快速得到解決,而不用依賴廠商解決
a? 過去微軟設計產品只需和內部溝通,現在得和社群合作,這是一個全新的工作模式開源社群貢獻的程式碼如何和套裝產品整合,也需要新的流程擁抱開源最需要的不是調整組織,而是要改變工作方法
q:.net发展開源後,對微軟工程師有什麼影響呢?
或者像google的chromium和chrome的作法一樣,作為產品發布者,我們有權決定哪些社群貢獻的程式碼能放入最終產品
q:你何時得知.net要開源?
q:在微軟推動開源,最大的挑戰為何?
另外,微軟有一套嚴格的智慧財產權規範,這個規範結構不適合採取開源,因此也有很大的調整,讓產品部門未來很容易可以開源第一次想要釋出typescript時的挑戰最大,等到了.net開源時已經非常順利了
q:程式碼開源後,對微軟帶來哪些好處?
a? 一開始最困難的是跟所有人解釋為何要這麼做例如得說服法務部門,如何避免微軟的智慧財產,得向市場部門解釋,開源的必要性,什麼樣的成功情境,才.net程序员是開源的成果等
q:為什麼需要改變工作方法?
a? 因為這是一個全新的模式倘若微軟仍然採取傳統的瀑布式開發流程,就不可能開源瀑布式開發流程是一個全權控制的模式,可以自行決定程式碼開發完成的時間點,再來安排後續測試團隊的工作排程
我們的市場競爭者java也因開源而受到歡迎比只靠內部.net開發團隊的腳步,大量開源社群參與的創新速度可以更快,我們也有類似java社群規模的.net開發人員在微軟之外,只是我們沒有善加運用
就像小孩成長過程,要先會爬之後才會走,能走之後才會跑在開源之路,微軟才剛剛學會走路,但距離會跑能跳還有很長一段路
q:在這種非計畫性的開源工作模式下,要如何確保產品的品質?
相關報導請參考：「.net组件她
讓.net走向開源」
q:會擔心智慧財產權的問題嗎?
a? 開源釋出的程式碼任憑社群使用,但是,要成為微軟的產品,會有另一個我們認證過的發行版本,就像redhat linux也會發行不同的版本一樣
潘正磊一手主導微軟visual studio開發團隊導入敏捷開發,擁抱devops思維,甚至她還是決定.net開源的關鍵人物
q:開源對微軟開發流程上又有什麼影響?
a? 沒辦法在決定的第一天就開源,因為不是將所有的程式碼開源,傳統桌面程式碼還沒有開源,這是很大的剝離工程另外,改用開源github來管理程式碼之後,如何確保全世界任何開發人員都可以使用,不論是編譯.net的历史有哪些、組建、測試等工作流程都要重新考慮,等於是整套微軟軟體開發工程的重建所以,我們花了很多時間研究java的作法,才發現jdk也不是完全開源,例如得和oracle簽署使用授權後才能取得程式碼
a? 早在2010年時,微軟就開始嘗試將開源軟體放入自家產品中,但會盡可能採取最安全的方式,斥資進行智慧財產權來避免發生問題,甚至還會考慮,萬一有問題,多快能把開源軟體從產品中移除
a? 我覺得,微軟不需要將所有程式都開源,而應該是選擇性地開源首選是runtime開源,其他則是要看需求程度來釋出例如.net開源之後,在github上受歡迎程度比c#編譯器高很多
白癜风有什么好偏方北京专业治白癜风的医院