企業內部開源資料匯總：https://gitee.com/InnerSource
InnerSource僅僅是一個名稱，它是一種在企業內部應用開源軟體實踐的軟體開發方法。來自PayPal的技術帶頭人Cedric Williams，在開源大會OSCON上解釋了在PayPal如何使用InnerSource來打破孤島、加強合作、增加生產力。
實踐開始於18個月以前，清算平臺的團隊當時大概需要花2/3的時間來重寫由區域團隊所提交的代碼。而區域團隊，有一個很重要的職責，那就是確保 PayPal能夠在不同國家符合當地的一些規定。這種情況對於誰都沒有益處。清算團隊沒法做好自己的本職工作，而區域團隊所話費時間寫的大量代碼而別人又 用不上。
PayPal從開放原始碼軟體中汲取了靈感，尤其是來自Apache軟體基金會的實踐。他們發現了開源軟體的組織原則，即每個項目都有各個金字塔的 層：用戶，在最底層；貢獻者；可信任的提交者；最上層是架構師／開發者的領導者。PayPal評估了這些個情況後，作出最大的變化是引入「可信任的提交 者」角色。
找到合適的可信任的提交者可不是一個簡單的決定：清算團隊中只有10%的人是這樣的角色。Williams在此回答了人們一個問題，成為可信任的提 交者需要哪些技術技能？首先必須有深厚的技術功底，然後對於代碼庫的核心了如指掌，即使有了這兩樣也不能成為最出色的。可信任的提交者還必需擁有良好的人 際交往能力，他們要成為教練員。他們需要以積極、清晰的方式來溝通。舉例來說，不要說「這些代碼無法接受」，而是需要這麼去說「這是我需要你去做的方可接 受你的代碼，這裡有幾點原因［...］」。
不出所料，引入可信任提交者角色帶來了政治上的扯皮風險，所以不得不小心的去處理，無論是清算團隊內部還是外部。為了使全局能夠接受變化，可信任提交者不僅僅要審核來自區域團隊所提交的代碼，還要審核來自清算團隊其他成員所提交的代碼。
實施6個月之後效果出來了，清算團隊再也沒有花時間去重寫別人的代碼了，而僅僅花了10%的時間去做審核代碼的工作，該團隊進行了一次大規模的重 構，且在沒有做任何計劃的情況下提升了4倍的性能。團隊成員的心態也從排斥轉變為積極的接受。一個最大的副產品是所有相關的溝通都通過寫作來完成，多數是 在Github上：PayPal使用Github來託管他們的開源軟體，使用企業版Github來託管他們的閉源項目。這使得能夠在所有的團隊之間進行知 識共享和傳播。
在InnerSource之前，PayPal嘗過不同的方法，它們是：自頂向下的強制和駐場。
第一種方法，即自頂向下，是比較傳統和古老的了。定義嚴格的規則和利益相關者，自頂向下，讓人們承擔責任。這無法解決問題，但是可以產生很多的會議。
駐場的情況會好一點。來自各個區域團隊的高級工程師們都被租借到聖荷西，和開發團隊的成員們在一起工作。駐場能夠達到知識的共享，且能夠對彼此團隊 的行為有所了解。非常遺憾的是 ，一旦這些工程師們回到了各自的區域團隊之後，他們就會成為瓶頸。他們發現找不到時間或者是沒有所需要的技能將他們所學到的傳授給他人。
Williams為InnerSource的入門者提供了一些建議。在第一步，在你的工程師團隊中將可信任提交者限制在10%，要求所有的代碼都須 公開審核，且要確保代碼的審核要聚焦於完成什麼從而使代碼更加的良好；第二，要求所有的對話都是成熟的、得到尊重的；第三，分享你的經驗。PayPal將 於11月9號在加利福尼亞的聖荷西舉辦首屆InnerSource峰會。PayPal還為此贊助了一本小書，目標讀者是哪些想進一步學習此方法的人們。
查看英文原文：InnerSource:Internal Open Source at Paypal