開源：沒那麼可怕！

以下是在 Toptal 女性開發者獎學金推出之前發布的。

作為開發人員，跟上最新的技術趨勢是令人興奮和具有挑戰性的。 每天，新的語言、框架和設備都會吸引我們的注意力，並在聚會、論壇和聊天中激發對話。 然而，我們的開發者社區是由人組成的，而不是工具，探索它的社會政治方面是很有趣的（因為沒有更好的詞；如今，“社會”往往與社交網絡相關聯）。

在 Toptal，我們最近就女性為開源做出了多少貢獻以及可能阻止她們做出更多貢獻的原因進行了一些有趣的對話，因此我們對此事進行了調查。 在與 Breanden Beneschott 和 Bozhidar Batsov 進行了對話後，我想知道：Bozhidar 是 GitHub 上的頂級開源貢獻者之一。 我在哪裡？ 如果你今天查看我的公共 GitHub 帳戶，它主要是我在課堂上為我的學生使用的小型測試項目。 它們是半生不熟的，絕對不能代表我的技能或專業知識。 （你必須相信我的話。）如果有人考慮根據他們在該帳戶中找到的內容來僱用我，我想我將很難謀生。 儘管如此，我從事專業開發人員已有 20 多年了，在我的日常工作中，我使用的開源軟件比我想記得的要多。 隨著時間的推移，我已經破解了 Linux 內核以使其適應某些特定需求，調整了我購買的每台路由器和 NAS，耐心地在 Raspberry Pi 等候名單中等待了幾個月，才拿到它，並獲得了我自製的家庭電話。我喜歡。 儘管如此，這些調整和測試都沒有進入我的 GitHub 以成為開源。 此外，除了修復 Tomcat 的第一個版本中的一個錯誤之外，我從未為開源項目做出過貢獻。 很好奇，不是嗎？

你可能認為這只是缺乏時間或興趣，但我知道事實並非如此。 至於我的個人項目，我可能認為沒有人會對我所做的事情真正感興趣，但大多數情況下，只是將我的作品發表在那裡，讓每個人都可以看到並為後代所用的想法讓我很害怕。 雖然你總是可以從 GitHub 上刪除一個個人項目，但在你嘗試為一個廣泛可用的開源項目做出貢獻的那一天，沒有回頭路。 如果我的代碼不夠好怎麼辦？ 如果我沒有正確理解問題怎麼辦？ 如果我的拉取請求被拒絕怎麼辦？ 如果人們拖釣我怎麼辦？

與開發人員朋友（主要是女性）進行了一輪快速通話，很快就說服了我，我不是唯一一個遇到這個問題的人，但對於工程師來說，沒有問題，只有解決方案，對吧？

這是一個需要解決的重要問題，因為為開源項目做出貢獻可以產生巨大的影響：

• 在您的職業生涯中：許多客戶在決定僱用您之前會查看您的社交一切； 您的 GitHub 帳戶和您的 LinkedIn 簡歷以及您的 Facebook 和 Twitter 個人資料都位居榜首。 你應該明智地使用它們。
• 對於您的技術技能：檢查由其他開發人員編寫的代碼庫，通常是非常好的開發人員，可以教給您很多東西。 從寫得不好的代碼庫中提取意義的能力同樣會挑戰並教會你很多東西。
• 對於您的軟技能：開源軟件是一個協作過程，幾乎所有有趣的項目都是由團隊構建的。 學習通過每個人都使用的工具與其他開發人員合作，融入團隊，高效溝通，這將使您成為一名出色的開發人員，而不僅僅是一個熟練的開發人員。
• 對於社區：您為開源項目做出的每一點貢獻都很重要。 您貢獻的越多越好，但即使在翻譯中修正一個小錯字也會使最終產品更好。
• 對於您的網絡：您可以向公司發送數百份簡歷，但沒有什麼比擁有具有個人關係的同事更有效的了。 積極參與開源項目將確保您結識人們並獲得他們的尊重，並且您的聲譽將會增長，這對於任何專業人士來說都是無價的。

這是我與這種恐懼作鬥爭的個人小旅程。 發表這篇文章是旅程本身的一部分。 我寫這篇文章是希望任何被阻止寫博客文章的人，或者害怕做出哪怕是很小的貢獻的人，最終都會看到，它並沒有那麼可怕。 此外，它旨在幫助任何願意為開源做出貢獻但不知道從哪裡開始的人，所以我將從基礎開始。

什麼是開源軟件，我在哪裡可以找到它？

開源軟件，簡稱 OSS，是任何隨其源代碼一起發布的軟件，並包含一個允許您對其進行修改和重新分發的許可證。 它可以在任何地方交付：在網站上、通過郵件列表或貓頭鷹。 最常見的場景，也是我們感興趣的場景，是代碼庫維護在協作存儲庫上。 在這裡，我們專注於 GitHub，但還有其他選項，例如 SourceForge 和 Bitbucket。 GitHub 非常友​​好，擁有龐大的用戶群，可以用於任何類型的代碼，並且可以與您使用的任何開發環境配合使用。 重要的是，它也被廣泛用於非開源項目。 您的下一個客戶項目很可能會在那里托管，因此知道如何使用它本身就是一項有用的技能。

如果我不知道如何編碼怎麼辦？

如果您正在閱讀本文，您可能想學習如何編碼。 您可以在幾個免費和付費網站上找到精彩的課程。 你應該選擇一種語言來學習； 如果您沒有偏好，請使用 JavaScript。 您已經擁有了在 Web 瀏覽器上啟動所需的一切，它是使用最廣泛、最暢銷的技能之一。 我個人最喜歡的是 Python，它同時用於 Web 開發和科學應用程序。 我也有個人最喜歡的初學者課程，Udacity 上的“計算機科學入門”。 我喜歡它，因為它是一門動手實踐的課程，您可以邊學習邊做項目。 您還可以在 Coursera、可汗學院和 PluralSight 上找到其他幾門課程。

如果我不知道 Git 怎麼辦？

如前所述，了解 Git 很重要，因此，參加 Git 課程。 即使你已經使用 Git 一段時間了，也要這樣做； 在你真正研究它之前，你不會知道你對 Git 的了解有多少。 如果您不能自信地解釋rebase命令的作用，請執行此操作。 即使錯誤的變基不會嚇到你，也要這樣做。 我在 Code School 上採用了完整的 Git 路徑，但同樣，您可以探索其他站點以獲取更多選項。

如何在 GitHub 上選擇項目？

您可能在日常開發中使用了一些 OSS。 選擇一個熟悉的框架是一個很好的起點； 您已經熟悉這些功能以及框架的工作原理。 當你深入到源代碼中，你會學到更多，你會更清楚地理解它的邏輯。 如果有您特別喜歡的技術或工具，請查找提及它的項目，或該工具的項目本身。 作為最後的手段，您可以查看 GitHub Showcases 上的項目，然後從選擇您感興趣的類別開始。

例如，在 GitHub 的搜索中快速搜索“Raspberry”會顯示超過 17,000 個存儲庫。 很容易迷路，所以找一個有良好社區和良好問題跟踪的項目。 選擇項目時，請檢查以下數量：

• 貢獻者：針對十個以上的貢獻者。 這應該確保項目有足夠的興趣，而不僅僅是一個小團隊的努力。 如果您是 OSS 新手，或者不太熟練，請將您的搜索限制在最多有 50 個貢獻者的項目； 更大的社區意味著更大的代碼庫和更複雜的項目。
• 提交：選擇至少有一千次提交的項目，並且最近的活動不超過一周。 一個已經閒置一個月或更長時間的項目在 OSS 術語中是陳舊和陳舊的，您可能不會很快得到任何響應。 日常活動是健康項目的標誌。
• 問題：問題是未解決的問題、已報告的錯誤或要求實施的功能。 它們將為您提供一個起點，並且是衡量項目興趣的良好指標。

另外，找出項目的主要語言是什麼； 您可以在項目主頁面的頂部欄中看到語言統計信息。 花一些時間閱讀討論的語氣，看看評論是多麼友好和有教養。 有些項目因其激進的社區而臭名昭著，因此它們可能不是正確的起點。

我選擇了 ScyllaDB，一個列式數據存儲項目，因為我對數據很著迷——任何與性能相關的東西。 我從未使用過它，但我希望能夠深入研究它的代碼庫。 使用我知道的工具可能會更簡單，但我將此視為挑戰和學習新事物的機會。 其餘的，它完全符合要求。 它有 18 個貢獻者，6.5k 次提交（最近一次是在撰寫本文時 23 小時前），178 個未解決的問題，並且看起來很活躍。

現在我該怎麼做？

首先，克隆存儲庫並在您的機器上安裝軟件以了解其移動部件。 然後，開始閱讀這些問題。 一旦你覺得準備好了，看看你是否可以在你的機器上重現這個問題，然後開始分析是什麼讓軟件行為不端。

另一種方法是找到可以自己改進或修改的東西。 例如，您可能注意到錯字或未對齊的字體。 我選擇修復一個小錯誤，特別是腳本文檔中使用的錯誤變量名。

它看起來很小，但是錯誤的文檔比沒有文檔要糟糕得多。 用戶將安裝 ScyllaDB 並按照安裝步驟進行操作，他們將盲目地依賴該腳本中編寫的內容，最終會感到沮喪。 這對我的能力來說是完美的，修復它需要我遵循整個過程，並熟悉代碼庫。 錯誤修復很無聊，但它是找到進入項目的方式的一個很好的開始。

創建分叉

這可能是微不足道的，但目前，對於 ScyllaDB 項目，我是 Ms.Nobody； 讓我在沒有監督的情況下更改他們的代碼是有風險的。 我需要做的是在我自己的 GitHub 帳戶中創建一個“fork”。 這是我的 ScyllaDB 分支。 這是我自己的遊樂場，我可以訪問所有代碼，並且可以根據需要修改文件。 如果我想創建自己的 ScyllaDB 版本並對其進行調整以完成與最初目的完全不同的事情，我可以在這裡進行。 創建分叉很簡單； 轉到項目的主頁並單擊“fork”按鈕。 一點都不可怕。

是時候修復錯誤了

現在，是時候在您的計算機上測試代碼並進行必要的修改了。 首先，確保你已經在你的機器上安裝了 Git 客戶端。 然後，將您的 SSH 公鑰添加到 GitHub，並確保它已由您的 ssh-agent 加載。 在本地獲取代碼很簡單； 只需使用指向你的 fork 的git clone命令，而不是主分支：

 git clone [email protected]:acbellini/scylla.git

到目前為止，您應該已經在主分支上測試了項目，因此您將在本地構建代碼並以相同的方式對其進行測試。 請記住，您必須分叉您的項目所依賴的任何其他 GitHub 項目，因為引用是相對的。 就我而言，我不得不分叉 seastar、scylla-ami 和 scylla-swagger-ui。

我需要修復的bug比較簡單； conf/scylla.yaml中的文檔提到了三個可配置的目錄：一個用於數據文件，一個用於提交日誌，一個顯然未使用，用於緩存，所有這些都默認為$CASSANDRA_HOME的某個子目錄：

深入研究代碼，它表明默認值是不同的，正如我開始的問題 #372 中所述，不應使用$CASSANDRA_HOME 。 我通過使用幾個不同的設置測試代碼、從配置文件中刪除設置並檢查使用了哪些目錄來驗證我的假設。 一旦確信一切都是正確的，我可以添加、提交和推送修改後的文件：

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

請注意，我在提交消息中引入了問題編號，前面有一個哈希。 這將告訴 GitHub 自動將我的代碼鏈接到問題本身。

另一個需要注意的重要事情是，當我查看代碼時，我意識到第三個目錄，即緩存的目錄，實際上並沒有使用。 很容易走得太遠並刪除此設置本身，或添加未使用的註釋，但這將超出問題 #372 的範圍，並且提交與此不嚴格相關的任何內容都是錯誤的問題。 您必須使您的更改集中並僅限於手頭的任務。

至此，代碼已修復，位於 GitHub 上，位於我的私人分支中。 這就是可怕的部分出現的地方：要求 ScyllaDB 人員接受我的代碼。 這稱為拉取請求。

最後一步：拉取請求

我喜歡直接從 GitHub 上的 Web 界面創建拉取請求。 我發現它比嘗試從命令行執行它更直觀和防錯。 創建拉取請求所需要做的就是單擊分支名稱旁邊的綠色小按鈕：

請注意，評論是由 GitHub 自動計算的。 我的分支現在有一個新的提交，但是自從創建我的分叉後，主存儲庫中還有 14 個提交，所以我將單擊左側的綠色圖標。

幸運的是，我的單個提交與其他 14 個提交沒有衝突，所以 GitHub 通知我我很高興。 我不需要添加任何其他評論或消息。 提交消息雖然很短，但說明了一切：我的代碼更改做了什麼以及它與什麼相關。 當我單擊最後一個按鈕以確認我的請求時，我想知道幾天前我發現如此可怕的是什麼。 現在沒有怪物在向我咆哮，地獄之火似乎也沒有燃燒。 老實說，這並不可怕。 在不太可能的情況下，我弄錯了，我的修復將不會被接受，就是這樣。

如果您現在檢查問題詳細信息，您可以看到 GitHub 自動添加了一條註釋，說明有一個拉取請求引用了此問題。 這就是提交消息中#372 的神奇之處。 這將有助於避免其他人浪費時間來修復已經修復的問題。

最後的筆記

現在我正在等待我的拉取請求被接受，當發生這種情況時我會收到通知。 請記住，這可能需要幾天甚至幾週的時間； 有人必須審查我的代碼，測試它是否按描述工作，修復問題，並最終確保它不會對其餘代碼的功能產生不利影響（閱讀：創建新錯誤）。 所有這些都需要一些人的時間，所以請耐心等待。 最後，當我的拉取請求被接受時，ScyllaDB 將多一個貢獻者，少一個問題，我將有我的第一個 OSS 貢獻。 現在，您也可以嘗試一下。 畢竟，它一點也不可怕。