登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 本網站預計持續維運至 2021年底,網站內容基本上不會再更動。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
自由專欄 正確選擇?四套開源專案評估

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

本文翻譯自 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 來。歡迎自由坦誠的表示意見!




自由軟體鑄造場電子報 : 第 252 期 淺談自由開源商業終端使用者之善意保護

分類: 自由專欄