InnerSource(內部開源)正當時 ---國際內源基金會Summit 2021 參後感

語言: CN / TW / HK

       

上個月,又一次以member的身份參加國際內部開源基金會InnerSource Commons組織的InnerSource Summit 2021,並分享了一個議題。現在抽一點時間,寫下我參加本次Summit的一些感受,並分享給大家。

        首先介紹一下什麼是內部開源和內部開源基金會。內部開源(InnerSource)就是在企業內部,採用開源社群習慣的方式進行協作,簡單來說就是在企業內部開放原始碼,並接受其他團隊的貢獻,可以參考這裡(gitee上關於內源的專欄)。 而國際內部開源基金會(InnerSource Commons,https://innersourcecommons.org/)就是一個企業間交流和分享內部開源方法論和落地實踐的社群,它創建於2015年,採用類似Apache開源軟體基金會即501(c)(3)非贏利組織的方式運作,每年都會舉行Summit來集中進行內部開源經驗的分享和交流。疫情之前Summit是線上下,疫情之後以線上的方式執行。同時也有一些其他的協作內容,包括books,patterns, learing-path等。

        然後介紹一下本次的InnerSource Summit,時間是2021年11月17日到18日,共有25+ Speaker在線上進行專題分享,同時在Slack的專門頻道上交流。

       下面是我從影片上的截圖,可以看到全部spearker,按照身份基本上分為三類,

  1. 基金會的管理人員:包括Chairman Danese Cooper,VP Georg Grutter,執行總監Clare Dillion
  2. 開源社群的名流:包括Apache基金會創始人之一Brian Behlendorf, 暢銷書《People Powered》的作者Jono Bacon,
  3. 當然最多的是各個企業進行內部開源實踐的負責人,包括微軟,IBM,Morgan Stanley,US Bank,Bloomberg,Shell,Didi等。

我來重點介紹幾個我覺得有意思的talk吧。

  • Danese Cooper的Chair's Address
  • 微軟同學的分享
  • Morgan Stanley同學的分享

1. Chair's Address.

Danese Cooper 是開源著名的活動家,也是InnerSource Commons社群的創始人。

跟往常一樣,她的Slide總是從Happy InnerSource Day開始,

今年已經是InnerSource Commons社群建立的第7年了,時間過的真快。

 

在她的分享中,她回顧了社群的進展,現在社群中有1500+使用者來自500+企業,都是已經在採用InnerSource方法的企業。

國外著名的企業包括3M,IBM,Microsoft,SAP,Ford,Nike,SAP,Walmart,Morgan Stanley,Nasa等,

國內著名的企業包括騰訊,百度,華為等。

2.  微軟同學的分享--InnerSource at Microsoft

微軟負責InnerSource的Senior Program Manager Arno分享了《InnerSource at Microsoft》。

他在talk中提到,微軟的僱員超過18萬,其中50%是工程師,公司程式碼倉庫超過8萬,每個季度約有1百50萬次程式碼提交。

在這種公司裡面推行InnerSource是一個很大的挑戰,他們從2014年開始建立開源辦公室即OSPO,2018年起成立公司級的InnerSource推進組織。

他提到在微軟內部,採用ALL-In的方式,即絕大多數專案都是內部開源狀態,全部工程師都能看到並做貢獻。有些專案外部貢獻相當多,比例在15%到35%之間,(說老實話,這個比例很讓我吃驚。)他們完善了HR的Review Process來激勵工程師進行協同貢獻。還組織了很多運營活動,包括定期的Meetup,Casestudies,還有Hack events等來幫助和推廣內部開源專案。

他們還建立了比較詳細的度量體系,包括專案級別的度量來幫助專案分析和改進, 和公司級別的度量。

專案級別的度量主要度量PR相關的指標,(PR means patch request,即提交一個patch。)

例如對 PR的反應時間,要求做到比較短,推薦做到平均1小時以內進行反饋。要求PR內部的平均時間應該和PR 外部貢獻的平均時間保持一致。

公司級別的度量包括參與協同的人數等。

他的總結是經過3年多的努力,“InnerSource Does Move the needle”。 我特地查了下“Move the needle”,在微軟這個說法是指有明顯的改善。

To move the needle is to have a noticeable effect, presumably positive.

 

3. Morgan Stanley同學的分享--Moving a Legacy Codebase to an InnerSource Model

這個talk吸引我的是,一般金融企業相對比較保守,Morgan Stanely這種金融企業也能做內部開源嗎?第二是新創的程式碼容易進行新方法的嘗試,對於老程式碼Legacy專案做內部開源是很難的。所以我把她的分享好好看了下。

這位同學談到她們有一個20年的老專案,是一個java的lib,被很多其他業務部門所使用,現在打算進入維護狀態不再繼續基於此進行新功能的開發了。他們採用內部開源的方式希望可以達到如下目的:

  • 直接引入終端使用者來提升這個老專案的生命週期
  • 通過內部開源貢獻bugfix來解決維護團隊人力不足的情況
  • 測驗內部開源方法是否可以在公司內work

這種方式進行了兩年多,他們意識到InnerSource不是把程式碼開源就完了,然後就可以坐等貢獻和入了。

InnerSource要取得好的結果,要讓協同部門做高質量的貢獻,必須做好如下的事情。

  • 專案要容易build
  • 專案要有好的文件,告訴使用者如何讀懂程式碼
  • 專案要有好的測試

這些都是花費了維護團隊不少人力完成的事情,事實上他們是在償還技術債務。

之後跟協作團隊還需要很好的溝通,包括瞭解彼此的期望,即哪些feature是維護團隊希望協作團隊貢獻的,哪些feature是協作團隊的需求。

程式碼貢獻的code style是什麼,貢獻新功能的測試覆蓋率要求是多少,等等。

運行了兩年多,維護團隊花了不少人力完善build指令碼,開發文件和測試指令碼,跟貢獻者的溝通也花了不少時間。

"Was it worth the effort?

Yes,absolutely it was. "

專案採用內源方式進行工作,完全達到了事前預期,專案延長了生命力,有源源不斷的貢獻者提交bugfix和新的功能,有些長期貢獻者甚至成為這個專案的co-owner,一起leading開發和專案規劃等。

現在她所在部門負責的所有程式碼倉庫,都採用內部開源的方式進行工作。

最後她總結到:

1. InnerSource 一個老專案花費的人力比她預想的多,需要完善build,測試和文件,但她也承認這本來就是專案組早該完成的事情

2. InnerSource 既提升了他們自己的開發體驗,又在使用者中受到非常大的歡迎。

 

當然這次Summit還有很多有意思的分享,影片總的連結在這裡。 

滴滴負責內部開源的安旭同學分享了她在滴滴內部推行InnerSource的實踐和體會;

我也簡單分析了一下InnerSource和DevOps的共生關係。

 

最後是總結:

作為InnerSource Commons的member,參加Summit已經是第三次了。

總的感覺是內部開源(InnerSource)正當時,越來越多的主流大廠在採用這種方式,某些廠實踐的深度和廣度都令人感嘆。