在未來的幾周，我們計劃發布一些由TODO團隊成員撰寫的文章，解釋每個企業下決心去啟動開源項目、使用并提升開源軟件的原因，以及由此帶來的便利。首先來傾聽沃爾瑪實驗室  Dion Almaer (@dalmaer) 的聲音。

為什么公司愿意在開源項目上耗費成本， 為什么確實有必要這樣做?

這是很棒的問題，并且隨著時間的推移，我的觀點也可能在某些方面發生改變。從職業生涯的初期，我就一直致力于開源計劃，也參與了一些優秀的開源項目，比如說Apache，之后當我加入Chris DiBona在Google的開源項目團隊，發現了一個特別有意思的現象。那是一次真正的洗禮。不論是Chris便簽上"我又要心驚膽顫的為那家伙工作了!"的名言，還是他不可思議的提供一些使工程師受益良多的開源框架，都潛移默化的促進了業務。

過去，開源工具以及廣泛性并不及現在，于是，Google Code 以及其它的解決方案，從開源組織里成長起來。

讓我們將視線快速轉移到現在。

您的公司處于尋求偉大開發者的激烈競爭中

全世界有很多偉大的開發者，您的公司可能正努力爭取盡可能多的設計師。由于供不應求，所以，您需要極盡所能的吸引和培訓人才。

大多數偉大的開發者都有GitHub檔案，并致力于那里的項目（開源項目或其它）。GitHub已經無處不在，大多數開發者要么喜歡它，要么樂于待見它。這里有一些灰胡子的人（指有一定資歷的年長開發者）針對Perforce或者其它事情大喊大叫，但那畢竟是少數:)

一則簡短的軼事：我認識的一位偉大的開發者應聘到一家一流的公司工作。當他被告知，它必須使用舊的Java棧工作，同時工作流并非基于git的時候，他基本上就選擇放棄這份工作了。

你使用和創建的開源項目是招募利器。如果你正在使用React，你將會有大量的開發者，他們可能正在尋找使用這種技術工作的項目。如果你創建了React，你將有機會找到工作于這個項目的核心團隊！

在沃爾瑪實驗室，我們有類似的情形。我加入到創建沃爾瑪實驗室的移動端的工作中。我們需要創建流程編排服務層，因為目前的后端不支持移動功能。我們該選擇什么？

我們決定選擇 node ，不僅僅是因為它是一種適用的技術，同時我們還可以帶來全世界的開發者團隊，他們急切渴望創建大規模的node服務。

對比下面的：

嗨，你希望構建處理沃爾瑪黑色星期五業務流量的node服務，同時向全世界證明node是可行的嗎？

vs.:

嗨，你愿意構建另一個java服務用來路由一些東西嗎？

綠色的通道使得團隊可以做一些偉大的工作，并且我為他們創建的端對端的工作流感到非常非常地驕傲。

盡管在很多年前，node岌岌可危。因為我們在node里面發現了很多BUG(有時只是一個s/compiler/VM/上的BUG)，并且發現當時node這個框架還未能支撐項目的開發和使用。這正是hapi node框架誕生和眾多基于node模塊群起的原因。

我們當時需要構建對應的團隊，因此我們需要召集團隊成員，不過還好我們有這樣的優勢：

• 我們可以從hapi社區大量的開發人員中物色拉取成員

• 已有大量不僅僅是關于開源魔法般的權衡，同時也被用于解決實際問題和傳遞商業價值的工作

從那時起，開源所帶來的好處開始光芒四射。當你需要招募一個天才，你需要一個流程來篩選識別出哪位能夠勝任此工作（同樣對他們而言，他們也在篩選你）。

面談的過程就像是約會。在一兩次約會之后，你很難確定你是否想結婚。我發現，婚姻是否持久以及是否令人滿意的最好的方式是，多一些約會，更好的感知什么是婚姻。

當你面試一個以開源為核心的團隊的時候，你可以和他們一起解決問題列表中的問題，真正感知做事情的狀態。它是一個極好的優勢。

開發者是當代的藝術家

當你想到IT商店的時候，我不認可，而將它關聯到“高質量軟件產品開發”。如果你在創建一個偉大產品設計的文化，你需要想辦法讓開發者繁榮起來。對我來說，這意味著有正確指導方針的獨立自主權可以取消束縛。

如果開源程序辦公室的工作有序開展，這個模式很適合。糟糕的是，它們只由律師來打理，僅僅只關注許可證和責任。這些是很重要的話題，你不應該忽略它們。但是，你如何才能幫助開發者創建解決方案，而不是浪費時間在那個漩渦里呢？

偉大的開源處理過程會有各種清單，它可以快速處理完，同時將公司的開發者從A到B的過程中釋放出來。我們正在談論如何使用開源軟件，以及如何創建和維護它。

開源團隊開發的工具有很大的影響力，單獨的產品團隊不應該花費時間在下面的事情上：

• 如何知道正在使用什么開源軟件

• 標記任何問題

• 反饋團隊“那個版本由于X而不被推薦”

• 幫助市場項目（在線，事件等）

• 提供給領導者項目的一些狀況

• 幫助領導者了解圍繞項目的社區

• 默認情況，以及關于人們如何貢獻和參與的簡單處理流程

GitHub有一些這樣的工具，不過只是一個子集。

遠程辦公

圍繞著“遠程辦公”，社區正在討論得如火如荼。你可以看到公司的兩面性，如Slack公司創建了更利于遠程溝通的產品，卻沒有公司招聘人來駐扎使用。

一旦你接觸到了一些人后，你就開始了“遠程”辦公。如果你們不是在同一間房里面，那么你就需要通過工具來實現你的主工作流程。當然，你可以通過聚在一起，面對面地討論一些主題，但這不是你通常的工作流。

這不是很有趣嗎？因為這些公司都可以通過開源的工具（例如：結合Basecamp和Rails的DHH,結合Automatic和Wordpress的Matt）來實現遠程辦公。開源項目多年來一直生活在遠程的夢境并且取得了巨大的成功。自然而言，他們就會信奉在合作的生活里的工作方式。無論他們是僅僅知道了如何讓它運轉（并且同時知道對應的好處），還是他們正在構建開源軟件從而使得最好的工程師可以來自不同的地域不同的膚色。

我個人認為遠程辦公只在特定的范圍內行之有效，并且開源使這條路更為順暢。

通常而言，這帶來了新的工具和針對你公司的新流程。多樣性是非常重要的，并且好的開源努力可以幫助公司增長對技術、流程和工具的閱歷。

杠桿作用

你可以在開源里面獲得一系列的杠桿作用。再次取hapi為例：在全球各地，我們已經有大量的公司在測試和運行這個框架。他們也同樣知道hapi運行在沃爾瑪實驗室的產品中。

我們都可以從社區提供的bugs和開發的新特性中受益。如同一個巨大的協同效應。

償還：做正確的事

我們都是站在了巨人的肩膀上。感謝那些工作在Linx、Apache、Node、JavaScript和PostgreSQL和...(此處省略一萬字)的大神。

我感覺繼續將開源進行到底就是我的責任。而從開源里面抓取到了好的精華卻將我正在做的事件全部隱藏起來，對我而言則是不對的。這不是說你正在做的任何事都是錯的（依賴于許可證等），但我感覺就是不對。

這就是為什么我一直認為任何開源的東西都不應該是專有的，并且通常是非常有用的。

但是在你進行開源之前，你需要記住開源遠遠不等同于“免費”。如果一個團隊準備拋一些軟件出來后就不管了，那么對我而言是沒用的。我的觀點是，你應該著手 在社區里面建立一些內容以表明你在那里并且會以通過某些途徑來支持。你最好有好的文檔提供。你最好對于貢獻有一個好的規劃。還有，做一個好市民。

確實，打造一個出色的開源團隊是需要很多時間和資源的，所以你不應該對此掉以輕心，但是我知道在這個年代，對于你能否成就一番事業還是得出“我們也承諾不起”這樣的結論，我不得而知（譯者注：此段意譯）。