點擊上方關注一下git
做者：Ken Wheelergithub
翻譯：EE （開源社文案翻譯組成員）面試
原文：數據庫
https://medium.com/codezillas/a-bitter-guide-to-open-source-a8e3b6a3c1c4npm
嗨，我是 Ken.編程
我在世界上最好的公司 -- Formidable 擔任開源總監。json
若是你之前據說過我，多是由於那麼一兩件事：安全
在 Twitter 上廢話連篇微信
開源數據庫，例如 Slick Carousel, Webpack Dashboard, Spectacle, Cash 等等ide
今天咱們要談的，主要是第二件事。最近（以及過去）有很多人問我可否圍繞開源作些指導，那麼今天個人確想寫一下這方面的內容。
在開始討論技巧以前，我想先談談爲何要作開源項目，以及我本身的經驗。
你爲啥應該寫開源軟件？
關於爲何，有不少緣由能夠解釋爲何開源對你和你的職業發展來講都是一件好事。
它能夠爲你的我的聲譽增添色彩。若是你有一個受歡迎的項目，你們就會熟悉你和你的工做；
它對你的公司品牌有極好的影響。提供和維護一個開源做品集能提升品牌知名度。讓員工有時間在開源上面投入，看到他們的想法變成現實，恰能證實你所在的公司是一個很好的工做場所。
你能夠成長爲一個名副其實的開發者！你再也不是在 /Users/Me/devshit 文件夾中編寫沒什麼人看的業餘項目腳本，那麼多少雙眼睛盯着呢，因此你有動力讓事情推動下去。
你是在幫助他人。你由於 John-David Dalton
這種感受很棒。雖說的是我的的感受，但每次有人由於某個項目對你表示感謝，或者告訴你由於你的代碼節省了他們時間的故事，你會感受很是爽。
這可能不會給你帶來一份工做，由於大多數公司不會嚴格地按照 GitHub star 來招聘員工，可是若是說對你面試沒有幫助，那我就是在說謊。
我在開源軟件上的經驗
先來談點別的。我算是有史以來最差的開源維護者了。好吧，就算不是最差的，至少我每次都沒有盡力作到最好。
我有不少次都沒能妥善管理好開源項目，要不是當初建立他們的時候還算成功我確定涼透了。
不過對於每一個項目，我都從失敗中吸收了教訓，而且利用從中獲得的看法來幫助我下一次作得更好，這些我在後面會介紹。我在這方面確定會變得更好，但我也但願讀者們能從個人錯誤中汲取教訓，而不是重蹈覆轍。
我簡短的說下本身的經歷，由於跟典型的開源軟件經歷相比，個人有點「不走尋常路」。無論你信不信，在我整個職業生涯中我可能只對不屬於我本身的大概20個項目作過貢獻。我只是寫一些東西，而後把它發佈出去。我以爲把這些介紹一下，無論從我的角度仍是從事件背景來講，都還挺重要的。
個人第一個開源軟件項目大概是我最成功的一個項目了。記得那時我在一家廣告公司工做，給位於紐約的大型時尚品牌建立電商網站。我是團隊裏的高級開發人員，一般被安排作大量的JS開發工做。跟我一塊兒回到 jQuery 時代吧。。。
關於時尚電子商務一件頗有趣的事情是，幾乎處處都在使用 carousel。電商網站每每進行精心，複雜，雄心勃勃的設計，結果致使現有的 carousel/slider 庫不夠靈活，難以實現我所要達到的設計目標。因而，我就本身從頭開始用 CoffeeScript 編寫 carousels。 這玩意兒雖然行得通，可是固然並無讓我在同事當中更受歡迎。
因此我看到了一個明確的需求。得有一個足夠靈活的 carousel 插件來應對設計師們丟來的各類東西，使用方便，易於修改。因而，我把它寫出來了。爲了咱們團隊。而後我又想既然這麼有用，爲何不讓別人也節省大把時間出來呢，因此，我將它開源了出來。。。
事實證實它的確爲其餘人節省了大量時間，你們彷佛挺喜歡它。在我發佈它以後的頭幾個月，其熱度簡直突破天際。我是開源軟件的新手，看到你們都在用我寫的東西天然是感到無比興奮，因而我整夜不眠不休地快速解決問題，發佈新版本，確保沒有人能與之匹敵。
我在這裏稍微說得簡短一些，畢竟這是一篇有關技巧的文章，不是講個人故事：最後，我對這個項目再也不關心了。我把這歸由於幾件事上。我換工做了，因此我實際上再也不須要用到 carousels ，我已經置身於問題空間以外。React 出來了，我很早就開始用 React，因此興趣天然不會再在 jQuery上。
可是最大的緣由之一仍是由於我感到筋疲力盡了。我在這個項目上投入太多。而評論裏面各個都自覺得是，抱怨咱們不該該使用 carousels （即便每個賺錢的項目都有一個，並且我還只是拿到了遞交過來的設計而已），我變胖了，惹得我妻子很生氣。
此後，我在不一樣領域又作了幾個流行的庫，每個都用來解決不一樣的問題。我最大的恐懼之一是我再也寫不出來一個流行的庫了，擔憂打擊會隨之而來。我逃避到如今，我能夠一直去寫一些中規中矩的東西，但有一種困擾卻揮之不去-- 我由於管理該死的 carousel 讓大半個互聯網限於癱瘓。
因此，下面就是個人開源軟件技巧，但願你能夠用到它們，作出成功的項目必須付出相應的努力，而不是用威士忌來減輕開源帶來的負罪感。
開源很像作演講。許多人認爲他們推銷給別人的東西價值不高。這簡直大錯特錯。若是你讀過關於「冒名頂替症候羣」的文章，你會發現事實就是這樣。每一個人都有本身的知識領域，一我的不可能通曉全部知識點。總會有人須要你兜售的東西。
我有兩個獨特的優點：a）關我屁事 b)迷之自信，因此我只管把東西寫出來，我知道這兩點對很不少人來講比較難。個人建議是：
可能出現的最壞的狀況？人們會說難聽的話？我來告訴你，孩子，哪怕你拿出最完美，最有用，最打動人心的代碼，把他們放到GitHub上，你猜會怎麼着？照樣有些二貨會進來吐槽發牢騷，這是不可避免的。在最壞的狀況下你也能學到一些東西。有人會這樣說，「嘿，這搞得性能像坨屎」，你可能會回答說，「額。。。我不擅長編程，算了我退出」，可是你也可能這麼回答，「」太棒了，多謝你的提示，我剛修復好了，如今好點了」。要成爲那個讓事情變好的人。
因此你要在哪方面造輪子？好吧，這個問題但是價值百萬美圓啊。
我是這麼看的：
你有一個問題
你有解決這個問題的方法
你把解決方案包裝得很是好，你們都想用你的方案來解決他們的問題
那麼，咱們就來談一下怎麼包裝。。。
因此你有了本身的想法。之前你遇到過一個問題，如今你已經把它解決掉了。可是你想讓其餘人也用你這個方法來解決問題對吧？如下就是一些提示，告訴你如何讓別人也想用你的東西。
首先也是最最重要的，看一看競爭對手和現有的技術。若是你和其餘人的庫作得同樣，那就須要作些東西將它們區別開來。舉個例子，你想要開發下一代 lodash。祝好運（很差意思不得不完成它）。可是除此以外，爲了爭取到 lodash 的市場份額，你得有吸引人之處。你的東西必需要有更小，更快，或者更好的 API。 明白我要講什麼了嗎？
說到 API 設計，就須要作必定的取捨。你可能作了一個庫，開箱即用，可是有人會抱怨說想要調整參數。你可能作了一個史上最靈活，可配置的庫，可是你就變成了 Sean T. Larkin，你們會抱怨爲何還要去配置（Sean，對不起，我是被迫這麼說的。你的v4版本作得很是好）。
你想找到其中的完美平衡，既要開箱即用，又能在必要時進行配置。最重要的是，你想要讓一切變得簡潔，明確，容易上手。不要聰明過頭，不然你會把全部人惹毛！
我喜歡作的一件事是用一種很是明確而非聰明的方式寫個人源代碼。由於這樣可讓別人更容易參與貢獻。進行適當的標註和說明，不要搞自嗨式編程，若是你準備搞一個 hack，留下評論解釋下緣由。
這段時間以來我沒有寫一行代碼，直到我完成了一個心目中想要的模擬的 API。若是你要把它作成真正的 API 的話是要花些時間的，但這是一個值得努力的目標。你會知道何時 API 作對了，由於那個時候你會有想要使用它的感受。
因此你已經在往前走了，解決了問題，將解決方案包裝的不錯，一切準備就緒，是時候發佈它了。可是在此以前，若是你想讓人們使用它，還有些事情必需要作。
1
一些該死的文檔要寫
我真不是在開玩笑。你要寫的必須是史上最好的文檔。避免寫一些像「just」和「simply」這類顯示優越感的字眼。你的文檔開頭要有一個標題連接索引。在入門部門，必須詳細地解釋清楚第一次用這個庫時該怎麼用。對於 API 的每個犄角旮旯都必須編進文檔，以詳細到荒謬的地步所有寫出來。若是你有一個方法，你應該把預期的參數，類型和返回類型都編進文檔。你應該記錄它的功能。應該舉例說明怎麼用。讓別人很容易就能使用你的庫。
你應該在文檔中說明如何作貢獻。你應該在文檔中說明如何運行全部這些編譯的步驟。若是你引用了另一個項目，或者任何一個概念，都要提供對應的連接。若是你引用了任何能夠連接的東西，請把連接加上。
文檔工做要作得完全，這會讓你的項目有很大的不一樣。
2
一些該死的測試要寫
聽我說完。你應該把測試覆蓋到合理的佔比。緣由在於：
它使你對本身庫的穩定性有必定的自信；
它將使你在合併 PRs 時更有信心；
它讓你在離開這個項目一段時間後再回來仍然滿懷信心地爲它工做。
有一次我發佈了一個庫，沒有作測試，Paul Irish 隨口說了句，「若是測試一下會很酷」。Paul說話了我還有啥好說的，就乖乖去寫測試了。沒想到，我居然找到了 15 個bug！感謝 Paul！
強烈建議，無論你作了什麼東西，都寫一些該死的測試。錦上添花哦。它爲我節省了不少時間，心情也沒那麼糟。
寫完測試以後，把它在 Travis 或者別的什麼地方設置好，而後你就能夠安心睡覺去了。
3
使用類型
測試沒有覆蓋到的，類型來補救。如今若是你不對你的 JS 劃分類型，就好像開車沒系安全帶。此外，隨着愈來愈多的人使用 TS 或者 Flow，他們開始但願類型已經就位。用類型編寫庫，導出和提供類型，你會感謝個人。不然後面讓別人標註類型，那就是第三方風格的，過期的，還多是錯誤的。你看着辦吧。
4
Repo （代碼庫）的先決條件
README.md
CONTRIBUTING.md
LICENSE.txt
一個有效的，完整的 package.json
README，就不說了。你應該始終包含一個 LICENSE.txt，不然有些人就用不了你的代碼庫。受權用 MIT 協議。不要自做聰明本身寫一些受權聲明。就用 MIT。用它就對了。
CONTRIBUTING.md 是個好地方，不只能夠規定如何爲項目工做，還能夠連接/添加行爲準則。添加行爲準則，無論你是否定同這個概念，相信我，它會讓貢獻和參與項目的一些人感到舒服，從此你要是遇到問題了，也能夠把它祭出來踢走使人討厭的人。
5
加分項
假設你已經寫出了很棒的文檔，API 設計緊湊，全部的先決條件已經就位，這時候你開始準備讓代碼庫在發佈以前看起來像模像樣了，這裏我有些建議。
徽章。沒有什麼能比徽章讓你的 repo 看起來更正規的了。徽章太多看上去亂七八糟，可是若是你抓住有用的幾個，那就是合法性的標誌。說明你關心合法性這件事情。像 npm 版本，測試狀態，覆蓋率等等都是很好的徽章。
此外，Mardown 支持原始 HTML，這會讓你的代碼庫標題看上去更漂亮。居中，加一段引言，美化一下。
若是你真的想作到最好，那就在這裏 https://github.com/kentcdodds/all-contributors 添加貢獻者名單。Kent C. Dodds
一切都恰到好處，是時候閃亮登場了。你怎麼讓你們過來看看並使用你的新庫呢？
我有一條特別建議。週一中午12點（美國東部時間）發佈。這個時間，在歐洲正好是下班時間，在紐約是午飯時間，在舊金山是早晨--忙碌的一天即將開始。你有一大批目標觀衆正無所事事地在網上閒逛呢。
至於如何發佈，我認爲 Twitter 是第一站。表達誇張一點，
「厭倦了敲鍵盤寫 CSS? 你如今能夠用一個 XBox 控制器寫啦！」，
「堆棧跟蹤讓你掉進了溝裏？若是他們能夠用炫酷的 VR 進行跟蹤呢！」
作本身想作的。可是要有吸引力，而且使用圖片，或者視頻。讓人立馬瞭解這個東西是什麼，爲何他們要使用它，給一個連接。過程大概是：
瀏覽 Twitter
噢，看看這條推送
什麼玩意兒！這東西竟然能作這個？！
點擊連接
進入到代碼庫，感受還挺酷
點擊開始
複製/粘貼到終端，放開浪
【點擊開始按鈕】
你能走多遠，就要看你的粉絲量以及你向他們推銷的技術方向，這一般是有效的招數。除了 Twitter, 在 HN 和 Reddit 上發佈效果也不錯。
另外，若是你以爲有必要，就在發佈的時候附上一篇博客文章，尤爲是以公司的名義進行的發佈。你能夠用更長的內容來展現它。
要大膽。要自信。準備好迎接外界的批評。
我一直懼怕到這一步，由於一到這裏，個人經驗總會把事情搞得一塌糊塗。可是我很高興能和你們分享我從各類失敗中獲得的教訓，但願你們可以瞭解接下來會發生什麼事情。
如今你發佈了庫。它有兩種結局：
1
以失敗了結
誰會在乎呢？我老是碰到這種狀況，重頭再來唄。有時候沒火起來並不表明你很失敗或者你的想法不行。只是沒到火候而已。重要的是你作了，你作對了。當你下次再開發東西的時候，你離成功會更進一步。給本身點鼓勵，從新出發！
2
大受歡迎
這纔是真正讓你頭疼的呢。你們喜歡你的東西。在 twitter 上轉發。這時你要不斷地修復 bug，回答問題，捍衛本身的想法。對此我有一些建議。
首先，若是任何人對摺騰你的庫感興趣，就將他們發展成 maintainer。堅持這一點很重要！由於隨着時間流逝，新的技術不斷涌現，隨之會產生不少新的問題。你本身也會變。而你的代碼庫還在那裏。若是你不委派別人，就等於給本身挖了個坑。你會由於維護而累得精疲力盡，會開始厭惡本身的項目直到它爛成一坨狗屎。相信我，交給別人去維護。
接下來，我要談談怎麼與人相處。
這是開源最大的部分之一。不少時候都比寫代碼更加劇要。人們開始吐槽你了，他們各個都以爲本身有這個資格，他們會公開攻擊你的項目。
理這些人幹嗎！
我浪費了不少時間跟這些人理論，如今我但願這些精力能花在別的地方。相信我，讓噴你的人見鬼去，別理他們。
可是，要注意鑑別噴子。有的人看上去像噴子，其實並非。想一下，你是在向全世界發佈開源項目。假設你是美國人，發佈的時候使用的是英文，請記住不是每一個人都會說英語。
想象一下你想爲一個用俄語寫的代碼庫作貢獻。但你不懂俄語。因而你用 Google Translate 將這句話翻譯成俄語， 「嗨，這個項目有實現的時間表嗎？」。而後比方說俄語翻譯過來是，「這個何時能完成？」。乍一眼看過去你可能會以爲，「嗨，這傢伙是否是有毛病啊？」，可是後來你才意識到在互聯上意思的傳達作得不是那麼好，通過翻譯傳達以後就更加不對勁了。
要注意的是，有時候別人不是笨蛋，他們只是不會說你的語言罷了。
除此以外，我能告訴你的最好的方法就是你的 PRs 要有一個牢靠的 CI （持續集成），要列出 issues，要有 PR 模板。在代碼庫上你會遇到成堆的 issues 和 PRs，若是想要管理好它們，你得樹立一些基本規則。個人建議是：
要求重現案例或者失敗測試案例
要求提供 bug 產生的情形
你是沒有時間找出某些一次性的 bug 的。讓用戶向你證實這個 bug 的存在而且讓你易於識別。這樣你纔會花時間去修復它。
並且，在 CONTRIBUTING.md 的某處指出你們應該在處理 PR 前在 issue 裏面跟你先討論想法是值得的。世上最悲哀的事情莫過於努力地去處理一個永遠都不會被接受的 PR。
談到接受 PRs，在這一部分我最後想說的就是你沒必要去作別人要求你作的事情。我就由於屈服於用戶而浪費了不少力氣就爲作個 API 出來。大多數時候，有些人只是由於他們遇到的一個孤立的小問題而須要一些東西，可是這對整個廣大的社區是沒有價值的。要警戒對你的 API 的任何改動，由於那些帶着極端需求的人會把你的 API 搞得一團糟。要爲核心庫作正確的事情，而不是幫一些搞滑翔機遙測系統的傢伙去解決問題。
哦，我說謊了，我要說的最後一件事應該是：正確地使用語義版本控制。
必定要這麼作。不然，每一個人都會失去理智的。還有推送標籤。還要寫版本說明。詳細的版本說明。隨着你的庫的不斷演進，讓投入到裏面的各方知道發生了什麼是很是重要的。
保持透明，清晰和信息健全。不要在沒有寬限期的狀況下棄用任何東西。若是你們用了你的庫，而你繼續改東西，讓他們的應用程序出問題，別人是不會開心的。以一種富有同理心的方式去升級你的庫。
到此爲止，你大概明白了我不止在開源軟件上作得很糟糕，寫文章也不在行。可是既然有人在問，那我就寫了。我但願這篇流水帳可以幫助到那些想發佈本身的開源項目的人，讓他們能節省一些時間和精力。
這裏面要注意的事有不少，可是若是你每同樣都能符合要求，你的日子會比我好過，成功的機會也會更大。
儘管如此，我還有最後一個建議。除非你真的想作，不然就不要作。不要以爲這是你必須作的。不作這個，你同樣能夠找到工做。不作這個，你同樣能夠成爲好的開發。我從中獲益匪淺，也享受於此，可是我永遠也無法把我免費花在庫上的時間給找回來了，那些時間我本能夠用來陪伴家人，追求本身喜歡的事情，作任何能夠給我帶來可觀收入的事情。由於想作纔去作。若是你對本身開發的東西沒有激情，可能就不會成功。
*本文經原做者受權後編譯發佈*
*本文全部圖片均下載自谷歌圖片庫*
本文分享自微信公衆號 - 開源社（kaiyuanshe）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。