何謂開源程式設計？

開源就是丟一些程式碼到 GitHub 上。瞭解一下它是什麼，以及不是什麼？

最簡單的來說，開源程式設計就是編寫一些大家可以隨意取用、修改的程式碼。但你肯定聽過關於 Go 語言的那個老笑話，說 Go 語言“簡單到看一眼就可以明白規則，但需要一輩子去學會運用它”。其實寫開原始碼也是這樣的。往 GitHub、Bitbucket、SourceForge 等網站或者是你自己的部落格或網站上丟幾行程式碼不是難事，但想要卓有成效，還需要個人的努力付出和高瞻遠矚。

我們對開源程式設計的誤解

首先我要說清楚一點：把你的程式碼放在 GitHub 的公開倉庫中並不意味著把你的程式碼開源了。在幾乎全世界，根本不用創作者做什麼，只要作品形成，版權就隨之而生了。在創作者進行授權之前，只有作者可以行使版權相關的權力。未經創作者授權的程式碼，不論有多少人在使用，都是一顆定時炸彈，只有愚蠢的人才會去用它。

有些創作者很善良，認為“很明顯我的程式碼是免費提供給大家使用的。”，他也並不想起訴那些用了他的程式碼的人，但這並不意味著這些程式碼可以放心使用。不論在你眼中創作者們多麼善良，他們都 有權力 起訴任何使用、修改程式碼，或未經明確授權就將程式碼嵌入的人。

很明顯，你不應該在沒有指定開源許可證的情況下將你的原始碼釋出到網上然後期望別人使用它併為其做出貢獻。我建議你也儘量避免使用這種程式碼，甚至疑似未授權的也不要使用。如果你開發了一個函式和例程，它和之前一個疑似未授權程式碼很像，原始碼作者就可以對你就侵權提起訴訟。

舉個例子，Jill Schmill 寫了 AwesomeLib 然後未明確授權就把它放到了 GitHub 上，就算 Jill Schmill 不起訴任何人，只要她把 AwesomeLib 的完整版權都賣給 EvilCorp，EvilCorp 就會起訴之前違規使用這段程式碼的人。這種行為就好像是埋下了電腦保安隱患，總有一天會為人所用。

沒有許可證的程式碼的危險的，切記。

選擇恰當的開源許可證

假設你正要寫一個新程式，而且打算讓人們以開源的方式使用它，你需要做的就是選擇最貼合你需求的許可證。和宣傳中說的一樣，你可以從 GitHub 所支援的 choosealicense.com 開始。這個網站設計得像個簡單的問卷，特別方便快捷，點幾下就能找到合適的許可證。

警示：在選擇許可證時不要過於自負，如果你選的是 Apache 許可證或者 GPLv3 這種廣為使用的許可證，人們很容易理解他們和你都有什麼權利，你也不需要請律師來排查其中的漏洞。你選擇的許可證使用的人越少，帶來的麻煩就越多。

最重要的一點是： 千萬不要試圖自己製造許可證！ 自己製造許可證會給大家帶來更多的困惑和困擾，不要這樣做。如果在現有的許可證中確實找不到你需要的條款，你可以在現有的許可證中附加上你的要求，並且重點標註出來，提醒使用者們注意。

我知道有些人會站出來說：“我才懶得管什麼許可證，我已經把程式碼發到公開領域public domain了。”但問題是，公開領域的法律效力並不是受全世界認可的。在不同的國家，公開領域的效力和表現形式不同。在有些國家的政府管控下，你甚至不可以把自己的原始碼發到公開領域。萬幸，Unlicense 可以彌補這些漏洞，它語言簡潔，使用幾個詞清楚地描述了“就把它放到公開領域”，但其效力為全世界認可。

怎樣引入許可證

確定使用哪個許可證之後，你需要清晰而無疑義地指定它。如果你是在 GitHub、GitLab 或 BitBucket 這幾個網站釋出，你需要構建很多個資料夾，在根資料夾中，你應把許可證建立為一個以 LICENSE.txt 命名的明文檔案。

建立 LICENSE.txt 這個檔案之後還有其它事要做。你需要在每個重要檔案的頭部新增註釋塊來申明許可證。如果你使用的是一個現有的許可證，這一步對你來說十分簡便。一個 # 專案名 (c)2018 作者名，GPLv3 許可證，詳情見 https://www.gnu.org/licenses/gpl-3.0.en.html 這樣的註釋塊比隱約指代的許可證的效力要強得多。

如果你是要釋出在自己的網站上，步驟也差不多。先建立 LICENSE.txt 檔案，放入許可證，再表明許可證出處。

開原始碼的不同之處

開原始碼和專有程式碼的一個主要區別是開原始碼寫出來就是為了給別人看的。我是個 40 多歲的系統管理員，已經寫過許許多多的程式碼。最開始我寫程式碼是為了工作，為了解決公司的問題，所以其中大部分程式碼都是專有程式碼。這種程式碼的目的很簡單，只要能在特定場合透過特定方式發揮作用就行。

開原始碼則大不相同。在寫開原始碼時，你知道它可能會被用於各種各樣的環境中。也許你的用例的環境條件很侷限，但你仍舊希望它能在各種環境下發揮理想的效果。不同的人使用這些程式碼時會出現各種用例，你會看到各類衝突，還有你沒有考慮過的思路。雖然程式碼不一定要滿足所有人，但至少應該得體地處理他們遇到的問題，就算解決不了，也可以轉換回常見的邏輯，不會給使用者添麻煩。（例如“第 583 行出現零除錯誤”就不能作為錯誤地提供命令列引數的響應結果）

你的原始碼也可能逼瘋你，尤其是在你一遍又一遍地修改錯誤的函式或是子過程後，終於出現了你希望的結果，這時你不會嘆口氣就繼續下一個任務，你會把過程清理乾淨，因為你不會願意別人看出你一遍遍嘗試的痕跡。比如你會把 $variable、$lol 全都換成有意義的 $iterationcounter 和 $modelname。這意味著你要認真專業地進行註釋（儘管對於你所處的背景知識熱度來說它並不難懂），因為你期望有更多的人可以使用你的程式碼。

這個過程難免有些痛苦沮喪，畢竟這不是你常做的事，會有些不習慣。但它會使你成為一位更好的程式設計師，也會讓你的程式碼昇華。即使你的專案只有你一位貢獻者，清理程式碼也會節約你後期的很多工作，相信我一年後你再看你的 app 程式碼時，你會慶幸自己寫下的是 $modelname，還有清晰的註釋，而不是什麼不知名的數列，甚至連 $lol 也不是。

你並不是為你一人而寫

開源的真正核心並不是那些程式碼，而是社群。更大的社群的專案維持時間更長，也更容易為人們所接受。因此不僅要加入社群，還要多多為社群發展貢獻思路，讓自己的專案能夠為社群所用。

蝙蝠俠為了完成目標暗中獨自花了很大功夫，你用不著這樣，你可以登入 Twitter、Reddit，或者給你專案的相關人士發郵件，釋出你正在籌備新專案的訊息，仔細聊聊專案的設計初衷和你的計劃，讓大家一起幫忙，向大家徵集資料輸入，類似的使用案例，把這些資訊整合起來，用在你的程式碼裡。你不用接受所有的建議和請求，但你要對它有個大概把握，這樣在你之後完善時可以躲過一些陷阱。

釋出了首次通告這個過程還不算完整。如果你希望大家能夠接受你的作品並且使用它，你就要以此為初衷來設計。公眾說不定可以幫到你，你不必對公開這件事如臨大敵。所以不要閉門造車，既然你是為大家而寫，那就開設一個真實、公開的專案，想象你在社群的幫助和監督下，認真地一步步完成它。

建立專案的方式

你可以在 GitHub、GitLab 或 BitBucket 上免費註冊賬號來管理你的專案。註冊之後，建立知識庫，建立 README 檔案，分配一個許可證，一步步寫入程式碼。這樣可以幫你建立好習慣，讓你之後和現實中的團隊一起工作時，也能目的清晰地朝著目標穩妥地開展工作。這樣你做得越久，就越有興趣 —— 通常會有使用者先對你的專案產生興趣。

使用者會開始提一些問題，這會讓你開心也會讓你不爽，你應該親切禮貌地對待他們，就算他們很多人對專案有很多誤解甚至根本不知道你的專案做的是什麼，你也應該禮貌專業地對待。一方面，你可以引導他們，讓他們瞭解你在幹什麼。另一方面，他們也會慢慢地將你帶入更大的社群。

如果你的專案很受使用者青睞，總會有高階開發者出現，並表示出興趣。這也許是好事，也可能激怒你。最開始你可能只會做簡單的問題修復，但總有一天你會收到拉取請求，有可能是硬編碼或特殊用例（可能會讓專案變得難以維護），它可能改變你專案的作用域，甚至改變你專案的初衷。你需要學會分辨哪個有貢獻，根據這個決定合併哪個，婉拒哪個。

我們為什麼要開源？

開源聽起來任務繁重，它也確實是這樣。但它對你也有很多好處。它可以在無形之中磨練你，讓你寫出純淨持久的程式碼，也教會你與人溝通，團隊協作。對於一個志向遠大的專業開發者來說，它是最好的簡歷素材。你的未來僱主很有可能點開你的倉庫，瞭解你的能力範圍；而社群專案的開發者也有可能給你帶來工作。

最後，為開源工作，意味著個人的提升，因為你在做的事不是為了你一個人，這比養活自己重要得多。

---

via: https://opensource.com/article/18/3/what-open-source-programming

作者：Jim Salter 譯者：Valoniakim 校對：wxy、pityonline

本文由 LCTT 原創編譯，Linux中國 榮譽推出