正確選擇？四套開源專案評估

本文翻譯自 opensource.com，原作者為 Matt Micene：https://opensource.com/business/14/10/find-the-right-open-source-project

你是如何找到對的開源專案來加入？這份指南是根據我找到合適選擇的經驗而撰寫。

在這份指南裡，我寫到，你的研究要經由撒網式的大範圍開始，接著自行評估。在這樣的評估中為了找到正確選擇，我檢視了我的動機、技術、列出長串目標，最後挑出少數的目標專案。因為我不是新手，我對我的追蹤記錄做了審慎的評估。我從過去失敗的經驗中學到了什麼？我注意到一些我可以避免的模式，看到這些模式是如何與我新的目標與技能相抵觸。接著，我評估了四套開源專案及其社群，看看它們是否為正確選擇。看看最後勝出的是誰！

我的追蹤記錄

Fedora 基礎建設

若干年前，在未經現在所做的評估工作前，我就加入了 Fedora 專案成為貢獻者。我有正確的理由，我希望對我使用的專案做出回饋，不過我並不清楚一開始我能回饋什麼。我最後做了一些嘗試，不過結果並不很成功。到處摸索之後，我加入了基礎建設團隊，但是我有足夠時間，卻很難依此作出貢獻。

問題：因為我沒有找到適合加入的地方，所以白花了功夫。因此我沒有管理好我的時間和預期結果。

Spaceclone

我花了不少時間在使用 Red Hat Satellite 上，也在觀察上游的 Spacewalk 專案開發者與使用者列表。某一天列表上出現一份公告，是有關於用來管理頻道與生命週期的新工具。這正是我和我的客戶的問題，我想這會很有趣所以就看了一下。我用 Python 來寫，並放在 GitHub 上，深入探索並撰寫出快取 auth tokens 算是相當簡單。雖然對我有點挑戰性，而且早期版本有些糟糕的 list comprehension，不過算起來還順利。直到我們兩個都忙於日常工作為止。你看，我們只有兩個人。兩個忙碌的人沒辦法讓一個專案成功。

問題：用來貢獻的時間以及專案體質問題讓專案失敗。

Liquidprompt

我在白天的工作裡，把今年大部分時間用在 OpenShift 上。我所做的其中一件事，是讓 Python virtualenvs 還有軟體集合 (software collections) 在開發應用程式時正常運作。這次我切中了要害。我看了一下 GitHub 上的開放問題 (open issues)，這裡的活動還蠻頻繁，他們有貢獻政策，主要維護者很快地就關注到我的 pull request。所以看起來是個體質不錯的專案。所以我又另外針對問題列表的某個功能加強，貢獻了一個 pull request，但除此之外就沒有什麼吸引我的目光了。

問題：吸引力依舊來自於參與。如果你對該問題領域沒有興趣的話，你可能不會持續回來。

Netflix OSS

在 OSCON 的時候，我參加了 Netflix 針對他們的開源工具舉行的教學。我的組態設定和預期設定有些不同，所以我做了一些調整讓範例能動起來，並且在 GitHub 提交了 pull request。這個 pull request 還在等待審閱。

問題：儘管說歡迎提交修補，這個專案或許不是真的開放給像我這樣的人。我們可能會在內部使用，不過它真的只是為了 OSCON， 而我沒搞清楚狀況。

以上歷史列表的關鍵：為了有參與感並持續貢獻，我需要對專案領域有興趣，有時間，同時確保我挑選的專案會積極接納外部大眾的貢獻。我已經跟我的公司解決了時間問題，所以剩下的只有興趣跟專案體質。

接下來去哪？

好了，你已經看到我開源軟體歷史的好壞跟奇怪之處。目前已經核選的方框有：

• 時間 = 配合日間工作，解決企業的智財權問題
• 技能 = BASH、python、架構、文件
• 目標 = 磨練技能、加強信念

是時候用我建立新的眼光來審視一些專案了。以下是四個我確認過體質，且狀態也許適合我的專案。

跳進新的專案

OpenStack

這個專案絕對合乎目標。OpenStack 大部分是用 Python 寫的，所以當然可以讓我磨練技能。我在一些會議遇到過該社群的人，知道有很多貢獻的方法。可能有問題的地方是，這已經是個大型專案，找到切入點並不是那麼簡單。還有就是，我跟公司爭取到的時間，可能不夠用來作出有意義的貢獻。不過，我還是把它放在列表上。

評估：我對 OpenStack 的初步印象很有限。有很多專案在我找尋切入點時幫了我許多。這個專案範疇相當廣泛，不論你是開發者、測試者、文字工作者、UX 人士、安全專家，都能輕易找到給新貢獻者的指南。他們在 launchpad 裡用標簽標注比較簡單的臭蟲，協助開發者找到進入點。不過基於我可用的時間，加上即使易解的臭蟲都可見的相互關聯性，我不認為我會有多少進展。所以，儘管能夠說出我在開發 OpenStack 會很酷，我還是先把它放在一邊好了。

OpenShift Origin

這個專案對我絕對是加強信念的專案，而且之前開發該工具的經驗，讓我看到一些我可以掌握的功能。看一下問題列表，我的功能並不在上面，所以這個 commit 可能並不容易，而且該專案主要是用 ruby 寫的，看來這裡會有陡峭的學習曲線。

評估：對 OpenShift Origin 的初步印象並不準確。在 CLI 加入新的功能也許沒那麼難，因為 OpenShift Online 的支援區就有一個公開的想法提交頁面。找到該社群的進入點比較困難些。比起核心程式碼，貢獻者頁面更強調加入新框架與語言選項。一旦你投入之後， 有許多不錯的資源可以聯繫該團隊並使用這些工具。這裡也有程式開發指南以及方法論文件。也就是說，我擁有的時間的質和量可以派上用場。學習 Ruby、OpenShift 最佳實踐，還有提出並倡導一項新功能，需要長久穩定的努力。不幸的是，我提出的新功能被埋沒在新點子的佈告欄裡孤芳自賞。

Fedora 基礎建設

從我第一次試圖參與 Fedora 基礎建設之後，該團隊在降低參與門檻上有了很大進步。現在有了新手計劃，一些容易修的臭蟲，一切都為了加快新人上手速度。我已經有了一些接觸與管道，對於跟有著尖峰貢獻時間的人共事，該團隊也很習慣。在這裏我可以有許多貢獻，也能學到很多。

評估：由於我之前曾經參與過基礎建設團隊，我已經在郵件列表上。我已經把 IRC 頻道加入書簽，我也知道如何使用 Trac 以及跟這個團隊合作。新的新手計劃與易修臭蟲對導師系統是很棒的起始點。該團隊要處理許多不同的事情，從映像站台運作、內部雲端系統，到開發內部應用軟體。他們做的東西我很熟悉，我可以找到一些有趣的東西來做。上一次我因為時間問題無法持續參與。依據我的行程，我回到某些能夠以我的步調進行的事項，作為基礎建設團隊的一份子，我想要成為穩定的貢獻者。請注意，這只是我的感覺，不過我確定該團隊不會介意參與中的小小空白。

Atomic 專案

這些日子誰沒有在注意 Docker？Atomic 專案正在為容器 (containers) 打造很有趣的代管平台。Atomic 專案有點像是 OpenStack，Atomic 本身依賴若干不同的上游專案。這些專案有各自的貢獻途徑，被加入到 Atomic 專案的貢獻途徑之中。因為網站上的文件還不完整，這也算是個人小小的冒險。而且假如這個專案難以評估，它的整體體質也會受到大打折扣。開源專案同時需要好的文件和程式碼。對於一位新用戶來說，沒有什麼比下載某個超棒專案的程式碼，結果試著要用時卻找不到用戶文件，更加令人受挫了。本身具有說明性 (self-documenting) 的 API 和指令查詢頁 (man pages) 並不足夠。

評估：Docker 是很新，但 Atomic 專案更新。雖然還沒進入狀況，但很容易就能變成堅實且充滿活力的專案。要找到社群聯絡頁面很簡單，那裡有你著手貢獻所需的一切資訊。有上游專案的連接、公開的 Bugzilla、IRC、郵件列表等等。不幸的是，並不是所有文件都很到位。在這些貢獻頻道裡有循環鏈結，而且入門文件很糟糕。或許我應該先從這裡著手而非開始貢獻程式碼。文件是我現在正在做的部分，裏面有些不同步之處，改進之後能夠為該專案吸引更多用戶與貢獻者。

宣告勝利

著手進行 Atomic 專案

一開始，我查看了專案對貢獻文件的介紹，看起來他們採用新近普及的 fork-and-go 貢獻風格。我可以從這裡開始，確保工具什麼的一切就位，在更進一步前熟悉基本樣式。

文件主要是用 Markdown 寫的，所以應該沒有太多問題。我不懂 HAML 或 Middleman，所以可能會讓事情變得複雜一些。因為我懂 Ruby，HAML 是 ERB 的替代品，所以可能不會有問題。Middleman 伺服器也有 Dockerfile，所以我不需要擔心有關伺服器的學習。

看起來沒有大問題，所以我進一步分支出 GitHub 上該網站專案，好讓我可以在本地端開始動手。現在，我不想在還沒跟團隊接觸，並了解文件方面的計劃之前，就冒然開始動手。這關乎社群貢獻，而不是我向前衝刺後，憑空提交更好的文件修正版本。在貢獻頁面有開發者郵件列表和 IRC 頻道，所以我就從這裡開始。

我找出誰負責文件，發出電郵給團隊，告訴他們我會先看一下，然後為簡單的更新提交 pull request。之後一旦該提交有回應或被接受，我會針對我認為的文件樣貌，提出更大的願景。

如果你想看看我的進展，可以到郵件列表和我的 GitHub repo 來。歡迎自由坦誠的表示意見！