開源是怎樣煉成的？

在過去幾年中，GitHub是所有人最喜愛的雲控制版本和版本庫服務，只不過漸漸地，人們已經不再這麼認為了。最近，在一個小的會議上，幾個在數家企業做經理的人一致同意通過協作、自主組織、分散式的方法來推動開原始碼的發展—— 為開發企業軟體提供了一個更具吸引力的新模型。

實際上，這個模型看上去怎麼樣？在一次RedMonk會議，自稱是Github第一位“開發者員工”的Ryan Tomayko簡潔地描述了該理念的核心思想：

Internally, our processes work very much like an open source project. There are projects, there are people interested in projects, there are people coming up with ideas for projects, they're submitting into projects, there are people reviewing those changes and either accepting or rejecting them.
我們的流程在內部運作起來非常像是一個開源專案。我們有專案，也有對專案感興趣的人；人們想出一些創意之後就會提交到專案裡，除此之外還有些專門人審閱這些更改，最終決定是接受或拒絕這些創意想法。

換句話說，流程的簡單也是高效運作的必要條件，和程式複雜的企業開發組織相比。GitHub作為一個遵守分散式、協作性質的開源組織，對開源專案的順利進行 有一定的限制規定。所有通訊都必須是電子形式的，且公佈出來，參與者一般情況下都是廣泛分佈在各個地方的，所以這是一種對所有問題討論進行的開放的審計跟 蹤和問責制。每個工作都是非同步進行完成的，所以很少會出現依賴性和需要規避的瓶頸現象。

GitHub本身就是一個可以為這種協作模式提供開放平臺的平臺。事實上，很難高估 GitHub 在加速軟體開發步伐上的影響力，因為它已經給參與和協作帶來了越來越容易的便利。

言歸正傳，所有的參與者都已經部署了GitHub的企業版本。隨著平臺的開放力度的不斷增大，當你將開源模型應用在企業內部的時候會出現什麼現象，人們會選擇他們喜歡的專案進行開發嗎？
如何確保開發人員能夠滿足安全性和遵從性目標，尤其是在OpenSSL已經崩潰的情況下？我覺得許多企業的開發組織會拒絕這些想，並懷疑“敏捷”工作流的影響力。但是又不能完全拋棄開源的想法。

但很難忽略開源和GitHub對軟體開發產生的巨大的創新影響力。在一年前舉辦的Realtime Conference大會上，Mikeal Rogers認為Node.js所取得的驚人成功還要歸功於GitHub的存在，降低了專案准入門檻。
但問題是這樣的：一個大眾化的開源模型在企業能夠順利工作嗎？是否可以被嫁接融合到現有企業發展文化中，或者說它是否需要進行適當的轉變？有一點可以肯定的是，開源創新所帶來的成功意味著這種模型是不應該被忽視的。

ByInfoWorld