何謂開源編程？

來自專欄 Linux 開源評論10 人贊了文章

開源就是丟一些代碼到 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中國 榮譽推出