開源是途徑，並非目的

開源重塑了企業的一些關係，並讓業務更加的靈活，它讓顧客乃至競爭對手成為公司的合作者。當參與開源的收益大於閉原始碼時，公司就會擁抱開源，並鼓勵這樣的靈活業務。但是開源本身並不是一個結果，它是一種找到不同公司的利益相交的地方，並能夠讓這些公司合作起來 —— 它是一條途徑，而不是一個地點。要想得到開源的更多收益，則須明確的走下去。

但是很多公司都會試圖跳過這條路徑，而直接到達終點。他們秘密的開發軟體，然後在某一天說自己完美的實現了產品，並有著酷炫的功能，並聲稱：「現在我們開源了！」 要知道這從來都不會發生。我可以列舉出一大堆理由告訴你，由此產生的項目不大可能帶來開放原始碼本應能得到的大部分收益。代碼是使用了自由的許可授權、且有著公開的可訪問的倉庫，即使是產品有著相當的受眾，也不會魔法般的突然出現很多參與者。所有的這一切都歸因於一個原因，那就是：潛在的參與者會清楚明白的意識到 —— 你的項目沒有開源的整個過程。

一家開源的公司必須經歷建設開發者社區漫長的過程，和其他利益相關的方進行合作，而且要跨越公司和項目的邊界進行工作——只有代碼是開放的，這一切才有可能。簡短點來說，若要開源，必須經歷這點。你可以從這條漫長的路徑任意的點出發，但是就是不能直接跳過。

開源要趁早，不要等到萬事俱備之後再開源

要等到所有的事情都完備的情況下再去開源，對於業務有著非常不利的原因：它會錯失良機，以及先發優勢。

當這些開發者們在秘密的進行開發，即隱藏在公司的保密協議背後在辛勤的工作，你的一些競爭對手已經早已開始建立聯盟、進行協作、甚至一起投資了。所以要儘早的去進行開源項目的投資，讓競爭對手追趕你，而不是相反。

一些公司對於過早的將代碼開源的擔憂有如下三個理由：第一，會對現有的開發流程不利，因為這涉及到開發方法和習慣的調整；第二，可能放棄潛在的信息優勢：讓競爭對手知道我們要開源一些項目，這意味著放棄了某些競爭優勢；第三，通常是不好意思或感到囧：「我們的代碼還沒有準備好！我們的程式設計師們不樂意看到不夠優雅的代碼以及難以閱讀的文檔，等他們把這些都補上再說。」

其實這些理由都是可以理解的，也屬於人之常情。讓我們先來處理前兩種情況：

開源可能需要對開發方法進行一些調整，而且說實話，開源的計劃確實會為你的競爭對手提供一些信息，當然這也就需要你偶爾的應該去針對開源項目的時間進行合理的安排。

但是這種偶爾的情況發生的機率非常的小，如果說你的團隊需要調整自己的工作方法，好的決策是儘早的改變，而不是拖延到未來。在項目早期階段學習如何整合開源實踐可能是棘手的，但是對於開源的新手來說，卻能夠更好地被引導，從而很快的熟悉它。在開發周期的後面來做這件事情的話，會面臨項目截止日期的壓力，那個時候再去改變，閉源的習慣早已經固化了每個開發者，會面臨更大的困難。

至於說開源會對外發出明確的信號這件事情來說，謹記兩件事：第一，無論如何，從整體的戰略來說，競爭對手都會看的清晰明了，你得根據自己的業務性質來作出決定；第二，如果你的競爭對手改變了策略是因為看到你開源了項目，這不正中你意了嗎？要明白自己的強項在哪裡。在你的行動對他們有重要意義的情況下，他們在某種意義上自願地將自己置於與自己的計劃相關的領導作用。不要去可以隱藏什麼，利用開源來將全部的優勢顯現出來。

最後我們再來看看不好意思的事情，即如何處理代碼還沒有準備好讓外人看這個問題，方法很簡單：儘管放手就好了。真實的情況是，你開源的越早，這些東西越少人關注，因為大家都知道沒有那個代碼倉庫在初始階段就是完美的。再說的更為露骨一點，不要以為會有人注意你，你隨時都可以開源，因為大家關注代碼是是否需要。

中層管理是關鍵，這是開源深入組織文化的地方

開源的實現，既可以是由上而下，也可以是至下而上。

有的時候，某些公司會將擁抱開源視為整個公司的戰略部分：上層領導認識到開放源碼的好處，然後在促進變革的過程中作出廣泛的改變，在公司的各個部門都非常的重視開源。然而有些時候，某些公司的開源之路是從軟體工程師們開始，因為他們是一線員工，明白開源給他們帶來的好處。後一種情況，開源的活動是在環境的趨勢下形成，又或者是工程師向自己的經理倡導、說服，無論那種情況，對於開源的推動是來自公司的基層——一線工程師，而不是公司整體的大的戰略。

無論是那種方式，自上而下也好，自下而上也罷，中層經理對於開源的實現都起著巨大的作用和影響。

中層管理層是傳遞關於傳達問題和優先事項信息的渠道。當這些轉變涉及開源開發時，只有當經理們認識到發生了什麼事情的時候，組織才回去認真的思考和行動。中層管理是開源內化的關鍵群體，如果他們沒有認同這種做法，整體的組織就無法從開源中獲益，甚至恰得其反。

這裡我們舉一個例子，絕大部分公司在轉向開源時都得重新考慮評估和考核的事情，隨著員工在參與開源項目花費時間的增多，那麼在評估時就很難知道該如何衡量他們的業績。如果管理人員過於注重預算和在其直接職權範圍內的可交付成果，那麼這些管理者就會低估員工在開源項目中的工作，這其中包括宣傳、幫助其它開發者入門、審核其它貢獻者的代碼、以及傳統公司沒有過的各種事項。一名由公司某業務部門付工資的開發者，參與到開源項目中，會以公司的利益為主，進而去傳播。這時如果Ta的經理試圖抹殺Ta在開源的工作，那麼出現的情況就是，越來越多的開發人員會將時間集中在業務部門的直接目標上，因為即使那樣會對公司造成的損失，但對於個人來說則是「考核過關」。

再舉一個例子，參與開源的積極活動一個非常有趣的好處就是能夠在公司範圍內增強內部的溝通。開發人員開始與其他業務部門的人員合作，若不是因為開源項目，他們可能一輩子也不會進行任何的合作。當雙方的經理都意識到並支持這樣的合作時，這些聯繫對於溝通來說自然是最為有效的。

開源的成功需要來自中層管理的大力支持，而不僅僅是組織層次結構的頂層或底層。

要對來自文化的抵抗有所準備

開源不僅對於在代碼中產生了轉換的效應，而且也會對組織的其它部分甚至非技術部分也會有所影響。如果經理和人力資源部門拒絕讓這種轉換擴散到整個公司，那麼開源協作的技術優勢和對企業文化的潛在改進就會遭到慘敗。

當一群有經驗的開源開發人員一起工作時，他們會以可識別的模式進行。他們有著共同的一系列使用的協作工具（版本控制倉庫、缺陷跟蹤、自動化測試系統等等），他們將傾向於以常規方式使用這些工具，這些工具在許多不同的項目中是常見的。即使對於非軟體代碼的任務也是如此：作者和編輯也會以與開發團隊編寫代碼相同的方式來處理文檔，使用相同的慣例和約定來協調工作以及作出決策。開放源碼協作工具包不僅僅是技術協作的基礎設施，而且還包括所有這些過程。

一個習慣於開源協作工具的員工，會自然而然的在各種場合下使用和推廣這些工具，默認情況是共享的，並且始終保持開放的態度，這已經是根深蒂固的一種文化了。舉例來說，一個組織該如何面對任務所有者一直在變更的情況？一定會對開源的一些邊界產生懷疑。

所以招聘和人力資源也要隨著逐步的開源而進行相應的轉變。那些優秀的候選人當他們和公司外部的人進行協作時，會留下證明自己很牛的證據的。他們在公共的空間留下了自己的成績，這是在整個社區的利益相關者都可以看得到的。開源能夠為公司招聘到最頂級的人才創造了機會，但同時開源也形成了對所有人公開的新的人才市場。這就對管理和人力資源提出了更高的要求，他們必須應對這些新的挑戰。

開源的開發因此會給公司的非工程部門帶來壓力，他們需要作出相應的調整，不能夠認識到實際的需要，又或者是不能夠滿足，這對於初入開源界的公司都是較為正常的挑戰。

社區無法代替你的開發者

有些時候，某些公司會認為開源是一條找到廉價的開發的方法，他們監視著他們投資的開源項目，將之轉換為人力，然後開始數著提交隊列中的代碼行數，並開始對比自己內部的開發人員的生產力，然後夢想著「社區」會發展壯大，這樣他們就可以將自己的員工分配到其他項目中去了。我可以放心的告訴你，這樣的事情是永遠也不會發生的，除非太陽從西邊出來。

開源的貢獻能夠提供真正有價值的內容，甚至可以完成你一些想要完成的工作，但是他不會降低你開發的成本，公司自己的開發人員能夠處理公司的優先事項，並且會對公司負責，這點是非常有價值，沒有哪家公司會放棄自己僱傭開發人員。

當一個開源項目成功的時候，不僅對公司有很大的價值，而且對整個社區的價值都有很大的提升，二者是成正比的。或許會出現多家公司共享核心的情況，但您自己的組織的開發投資可能會保持不變甚至增加。在這個水平上成功的項目，投資只應增加，不應減少。

在某些時候，您可能會減少對項目的投資，但這是因為某些條件使得項目對您而言不再那麼有價值，而不是因為您突然獲得了與以前相同的價值。這裡有一個很好的經驗法則，那就是：無論社區的規模大小，開源投資與收益是成正比的。

總結

一旦您的業務使用並參與到開源項目中，請務必記住：開源僅是一條路徑，要明確而堅定到走下去，且要從一開始就讓中層管理參與進來。謹記開源的教訓：將之應用於整個流程，而不僅僅是開發部門。這條道路沒有終點，需要持續的進行投入，當然這樣才會有持續不斷的回報。只有一直走下去，開源的戰略才能凸顯其功效，偶爾的失策也就不算啥事。