標籤：

維護一個大型開源項目是怎樣的體驗？

11-25

（我認為）大型開源項目包含以下任意一個或多個特徵：

  • GitHub star 數量 1000 +
  • 每周都可以接收到多個 issues 或 PR
  • 有一些公司或其他項目在生產環境中使用
  • 任意一個或多個包管理系統中下載量巨大
  • 在項目所在領域中擁有較大關注度

可以從以下幾個方面進行回答。

  • 先介紹你的項目，用來幹什麼的？
  • 在開發和維護的過程中遇到過哪些值得一提的事？
  • 有沒有什麼奇葩的 issue 或者 PR？
  • 對你的生活或者工作有沒有造成影響（好的，壞的）？

加入 Visual Studio Code - Code Editing. Redefined 快一年，趁這個機會聊一聊開發和維護這個項目的感受，如果大家不反對這是一個 大型 開源項目的話。以下為個人理解，不代表公司也不代表團隊。

項目

Visual Studio Code 的目標是做一個 Lightweight Editor，通過的擴展 api，讓用戶在 VS Code 中達到和 IDE 中接近的開發體驗（效率）。

不過很多群眾對 VS Code 有諸多誤解，我先來一一解答

  1. 「VS Code 師出 VS，是 VS 找了一群人來重寫的，復用了很多 VS 的代碼，等等「。很抱歉，並不是這樣，半毛錢關係也沒有。VS Code 的核心代碼，也就是 Microsoft/monaco-editor 是 Erich Gamma 2011 年加入微軟後，招聘的一支「全新」的隊伍進行開發的。Monaco editor 從一開始就是一個 browser based editor，早期一直服務於各個微軟系統中（比如 Visual Studio Online，OneDrive online）。招聘的這支隊伍對於 Erich 來說並不是新的，因為大部分成員都是原先 IBM 的老部下，其中幾位大爺跟著 Erich 擼了二十多年代碼了。
  2. "VS Code 是 Atom 的復刻，是對 Atom 的魔改，是 Atom 的一個主題！"。很抱歉，並不是這樣，但還是有幾毛錢關係的。Monaco Editor 在經歷幾年的高光期，進入了一個小小的黑暗時代。這時候團隊成員開始調研將 Monaco Editor 做成桌面應用，和 Atom 一樣，我們首先關注到的就是 node-webkit。必須說 node-webkit 是業界的一縷清風，給這個產業帶來了太多的可能性。當然最後我們選用了 atom-shell，也就是後來的 Electron。但就是這個 atom-shell，給大家帶來了以上的誤導。

最後，我們一定要尋根問祖的話，VS Code 應該是師出 Eclipse（同志們，哎你們怎麼扭頭走人了，別怕，我話沒說完呢）。團隊核心的幾位大爺，早年就跟著 Erich，在寫了幾個 Editor／IDE 之後，創造了 Eclipse。正是因為見證了 Eclipse 的興衰，所以這一次在設計 Monaco／VS Code 的時候，才會如此的剋制。Extensibility 不好嗎？當然好，但是 Eclipse 的弊端已經在一些競爭對手身上出現啦。

開發／維護

我 13 年加入微軟後，就開始接觸到 Monaco 了。在使用的過程中踩了一些坑，研究過代碼，做過好一些擴展。所以在 VS Code 正式開源後以及上線 Marketplace 後，我就開始動手寫一點插件和發 Pull Request。去年五月得空和團隊結對編程了兩個禮拜後，就加入了 VS Code。

VS Code 的開發幾乎完全是公開的。早期我們還通過 User Voice 收集反饋，但我們早就把它關掉了，所有問題的處理都放在 GitHub 上。我們的 Yearly/Monthly plan 都以 issue 的形式呈現 Microsoft/vscode ，而我個人正常的開發節奏是這樣的：

計劃

在上一個 milestone 快結束、新的 milestone 開始的第一周，和老闆溝通新的 milestone 自己想做的功能。以及自己要不要休假。

Debt Week

我們把新 Milestone 的一周當作 debt week，集中處理一些技術債，以及為一些插件做點微小的貢獻。我一般會花一點時間在 Vim 插件以及我自己的 Ruby 插件上。

開發

這之後就是兩到三周正常的開發。每天起床得先把自己頭上的新 issue 都 triage 一遍，遇到緊急的得先修，不然就繼續完成自己的 feature。

Inbox Tracking

我加入團隊的時候，我們只有 1700 個左右的 issue，現在已經破 4000 了（大部分都是 feature request）。GitHub Inbox 在這種情況下是無用的，我們的做法是每周會有一名同事，負責 GitHub 的新 issue，assign 給合適的 owner。我已經當過三次 Inbox Tracker，只能用可怕來形容。每天一睜眼就是一百多個 issue 要處理，一點都不想起床。

Endgame

我們在 milestone 的最後一周 endgame 會對新 feature 進行各種花樣的測試，對這個 milestone 關掉的所有 issue 進行驗證。全部完成後，每個成員書寫自己負責部分的 release note。最後 Endgame master 會到後台網站發布新的 Stable 版本。

印象深刻的事

當之無愧就是 VS Code uses 13% CPU when idle due to blinking cursor rendering . VS Code 是基於 Electron 的，而 Electron 則基於 Chromium。這樣的話，Chromium 的鍋有時候得我們來背。

VS Code 里的編輯區域並不是 textarea ，全都是 mock 的，這也是主流做法，Ace、CodeMirror、Atom 無不例外。理由也很簡單，要實現Tokenize、高亮、Partial Render、Line Wrap，自己控制渲染肯定是最方便的。為了儘可能模擬 textarea，我們模擬了游標。最開始這個游標的跳動，是通過 JavaScript 來控制游標的 opacity。後來社區給我們貢獻了一個 pull request，使用 CSS animation 來調整 opacity。實現上來說肯定是比 JavaScript 版本更優雅，同時也提供了四五種不同的游標跳動的選項。

但誰知道，Chromium 對於 CSS Animation 是有巨大的坑的。比如你寫的 animation 是每秒改變一次 opacity，但是 Chromium 會根據刷新率（比如 60hz）來檢測頁面上的 animation。雖然我不知道 Chromium 做了什麼，但是你可以看到每16ms，Chromium 就會吃掉一點你的 CPU 和 Battery

真的是一點辦法沒有。我們起初沒有發現這個問題，直到 broccoli 的作者 Jo Liss 給我們發了 issue，並且在 Twitter 上爆我們，瞬間就成了 Twitter 上大新聞。連 Miguel de Icaza 都點贊了，真的是。。。

當時我剛吃完晚飯，但是由於這個事情在我的防區，我只好開電腦 troubleshoot。最後發現是 Chromium 的 bug，開了兩年多了，我只好告訴 Jo Liss，這鍋我們不背，但是我們會修的。

結果之後好事者把事情捅到了 HackerNews，瞬間成了當天大新聞，還上了 TheRegister 小報。所有人都開始討論使用 Browser 技術做桌面應用是不是正確的選擇，撕的不亦樂乎。

你們撕的倒是開心了，我那幾天給各種老闆解釋什麼是跳動的游標，忙的跟狗一樣。好在後來 Chromium 的 PM lead Paul Irish 留言表示這是他們的 bug，算是完美收官了。

有沒有什麼奇葩的 issue 或者 PR？

  1. 你們猜大家看到中文寫的 issue 會找誰來翻譯？
  2. 有些朋友提交了 PR，根本不管你給的建議，自顧自的更新修改。這樣的 PR 根本不可能 merge，但是我們給的儘可能 polite 的建議，有些朋友真的把它們只當成建議。。。
  3. 再一次說到跳動的游標，這個始作俑者是社區的朋友，看起來也是非常 neat 的實現，誰知道就踩了 Chromium 的坑呢。。。

關於中文 issue 的問題，VS Code contribution guide 寫的是比較清楚的，請大家用英文提問。但是鑒於中文用戶量巨大，加之人總有英文不夠用的時候，VS Code 也會經常看到中文問題。我有這樣一些想法

  1. 寫中文我個人覺得問題不大，畢竟 GitHub 是我們幾乎唯一的反饋渠道，不能要求用戶必須會英文。
  2. 寫中文的確增加了我本人的工作量，所以能寫英文，還是盡量寫。
  3. 但如果你覺得需要嚴重的 Google Translate 的幫助，我建議還是寫中文，並且 cc 我。不然可能翻譯出來最後誰也看不明白，或者誤解。
  4. 我老闆問我，為啥中文 issue 幾乎把所有東西都寫在標題里，然後 issue 描述留空。我真的不知道該如何回答。如果用中文寫 issue，並 cc 我，請保證把reproduce steps 寫好，一步一步用中文寫清楚，這總沒難度吧？
  5. 如果第四步做不到，還要我解決問題，請考慮請我喝啤酒吧。

生活

大家都喜歡開源，但開源貢獻者大部分時候是在做義務貢獻。這麼來看在微軟搞 VS Code 就是一件愉快的事情，畢竟有人給你付工資讓你做 open source。而且再也不用上班搞一套代碼，回家之後私下自己在 GitHub 上面逛游，搞別的項目，上班和下班後可以在同一塊土地上耕耘。

當然這樣缺點也很明顯，就是生活和工作往往難以分開。工作是一周五天，一天八小時，但是 GiHub issue 從來都是 7*24。遇到棘手的問題的時候，很難放任不管，哪怕已經回了家。不過也正是因為項目的特殊性，我們組還是有比較好的 remote 和自由工作時間的文化的。

---

補充

1. 添加了對中文 issue 的看法。

這次籍著Electron 1.0發布的機會，說說我自己維護兩個大型開源項目的經歷吧，分別是node-webkit（也就是現在的NW.js）和Electron。

前者是幾年前自己單打獨鬥，在公司0資源投入的情況下從兩百多star一直做到好幾千star，具體數字已經忘掉了，只記得當時在C++項目排行里做到了前十，直到自己另起爐灶。而後者，則是披著GitHub的光環，有著公司熱心的投入，毫無障礙一路跑到了現在的三萬多star。

（使用Star History生成的star數統計圖）

一切從node-webkit開始

如果大家有接觸過前端或者桌面端的開發，那麼很可能有聽說過NW.js的大名，node-webkit就是其改名之前的稱呼。

但絕大部分人可能並不知道，node-webkit在最初發布的時候（2011年），並不是面向開發桌面應用程序，而是一個Node.js模塊，可以創建一個WebKit窗口。神奇的一點是，你可以在這個窗口的頁面里調用Node.js的模塊。

Node.js代碼：

var nwebkit = require("nwebkit")
nwebkit.init({"url" : "index.html"}, function () {
nwebkit.context.runScript("")
})

index.html代碼：

&&
&

& &
require("fs").readdir(".", function (err, files) {
var result = ""
files.forEach(function (filename) { result += filename + "&
" } )
document.getElementById("output").innerHTML = result
});
&
&&

大家可以在NW.js的webkitgtk分支里找到node-webkit的原始實現，甚至嘗試重新build一遍。不過這個模塊一直未能穩定下來，玩具的味道更多一些。

再後來，原作者rogerwang對其進行了改進，從使用WebKit改成了調用Chromium Embedded Framework（簡稱CEF），一個可以把Chromium嵌入應用程序的庫。這個代碼一直沒有正式公布，但大家可以在node-webkit的cef分支里找到。代碼的另一部分是針對Chromium的幾十行補丁，將Chromium的message loop替換為libuv，但是NW.js在開發過程中對代碼庫進行了很多次rebase操作，原始代碼已經找不回來了。

找個實習生來開發

node-webkit的原作者rogerwang在Intel開源技術中心工作，雖然Intel在大家心目中可能更多是個賣CPU的，其實在開源方面也非常熱心，甚至提供開源方面的實習工作。

在2012年的夏天，一則Intel的實習信息吸引了我的注意，上面說Intel需要一名熟悉Node.js的學生來進行node-webkit的開發。我投了簡歷，也很幸運地開始了node-webkit的開發。

Content Shell

我最初的工作是對node-webkit的cef分支進行改進，但是很快就發現很難繼續進行開發了。CEF提供了自己的一套API來包裝Chromium的內部API，而Node.js則是直接調用V8的API，如果想要把CEF和Node.js合併到同一個項目，困難重重。

於是我乾脆將node-webkit推倒重寫。新的代碼基於Content Shell，一個Chromium代碼庫內的最小化瀏覽器實現。

重寫後的結果非常不錯，我得到了一個可以調用Node.js模塊的瀏覽器實現。基於這套代碼我發布了node-webkit v0.2.1。

把node-webkit進化成桌面開發利器

至此node-webkit已經變成了一個獨立的瀏覽器，而不再是Node.js模塊。為什麼不把它變成一個使用JavaScript和HTML開發桌面應用的工具呢？後面幾個月我開始對這個想法進行嘗試。

首先我模仿遊戲框架L?VE framework為node-webkit實現了一個打包系統，可以把應用直接附加到exe上：

（node-webkit的打包系統，來自我自己的PPT）

這個打包系統一直沿用到NW.js，但是因為性能方面的種種原因，後來在開發Electron時我並沒有使用這套系統。

接著這是各種細節上的完善：比如利用package.json文件來描述應用；給窗口加工具欄；拓展DOM來提供API；取消瀏覽器的安全系統；等等。當然還有無休無止的bug修復。

其中最有挑戰性的一點是支持Node.js的native module，我對Chromium打上各種補丁來暴露V8和OpenSSL的API，給Node.js打補丁好解決OpenSSL和NSS之間的符號衝突，提供自定義的node.lib來支持Windows，最後還要提供適用於node-webkit的編譯工具。

完成這些工作以後我發布了node-webkit v0.2.5。

提供構建GUI的API

這時我的絕大部分工作都在圍著瀏覽器轉，而由於瀏覽器自身的局限性很多功能我都沒法提供。比方說瀏覽器里就沒法創建系統原生的菜單。（當然今天已經有了HTML5 Menu標籤，而當時是2012年。）

於是我想到增加一個新的內置模塊，用來提供對窗口、菜單等系統API的綁定，也就是：

require("nw.gui")

如果你有使用過NW.js的話，你應該很熟悉這一套API。

經過幾個月的完善後，我發布了node-webkit v0.3.6，這也是由我維護的最後一個版本。

node-webkit的推廣

雖然node-webkit屬於Intel，但其更多屬於rogerwang的個人項目，那時候這個項目在GitHub上也還掛在rogerwang的賬戶下。所以當時除了我自己一個人，沒有其他任何來自Intel的資源投入。

而像node-webkit這樣的框架類項目，只有擁有用戶，才會有生存下去的意義，所以在開發node-webkit的半年時間裡，我也一直有在積極推廣。

首先是到處發帖子宣傳node-webkit的好處，一大陣地是Node.js的郵件列表。每次有新版本我就會過去發布公告，回答問題，與人撕逼。其次則是編寫範例應用，讓新手快速入門，讓其他人相信node-webkit的能力。最後則是去技術會議宣傳，讓大家知道node-webkit這個東西。

當然最重要的還是認真回答Issues里的問題，努力修復bug增加功能。

我的努力最後也得到了非常好的回報，在我結束node-webkit開發的時候，項目在GitHub上獲得了數千個star，排到了C++項目排行的前十。

第一個用戶

另外值得一提的是node-webkit的第一個用戶，Light Table editor。這個編輯器的作者ibdknox很大膽地使用了node-webkit來進行開發，當時為node-webkit迎來了非常多的關注，也給大家吃了一枚定心丸，為項目推廣助力巨大。

幾年後Light Table又從node-webkit遷移到了Electron，當時好似好友重逢，感觸良多。

工作的轉移

在我為node-webkit工作半年之後，2012年底，這個項目開始吸引越來越多的注意力，也開始引起Intel一定程度的注意。rogerwang得到了機會放下其他的工作，開始全職維護node-webkit。

（GitHub的代碼貢獻表）

大家如果有在比較大的公司工作過，之前可能會奇怪，為什麼一個實習生能如此隨意地修改代碼，發布新版本。其實正是因為這個項目當時在Intel內部無人關注，無人管理，我才得以隨心所欲地嘗試各種想法。

但之後正當node-webkit冉冉升起之時，我卻徹底失去了node-webkit的自治權，開始收到命令去完成指定的開發工作，被禁止隨意去增加功能，也不允許去隨意修復bug，而發布新版本、和客戶交流的工作也被轉移給更高級別的工程師手上。正如一個大公司里的螺絲釘。

可能這種開發方式才是大公司的常態，我也不想抱怨任何人，但是抱歉，我只是一點也忍不了。

為GitHub而戰

在我進行node-webkit開發的同時，GitHub正在秘密開發Atom編輯器。我了解到GitHub正在尋求一種使用HTMl和Node.js來開發桌面應用的方式，於是聯繫到Github
的工程師nathansobo，表達了為GitHub工作的意願。

所幸node-webkit已經為我自己博得了足夠的名氣，在一面未見的情況下，我們敲定了協議，我需要將Atom遷移到node-webkit之上，並且提供支持工作。

於是2012年底，我結束了在Intel的實習，開始為GitHub作為contractor工作。

一個更好的桌面應用框架

在我加入Atom的開發時，項目還基於CEF。我們嘗試了將Atom遷移到node-webkit上面，但是最終效果並不是很好，node-webkit當時並不穩定，而且API有太多的坑。

於是我開始重新考慮node-webkit的API設計，發現如果想要支撐大型應用，我不得不做出很多結構性的改變，而這些改變與其修改node-webkit，不如重寫更加實際。在和GitHub討論之後，我開始編寫一個新的桌面應用框架，當時的名稱叫做atom-shell。

有興趣的同學可以去了解一下我們究竟做了哪些改變。

左右互搏

後來，經過長時間的開發，atom-shell最終開放了源代碼，而與此同時node-webkit 已經吸引了非常多的注意力和用戶，我開始了和自己的競爭。

再之後node-webkit改名為NW.js，而atom-shell則改名為Electron。

（Electron 1.0）

維護開源項目的生活

說完了從node-webkit到Electron進化的歷程，最後說說維護開源項目的體驗吧。

和普通項目不同，開源項目幾乎所有的用戶都來自公司外部，取決於項目的受歡迎程度，每天都會受到相當大數量的郵件。就我自己而言，來自GitHub的通知郵件每天數量在50封左右，需要花1到3小時左右一一消化回復。很多issue要去仔細重現，一些話題也需要大量的討論，很費神。甚至會有troll過來破壞所有人的心情。

其中最讓人無奈的一個troll，最愛跑到issue下面留言，指摘Electron抄襲NW.js的代碼，剽竊NW.js的理念，還到處勸人轉用NW.js。簡直了。

維護項目的另一項工作，是審核pull request，和維護node-webkit時不同，Electron的用戶群要大很多，所以每天都會收到pull request，其中不乏高質量的代碼。但多數時候代碼都不能直接合併，要麼設計不合理，要麼代碼不合規範，更多地則是引入新bug。所以每個pull request都需要細心查看，還少不了和貢獻者大量的討論。

於是，做完這些工作以後，留給寫代碼的時候反而少了很多，也是沒有辦法。但對於一個開源項目而言，這些瑣碎的工作其實非常重要，只要讓人感覺你的項目在被精心維護，才能不斷吸引更多用戶。一個維護不善的項目，哪怕初期因為種種原因吸引了很多用戶，一旦更好的替代品出現，用戶馬上會飛速流失。

生活上，因為是全職做開源，影響反而非常小。GitHub的遠程工作氛圍非常濃厚，我的大部分工作時間也是在家裡而不是辦公室里，所以多數時候是想寫代碼了便開始工作，不在狀態就把工作放在一邊去做做喜歡的事，以此用有限的時間維持非常高的工作效率。

但開源會給自己帶來另一個問題，責任感。一個沒人用的項目，棄坑不過是一轉念的事情，但是當越來越多人開始用你的項目，甚至有創業公司把未來壓在你的項目上，責任感會越來越重，你唯一的選擇就是將項目繼續維護下去，無法棄坑，直到更好的技術出現。

不知道我未來還會維護Electron多久，不過就過去幾年來看，還挺開心的，應該還會繼續做下去吧。

更新

node-webkit在自己的郵件列表置頂了一個聲明，聲稱我當時不過是個實習生，所有的工作都是在指導下完成，而且無關緊要。本來我沒打算理會，但是很多人已經產生了誤解，而且node-webkit的開發者一直在據此對我進行騷擾和攻擊，實在無法放在一邊，我又寫了一份聲明，有興趣的就去看看吧 Statement on the statement on the history of node-webkit project。

我來說一個面向最終用戶的軟體項目 Koreader (koreader/koreader · GitHub)。Koreader是跨平台的電子書閱讀軟體，支持多種文檔格式，可以運行在Kindle、Kobo、PocketBook等電子書，以及Android和Ubuntu Touch設備上。目前Koreader在GitHub上有1400+ star，PR+issues超過1600個，有將近40名開發者為項目貢獻了代碼，在Transifex上有超過15種語言的本地化翻譯。

Koreader最有特色的功能是PDF頁面文字迴流。和其他支持文字迴流的PDF閱讀軟體不同，Koreader把PDF頁面當成圖像，按照行間距和詞間距把頁面分割成以詞為單位的圖像塊，再將這些圖像塊適應屏幕重新排版。這種基於圖像的PDF頁面重排不僅支持掃描的PDF頁面，還可以讓大部分數學公式的結構在頁面重排後保持完整，更多重排樣例參考如何解決六寸的 Kindle 看掃描版 PDF 的問題？ - 黃鑫的回答。

Koreader是一個完全由社區驅動的軟體項目，採用去中心化的管理方式。用戶和開發者把bug和特性需求發到GitHub的issues列表裡，由開發者自願認領。開發者把實現或者修復的補丁提交Pull Request，由另一名或多名開發者評議然後合併。目前Koreader項目有11名開發者有合併PR的許可權。這種「同行評議」的PR（peer-reviewed pull request）機制使項目不需要一個中心維護者仍然可以快速迭代。

我們通過持續集成工具Travis CI(https://travis-ci.org/koreader/koreader) 對主分支上的每個Pull Request運行單元測試和代碼覆蓋測試，一定程度上保證提交的代碼不會破壞已有代碼的功能。我在伺服器上部署了一個每日編譯（nightly build）的腳本程序，這個腳本機器人在每天的北京時間6點和18點會從GitHub拉取主分支上最新的代碼，從Transifex上拉取最新的本地化翻譯，所有測試通過之後會為Koreader支持的每個平台編譯最新版本的軟體包，然後將軟體包自動發布到Koreader的OTA（over-the-air）升級伺服器。在所有支持OTA升級的Koreader平台上，用戶就可以一鍵下載增量更新安裝最新的版本。所以，經常會有用戶上午提交了bug報告，第二天就可以通過OTA得到問題的修復。

除了GitHub上的開發者社區之外，Koreader正在形成一個論壇形式的用戶社區。在電子書閱讀論壇比如國內的 Hi-PDA E-INK板塊 和國外的 MobileRead 上都聚集了一大批Koreader用戶。最讓我感動的是，一些Koreader熱心用戶會不厭其煩地為新用戶解答使用過程中遇到的問題，會從普通用戶的角度為新用戶寫各種教程和指引。前幾天MobileRead上的Koreader粉絲又在向管理員建議為Koreader開設專門的板塊，貌似新板塊正在建設中。

善用這些自動化工具，讓機器儘可能代替人力來維護開源項目然後有更多的時間去實現設想的功能，我想這就是作為開源軟體開發者和維護者極好的體驗了。

謝邀。現在全職維護 Vue.js: vuejs/vue · GitHub 在某些人眼裡可能不算大型吧，不過從用戶量來說，全球幾十萬還是有的。

因為用的人/公司足夠多，有足夠的社區捐贈和商業贊助，所以現在是獨立開源開發者。可以說這個項目已經完全改變了我的生活軌跡。一開始也沒想到會能做到今天這個地步。和在大公司對比，沒有那麼安逸，壓力要大一些，但是非常自由，可以做自己真正喜歡的事情感覺很好。

印象深刻的事情

這個項目一開始純粹是作為練手的輪子，因為當時想要研究 Angular 數據綁定的實現。研究的時候覺得臟檢查實在是個不優雅的實現，於是就琢磨如果只支持 ES5 能不能用 getter/setter 實現無縫的依賴追蹤。如果算上那時候的第一個 commit，距今已經兩年零三個月：initial setup · yyx990803/vue@83fac01 · GitHub 正式對外發布是 2014 年 2 月的事情了。當時也算是抱著『搞個大新聞』的念想小小策划了一下，同時在 HackerNews、Reddit、EchoJS 等地方發了帖子，還給 DailyJS、JavaScript Weekly 等媒體發了自薦。發布後幸運地在 HN 首頁呆了一段時間，第一周後拿到了 615 個 star。我對第一周的一些數據做了些統計，還寫了篇博客：First Week of Launching Vue.js

當時 Vue.js 其實非常的不成熟，但有一個公司膽子很大地把這個個人項目用在了生產環境里：Optimizely。這家公司國內知道的人可能不多，但他們 B 輪融了 a16z 的 55m，其實是一家准獨角獸公司。他們當時的新前端 lead 上任做的第一件事就是把他們基於 jQuery + Knockout 的舊前端用 Vue.js 重寫了，還邀請我去過他們辦公室聊天。現在回頭看來，當時的 Vue.js 問題很多，但多虧了這家公司，讓我第一次覺得『卧槽，原來我寫的東西還真有別人用！』

另一類有趣的用戶則是一群法國的交互開發者。這些人大多是在廣告創意類的公司工作，主要的任務就是把網站做得要多酷炫有多酷炫，很多都是從 Flash 背景過來的。對於他們來說 Angular 完全是 overkill，但 Vue.js 卻正好。加上對於動畫的良好支持也算是 Vue.js 的賣點之一，所以他們用 Vue 還做了不少得獎的交互類網站，比如：Louis Ansa - Interactive Designer （國內可能載入很慢）

再往後不知為什麼 Vue.js 在日本也有不少人開始用了，東京一家叫 Cuusoo 的公司有個工程師把他公司的前端用 Vue.js 改寫了，翻譯了日文文檔，居然還組織了 Vue.js meetup... 然後他現在升任他公司 CTO 了 orz... 總之聽說 Line 和 Nintendo 也有一些項目用了 Vue.js。

今年 5 月份的時候，Laravel 的作者發了條推，大意是說『我嘗試學了下 React，覺得好難用，決定改學 Vue.js 了』。然後 Laracast（一個 laravel 教學視頻網站）的創始人做了一系列 Vue.js 教程，於是 Vue.js 突然就在 Laravel 社區火了，貌似現在最活躍的用戶都是 laravel 社區的人...

開發中的體驗

現在想來，才明白為何一個項目所謂的『成熟』需要時間。今天回頭看兩年前的代碼，那就是一坨渣渣啊。這期間經歷了很多摸索著做了個能用的實現，然後去研究其他庫的源碼，於是恍然大悟為什麼他們要這麼設計，再把自己的設計改寫的過程... 為了這個幾乎所有開源的前端庫實現我都研究過了，很多次在做大改動的時候心裡都會覺得很慌：『之前那麼蠢的設計居然還有人用！』0.10 到 0.11 的升級是一次完全的重寫，實在是因為 0.10 的設計太幼稚，維護不下去了...

為了能『可持續發展』，不得不強迫自己形成代碼潔癖。每一個函數，每一個 hack，每一個 edge case 都要寫上注釋，怕的就是哪一天自己都看不懂自己當時在幹嘛。為了不在修 bug 的時候導致更多的 bug，只能強迫症一般地保證每一個 commit 之前都是 100% 的測試覆蓋率。總的來說，能自動化的東西都基本自動化了，比如發布一個新版本也是一個命令自動跑完所有測試，按照 semver 升級版本，然後 push git tag + npm publish。另外還在持續集成服務上對每一個 PR 自動檢查代碼格式 + 跑單元測試...

另一個很有意思的轉變就是從一開始完全想怎麼設計就怎麼設計，到今天需要考慮各種用例、穩定性、瀏覽器兼容、向後版本兼容、社區意見等等，整體的設計過程也變得越來越社區化了。以前想做個新功能直接上就是了，現在基本上都會先開個帖子徵求下社區意見，大家一起討論著做。比如這次 0.12 ~ 1.0 的升級，大部分 breaking change 都專門開了 issue 徵求社區意見，新的綁定語法更是經歷了漫長的幾百條評論的討論...

Issue 和 PR

現在基本上每天起床第一件事就是看郵箱裡面有沒有新 issue。我用 Inbox 把 Vue 的 issue 專門分了個類別，就當是 todo list，修掉了就勾掉。有時候一口氣修了幾個 bug 啪啪啪勾掉一堆的時候感覺還是很酸爽的... 當然更爽的是有時候一覺起來一個 issue 也沒有 -.-

說到 issue 的類型，實在是一把辛酸淚。剛開始的時候有人開個 issue 就覺得受寵若驚了，到後來時間緊了之後，就越來越體會到對開 issue 的方式對維護者體驗的影響。舉例來說，有些人開 issue 永遠只有一句話，甚至有些直接就是標題："xxx doesn"t work"，然後無內容。早期碰到這種的還會記在心上，現在遇到這樣的就直接掛個 『請給重現』的 tag，如果幾天以後還是沒重現就直接關掉。另一種極端就是一些很認真的同學，一個 issue 分幾個小標題，『問題描述』、『重現步驟』、『可能的原因』，有些甚至把應該改哪裡都幫我指出來了，就差直接開個 PR 了。每次遇到這樣的 issue 我就特別想擁抱一下開 issue 的人，希望大家都向這樣的同學學習！

印象最深的一個 issue：

最奇葩的 PR：

mini change: removed unnecessary spaces by Jinjiang · Pull Request #1165 · yyx990803/vue · GitHub

^ @趙錦江(勾三股四) 為了混 contribution 已喪心病狂！

對工作和生活的影響


首先，維護這個項目對於個人的技術成長顯然是有著巨大的好處的。為了保持項目的競爭力，我需要時刻關注前端最前沿的東西，研究別人的實現；為了保持項目的可維護性，我需要進行各種工程化的實踐...

有一個有一定知名度的項目自然在很多事情上也會比較方便，比如當時去 Meteor 面試就是做了個 Vue.js 的分享然後聊了聊天就給 offer 了，並沒有叫我翻轉二叉樹什麼的...

生活上，對項目過於投入有一定的負面影響。因為 Vue.js 畢竟是個個人項目，所以經常需要佔用工作外的時間，代碼寫太晚被老婆訓斥也不是一次兩次了... 還好我在寫 Vue.js 之前就已經找到了老婆，各位單身的碼農挖坑前還需謹慎！

我不清楚 be5invis/Iosevka（3796，?102）算不算大型……雖然上個月星星漲了 2000 多。

感受就是——我為了這玩意寫了一整條工具鏈：otfcc，ideohint（給 Inziu 用的，這應該是全球第一個 Well-hint 的半形等寬中文字體），各種 otfcc 上位腳本，Patrisika，PatEL……

修那種「我為啥 build 不了」的 bug 是最痛苦的，因為 Iosevka 的 building 之前大量用了 makefile 裡面的黑魔法，現在搞到我想用 node 寫個東西代替 make……呃 gulp 似乎不太適合前端之外的場合。

另外想支持的請點進項目主頁然後點標題里的贊助，謝謝。

說一個比較目前小眾的但是intelligence 很高的項目吧 bloomberg/bucklescript An optimizing compiler from OCaml to JS

首現想說的是 按github 星星數評價大型開源項目 真的很不公平, 一些項目門檻低, 能參與的人數多，或者是時下流行的概念股， 自然點贊的人數多了，舉兩個例子 coq/coq, ghc/ghc 可以說都是幾十年的智慧積累了 充滿了人類智慧的榮耀 關注度者寥寥。

之前有問題 中國為什麼不做編譯器和編程語言？ - 知乎 BuckleScript 徹底是中國人架構並主導（而不僅僅是中國人參與）的編譯器, 並且也有用作於商業用途, 像Facebook, Google，還有些許小的公司 都有使用，但是國內論壇很少有提及 或許也有葉公好龍之嫌吧

言歸正傳，回答題主的問題

&> 先介紹你的項目，用來幹什麼的？

BuckleScript 是一個優化編譯器 主要用來支持在JavaScript 平台的大規模編程, 具體解決了一下痛點:
1. 正確的類型系統 不僅僅只是TS那樣用來做代碼提示，其類型系統理論證明正確，確保編譯器可以用來進行ahead of time optimizations
2. 性能優化，其類型信息可以用於靜態優化

3. 良好的互操作性，和TypeScript一樣，沒有做name mangling,單模塊編譯到單模塊
更多優點可以參考: BuckleScript User Manual

&> 在開發和維護的過程中遇到過哪些值得一提的事？

特別感謝我現在的僱主，BuckleScript 一兩年前只是我的一個業餘項目 後來老闆覺得很驚艷 就讓我全職做自己喜歡的事情了

&> 有沒有什麼奇葩的 issue 或者 PR？

有的時候PR太大了 review會頭疼的厲害，所以即使想merge 也還是會說no, 比如這個 Native compilation for bsb (PR 3/3) by bsansouci · Pull Request #1338 · bloomberg/bucklescript 知道這樣會很打擊貢獻者的積極性 但是也是沒有辦法的事情

&> 對你的生活或者工作有沒有造成影響（好的，壞的）？

好的事情是可以做自己喜歡做的事情 而且在公司里也頗受尊敬。壞的是感覺太emotionally attached, 最近正打算做點其它方面的事情 算是diversify下自己的興趣和生活吧

其實大多開源項目是這樣維護的


Codenomicon 和谷歌安全部門的研究人員在開源軟體 OpenSSL 中發現了一個存在兩年的安全漏洞，可能導致用戶的通訊信息暴露給監聽者。
全世界有無數公司依賴於開源加密庫 。

OpenSSL，其中不乏思科和雅虎這樣的科技巨頭。漏洞曝光後，OpenSSL 軟體基金會董事長兼聯合創始人Steve Marquess 曾在郵件列表上透露， OpenSSL 項目通常一年只收到 2000 美元捐款。這個數目連一名美國普通程序員的薪水都付不起。

「心臟滴血」漏洞曝光後，很多人都驚詫，為啥這麼火的開源項目，背後團隊只有少數幾個人，維護資金這麼少。後來 CommitStrip 博主根據這一事件畫了漫畫。

（插播：其實除了 OpenSSL 遭遇困境之外，OpenBSD 在 2014 年年初也遇到過財務危機，沒錢付伺服器的電費了。請看去年的報道：《若再無資助，OpenBSD 項目恐將關閉》。當然了，求助信公布後，OpenBSD 很快收到了 10 萬美元的資助。）

也正是因為「心臟滴血」漏洞，普通人才更多地了解到開源項目的背後。好在一些大公司也開始為開源社區資助。比如 2015 年 10 月，Mozilla 宣布向開源社區捐贈 100 萬美元。

Mozilla 是開源社區的重要成員，而它本身也大量使用開源項目。為了回報社區，Mozilla宣布了開源支持計劃，向其使用的關鍵開源項目捐款100萬美元。今天的互聯網重度依賴於眾多的開源項目，而許多開源項目的開發者卻缺少了最基本的資源，去年的OpenSSL 高危漏洞曝光之後，主要互聯網企業正努力改變這樣狀況。

Mozilla公布了它是使用的開源項目清單，其中包括：Apache Server、Clang/LLVM、Debian 、Django、Docker、GCC、Git、Linux內核、MySQL、Node.js、OpenSSH、OpenSSL，等等。 （ Via：Solidot）

  • 先介紹你的項目，用來幹什麼的？

利益相關：ECharts兼職小運營、小產品
ECharts，一個用JavaScript做的圖表庫，不過我們一般宣傳時會說得更加高大上一些，叫做數據可視化解決方案或者數據可視化平台。底層基於我們自己開發的一個繪圖庫ZRender。
目前Github Star數 11877，感謝各位關注者。

Github: GitHub - ecomfe/echarts: A powerful charting and visualization library for browser
ECharts: ECharts

  • 在開發和維護的過程中遇到過哪些值得一提的事？

1. 當然先誇誇我們的工程師

@Kener-林峰 林老闆作為ECharts之父，作為和我睡過一個床的人，對我的影響非常大。從一個只是滿足某個mis系統的報表需求，到做成如今的一個如此有影響力的產品，他永遠旺盛的精力、每次聊到產品時炯炯有神的雙眼，讓我頭一次那麼近距離、深刻地體會到，當一個人熱愛他的事業時，他會創造什麼樣的奇蹟。所以他出去創業，我相信他一定會成功。

現在維護ECharts的幾位同學，也讓我感受到這一點，沒有公司KPI，全憑著自己對於這個產品的熱忱，不斷地創造出超出我們預期的產出。介於我還一直在催他們趕緊發版本，趕緊錄教程，趕緊寫書，趕緊寫文檔，我就少誇一點，免得他們太驕傲。

2. 用戶帶來的感動

經常會在新聞客戶端中看見一些「大數據時代十大數據可視化產品」，「數據新聞必備利器」之類的文章，一般都沒有ECharts（技術部門沒錢買軟文），但這種文章的評論中，基本上都會出現「居然沒有ECharts」，「沒有ECharts，差評」之類讓我淚奔的評論。

偶爾有提到ECharts的文章（比如最近知乎上關於百度有哪些有良心的產品），也會有用戶在下面力挺ECharts，雖然挺的方式讓我略顯尷尬，比如「ECharts是百度唯一有良心的產品」，我就會默默看看手裡負責的其他項目。但還是非常感動。

所以為了這些讓我們感動的用戶，我們會想辦法持續發版本，寫好文檔，弄好教程

3. 海外發布帶來的意外

14年年底我們發布了英文版，自然，我們在海外沒有任何宣傳渠道，除了弄了張海報發在中國微博上，就讓他這樣默默地上了而已，但令我們意外的是，Github數在發布後猛增，短短一個月時間就幾乎翻倍。

http://echarts.baidu.com/index-en.html (二維碼自動識別)

4. 少許的糾結和不爽
說實話，ECharts的文檔我們自己都覺得挺爛的，我們也在儘力解決，但這不是一朝一夕能改變的事情，所以，經常也會受到個別用戶郵件，或者評論直接開罵「垃圾」，「文檔不是寫給人看的」，「寫文檔的人是吃著翔寫的」之類的。
雖然知道自己做得不好，但是看見這些話語，心裡多多少少還是有疙瘩。
但幸運的是，更多的用戶給我們的是支持與肯定。

  • 對你的生活或者工作有沒有造成影響（好的，壞的）？

不說我個人，說說我覺得對團隊的好處
好的：
人才吸引：相信沒有ECharts， @羨轍 不會來，就這麼簡單粗暴，&<廣告&>當然，我們在人才吸引上還做了很多工作，比如百度前端技術學院 http://ife.baidu.com。&

行業接觸：ECharts的用戶除了技術人員以外，還有大量的媒體從業者、數據分析師、醫療、金融等不同行業的相關人士，因此，我們有了大量接觸不同行業的機會，包括林老闆也被天安門公安局請去過分享。

綜合能力：ECharts的幾位同學早已超出全棧工程師的職責與角色，戰略、產品、交互、視覺、後端、前端、資料庫、數據分析、運營、市場、客服……屬於全乾工程師，在ECharts項目上的產品、運營、市場方面的實驗也給我們在其他項目中的工作積累一些經驗，作為工程師的我們，也體會到了其他角色工作的情景與不易。

壞的：目前還沒有比較明顯的壞處，

也說說我的體驗

  • 先介紹你的項目，用來幹什麼的？
    • 我做了一個MySQL資料庫中間件：kingshard（GitHub - flike/kingshard: A high-performance MySQL proxy )。kingshard是一個由Go開發高性能MySQL Proxy項目，kingshard在滿足基本的讀寫分離的功能上，致力於簡化MySQL分庫分表操作；能夠讓DBA通過kingshard輕鬆平滑地實現MySQL資料庫擴容。 kingshard的性能是直連MySQL性能的80%以上。
  • 在開發和維護的過程中遇到過哪些值得一提的事？
    • 去年的整個夏天的周末都投入進去，開源一周github上的star就超過300，非常驚訝。
  • 有沒有什麼奇葩的 issue 或者 PR？
    • 大部分人都非常客氣友好吧。
  • 對你的生活或者工作有沒有造成影響（好的，壞的）？
    • 犧牲了很多業餘時間，但通過開源認識了很多朋友。當然，找工作也很easy。
公司的商業代碼基本全開源... Qt Project

前面 zcbenz 的回答中關於 node-webkit 項目的歷史有很多不實信息。node-webkit的作者 rogerwang 最近在項目郵件列表裡面對此發表了一篇聲明，因為是牆外鏈接，所以我把內容原樣貼在這裡：

https://groups.google.com/d/msg/nwjs-general/LIrC7zHtQdo/6Gd5MXVsCAAJ

I wouldn"t like to spend time on this, but as the previous co-maintainer of node-webkit project, keeps spreading misinformation about his internship work in the node-webkit project on his blog post[1], http://zhihu.com[2] and conferences[3][4], I feel obligated to clarify the confusion and misleading message.

The node-webkit project started under an innovation program in 2011. As node-webkit was becoming popular, we decided to hire an intern student to work with us. I interviewed and recruited Zhao Cheng in 2012. We managed Cheng, just as what we would always do to an intern with good potential (with Node.js experience, but barely on Chromium/WebKit), providing coaching, reviewing code, etc. During his 6 months internship, I mentored him on daily technical things (including git tips, bug fixing, making releases, architecture adjustment, etc) and interaction with open source community. As he was pursuing opportunities out of China, we encouraged him to do work which can be seen by the community, including announcing release notes and communicating with users in GitHub issues. These work would help on his goal. Later Atom project lead from GitHub contacted us to learn how we integrated Node.js and Chromium. Then Cheng ceased his internship, and left the team, although we offered him a permanent position. Later on we got to know he joined GitHub for the Atom Shell project. Following the resignation process, his work was transferred to me, including communication with users in the issues he owned, and announcing the last release before he left. All of those went smoothly.

So we feel shocked and sad when we saw that, node-webkit was described as a "solo developer" effort, his daily work was interfered brutally, he "couldn"t stand it a bit" and left the project after he lost his "autonomy" on the project.

On the contributions to the node-webkit project: The Node integration with Chromium was done before Cheng joined the project. He went on to fill the missing part of packaging and native GUI library. As Kevin wrote in his comment, the code for node-webkit project spans across multiple repositories: the Chromium repo, the Node repo, the v8 repo, the WebKit repo, the breakpad repo and the node-webkit repo. The last one hosts the packaging code, native GUI library and serves as the home page. It is the only one known by most people, and it is the only one referred in Cheng"s post to represent his contributions, which is misleading. Furthermore, the Intel copyright notices were removed and were replaced by GitHub copyright notice in Electron when pieces of code was copied and derivative work was made from some code of node-webkit (see Kevin"s post[5] for the links to source). We appreciated Cheng"s contributions, but it is really a self-deception that he tried to position himself as a game changer of node-webkit during his internship.

In April 2016, it was asked about the origin of the Electron project and its relationship with the node-webkit project, Cheng answered that Electron "was rewritten from scratch", and it"s not even "inspired by NW.js". Kevin (co-maintainer of NW.js project today) replied[5] to correct him with verifiable information. Later on, Cheng wrote the post on his blog and start spreading it on zhihu.com. And it appears that he talks about the same at conferences from his slides.

That said, we still respect the Electron project, no matter whether it is a derivative work of node-webkit or not. I hope we could close this here with this final statement, and get back to the tons of work ahead.

Roger Wang
node-webkit creator and maintainer

[1] From node-webkit to Electron 1.0

[2] 維護一個大型開源項目是怎樣的體驗？ - zcbenz 的回答 - 知乎

[3] https://twitter.com/hkdennis2k/status/801958264938184704

[4] https://twitter.com/serrynaimo/status/801960379664330752

[5] Question: Electron Origins · Issue #5172 · electron/electron

(更新：zcbenz在最近的項目里採用了相同的做法，移除了其他人的copyright notice:

LGPL licensed code in yue · Issue #4 · yue/help )

受邀，第一次在知乎上回答這麼長的內容。


先介紹下項目：ThinkJS，一個藉助 Babel 編譯，可以直接用 ES2015+ 特性開發 Node.js 項目的框架，為企業級 Node.js 項目開發提供巨大的便利。目前 GitHub 上 star 數為 1620，issue + pr 有 300 多，有 1700+ 單元測試用例和非常完善的中英文文檔，已經有不少公司在使用。


項目事迹


提到 ThinkJS，可能有些人第一想到是不是和國內的 PHP 框架 ThinkPHP 有一些關係，你沒猜錯，剛開始 ThinkJS 就是借鑒 ThinkPHP 來開發的。這個想法是在 2013 年下半年的時候開始有的，那個時候 Node.js 框架主要還是 Express，但用 Callback 處理非同步的方式非常讓人頭疼，而有另一種比較好的方案就是用 Promise，所以慢慢就有了借鑒 ThinkPHP，使用 Promise 機制開發一個 Node.js 框架的想法。


借鑒 ThinkPHP 框架有幾個原因：

1：ThinkPHP 代碼比較簡單，借鑒成本較低。

2：ThinkPHP 在國內有一定的用戶量，如果這部分用戶想用 Node.js 開發項目肯定是希望有個和 ThinkPHP 相似的框架。

3：最重要的一點是，ThinkPHP 在國內持續維護了 7 年多的時間，這在國內是一個非常不容易的事情。我也是希望藉助這個激勵自己要把 ThinkJS 持續維護下去。


我們在 2014.09.22 發布了 ThinkJS 1.0 版本，在公司內部有較多的項目在使用，外部慢慢的也有一些人在使用。


隨著越來越複雜的項目使用 ThinkJS，Promise 也暴露了一些弊端，如：不能很好的跳過一些中間環節和數據傳遞。隨著 ES2015 規範的發布和 React 的火爆，雖然運行環境還不支持這些新的特性，但這裡藉助 Babel 編譯可以提前使用這些新的特性。而對於非同步處理方式有了更好的方式，Generator Function 或者 Async Function。


所以我們在 2015.03 完成了全新版本的設計，定位為可以在項目里直接使用 Es2015+ 特性開發，框架會進行自動編譯和自動更新，大大方便 Node.js 項目的開發，同時優化 1.0 里不合理的架構和設計，脫離對 ThinkPHP 的依賴。於是我們在 2015.10.30 發布了 2.0 版本，這天也是 Babel 發布 6.0 的日子。


隨著 2.0 的發布，ThinkJS 成為世界上第一個全面支持使用 ES2015+ 特性開發 Node.js 項目的框架，後續的版本又支持了 TypeScript，斷點調試等功能。

和其他框架的對比


很多人一看到 ThinkJS，就覺得是個大而全的框架，估計就直接放棄了，他們更喜歡 Koa 這種小而美的框架。


其實 ThinkJS 並不是大而全，只是封裝了一些常用的功能，為企業級開發而定製的。提供的 Middleware 和 Adapter 機制更適合企業級項目開發。


Koa 雖然本身很小，但實際開發項目時，需要自己尋找各種中間件，這些中間件質量層次不齊，有些功能模塊介面不統一，這給團隊開發帶來很大的麻煩。同時團隊還要基於 Koa 做自己做項目規範，經過時間才能積累最佳實踐。而 ThinkJS 將這些直接提供了，省去了很多時間。

一些好玩的事情


自從有了英文文檔後，慢慢的有些老外也在用 ThinkJS。發現這些老外真是積極，他們會主動給一些 awesome-* 項目發 pr，讓其添加 ThinkJS，也會主動修改文檔中的一些拼寫錯誤，然後發 pr。


更好玩的是有個老外 [EunseokEom](https://github.com/eseom) 覺得 ThinkJS 的官網不太好看，所以他自己設計了個，並且給實現了，renewal draft #1 by eseom · Pull Request #60 · 75team/www.thinkjs.org · GitHub，雖然這個網站我們覺得也不是很好看，最後沒有合併，但老外這種貢獻的精神真的非常贊。不過這也讓我們有了優化官網的想法。

尤雨溪同學介紹了一則在軟體開發領域比較有代表性的範例；那麼我就說說一個大家不太熟悉並可能稍感神秘的領域中的大型開源項目：在天體物理領域中（目前也在逐漸擴展到多學科）的數據分析和可視化軟體:The yt Project.

這個項目（包括使用文檔）的源碼都放在BitBucket上（yt on Bitbucket），目前有約18,000的commit，2000的PR和1000+的issue。由於專業特點，我們個人有些代碼出於各種原因是不能公開的，因此提供無限免費私有倉庫的Bitbucket是一個很方便的選擇。

目前yt在天體物理領域取得了較大的影響力（很可惜，這一點在國內尚不明顯；因此我也計劃在國內通過給talk的方式做一些初步的推廣工作）；yt支持天體物理中多種廣泛應用的（數值模擬/觀測）數據格式，大量的論文是用yt進行數據處理和可視化的，其中包括一期《自然》雜誌的封面。一些可視化的例子可以在The yt Project: Gallery、我個人主頁上的Visualizations上找到（部分在YouTube上視頻可能被牆）。

與軟體領域的開源項目相比，yt Project有其特殊性：

  1. 相當一部分的模塊要求維護者有專業的物理知識；
  2. 使用者為編程能力相對（與程序員相比）薄弱的物理學從業者，因此在使用文檔和擁護支持方面有較多的工作。

維護這個較為大型的開源軟體，一個人的力量是遠遠不夠的；約20人的團隊（The yt Project: Community）以及從始至今共108位contributor都為這個開源軟體做出了貢獻，其中包括像我這樣的博士生、博士後和教授。項目的維護主要有以下幾個方面：

代碼設計與debug


這個是最主要、也是最基本的工作。每隔一段時間，當一個階段的工作比較成熟之後，我們就會推出一個新的版本號。我這周剛參加了這個項目的mini-sprint，大家針對全新設計的立體渲染模塊進行了最後的代碼衝刺，並即將推出3.3版本。

代碼測試

測試包括通過運行一系列測試腳本，檢測代碼各個模塊能否正常運行，以及改動前後的版本的輸出（數據、圖像等）是否一致等等；後者在科研中是很重要的，否則今天一個結果、明天另一個結果，論文就沒法寫了。這個本應是一個繁重的工作，然而團隊里的一位成員為這個項目寫了一個測試機器人；每提交/改動一個PR，機器人就會自動針對變化運行測試、重新編譯使用文檔，並在PR頁面留言：

同時在團隊的Slack上的即時聊天組裡也會發信息：

話說我去年剛開始成為這個項目的成員時，還驚訝於這個人為什麼每次都如此勤快，後來才覺得它應該是機器人…

用戶支持

如前所述，由於這個項目的特殊性，我們在用戶支持上做了較為完善的工作。我們撰寫並維護了非常詳盡的使用文檔yt Docs；通過yt的使用者郵件列表，每天都能收到幾封郵件並都能得到及時的回應。此外，第二屆使用者workshop將於明年二月初在加州理工學院舉辦（正式的通知將在最近發出），有感興趣的同學可以保持關注或者聯繫我。

團隊組織

由於大部分團隊成員在不同的研究機構，我們每周會在Google Hangout上進行PR Triage集中分揀審核提交的PR；此外還有團隊會議，著重討論更宏觀的項目發展規劃（yt Enhancement Proposals）。

此外說說對我個人的影響吧。做為未出茅廬的博士學生，我更多的精力在科研工作上，在yt項目的投入與團隊中的博士後們相比並不算多；然而團隊成員評價說我的開發工作具有high impact，得到這樣的肯定也是非常開心的。由於yt項目較大的影響力，我通過這項開發工作結識了本領域中各個大學/研究機構里許多優秀的開發者和使用者，其中有些研究者向我發出了訪問或者講座邀請，這無疑是提升自己研究工作的知曉度的絕好機會。

最後，如果有同學有興趣願意嘗試使用yt（不局限於天體物理專業），歡迎與我聯繫~

我覺得 Vue 已經寫得不錯！

我看沒啥其他人回復，所以斗膽來一發 :trollface:

先描述一下基本情況（截至發稿時）：

- 項目：Gogs - gogits/gogs · GitHub
- GitHub Star: 8991
- Issue + PR: 1883
- 由於項目原因特殊，別人用了也不會說出來自己是誰
- 無法得知 GitHub 方面的下載統計，但七牛 CDN 部分的是每月 1 萬次下載（整包.zip）

然後是一點 cloc 的統計：

-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Go 207 7773 4299 41986
CSS 14 160 268 8164
LESS 38 410 115 6215
Javascript 18 557 304 5266
XML 15 0 0 1071
Bourne Shell 16 79 86 359
YAML 3 5 0 59
make 1 2 3 6
SQL 1 0 0 2
-------------------------------------------------------------------------------
SUM: 313 8986 5075 63128
-------------------------------------------------------------------------------

接下來是有關項目的細（che）節（dan）：

Gogs 是一個用 Go 寫的 GitHub 仿製品，目的是在非必須使用 GitLab 的場景下替代其使用，重點在部署非常方便，系統常態資源要求低（樹莓派起跑）。

最值得一提的事情就是： people come and go，除了你自己，沒有人會堅守到持續貢獻源碼的戰線上，必須做好他人時刻撤離的準備。因此，**代碼審核必須非常嚴格，符合項目自身規範，因為同一片代碼的下個 提交者很可能就不是同一個人了**。

最奇葩的 issue，絕對是 Copyright violations · Issue #1069 · gogits/gogs · GitHub ，此貨義憤填膺、言辭激烈地抨擊中國是抄襲大國，由於他個人信息根本不全。。我也懶得與他理論，不過還是有眾多小夥伴出來反擊他，讓我非常感動 :trollface:

對生活的影響，作為程序員，那必須是修 Bug 修到天亮！然後直接去上課。。。

厚著臉皮佔個坑
duilib:GitHub - duilib/duilib
目前star 900+，還不達標，不過考慮到早期開源在google code以及一些衍生項目，應該是有1000+的。

作用：
duilib是基於布局和組合理念而設計的一個windows下gui庫，代碼簡潔高效穩定。

值得一提的事：
做duilib之前，我對界面開發也是個新手，雖然有多年的編程經驗，但基本沒寫過界面代碼。基於vikseo的開源項目大幅重構後發布了duilib第一版，懷著忐忑的心情發到csdn論壇上，居然有幾個不認識的網友在幫忙宣傳推廣和維護，最早是踏雪流雲，後來又來了tojen和daviyang等幾個新朋友，大家熱心的提交patch、編寫demo、獻言獻策，本人內心受到很大的鼓舞，就正式把duilib作為一個開源項目來做。到今年8月份duilib也差不多6周年了，雖然作為一個傳統的pc項目，他已經不那麼酷了，但作為一個廣泛應用的ui庫，我個人會一直維護下去的。從長遠看中小團隊開發的通用ui項目已經很難和blink/webkit這類大型項目競爭了，html5+桌面開發平台會越來越流行（比如樓上的electron和nwjs），但duilib還繼續會在對大小和性能有要求的客戶端產品上繼續佔一席之地，並謀求跨平台跨終端的發展。

奇葩的事：
很早以前，有個珠海的程序員給duilib做了個論壇，後來就宣稱自己是duilib的開發者和管理者，被質疑就到處說他從duilib開發團隊分裂，要去做一個牛逼的html5桌面開發框架。實際上，duilib一直託管在google code（早期）和github（目前）上，誰有提交一清二楚，此君沒有提交許可權也沒有提交過一行代碼甚至一個bug呢。

對生活的影響：
10、11年的時候有過多次半夜調試的經歷，後來基本沒有了，偶爾和朋友或同事聊天，能看到對方一臉驚訝的表示，duilib原來是你寫的，我在項目中用過或正在用呢，然後內心小得意一下。

曾經用易語言開發了某百萬級網遊外掛程序（穿越火線），獨創了很多新功能，都是客戶端級別實現的功能，不會被查出來，當時也hack過老外早期發布的模擬版服務端，感覺這些功能官方做至少也要服務端同步才能實現，比如一槍斃命，飛天，遁地，隱形，封包修改商城數據/遊戲結束後統計數據，後來招代理，二級代理，開CF卡盟，很是火爆，賺錢至少也超過7位了，也知道自己不能繼續下去了，想賺更多錢的代價可能是所有錢都被追回然後坐牢。為了避責，賣掉源碼給幾個外掛網站，直接開源到github了，然後就是外掛最瘋狂的時候了，很多人二次銷售我在github發布的代碼，那時做一個外掛就是加一個殼，基本新手就能做到，然後當年就被抓住好幾伙所謂的製作外掛團伙。

那是四五年前的事了，現在絕大多功能都被封掉了，但是內存透視還是用的我的代碼。

github上已經被騰訊舉報刪除了，網上能搜到很多透視源碼，基本都是無修改我11年發布的版本。

我這個項目應該不算是大型，也不算是維護，如果說單純算收入，不論合法不合法，絕對超越此貼其他項目。

佔位。 Vux(GitHub - airyland/vux: Mobile web UI Components based on Vue and WeUI. Be Cool with Vue WeUI. ) 等達到5000Star時就來寫。

一直在開發SeaweedFS 和 Gleam

github.com/chrislusf/seaweedfs 4600+ 分散式海量小文件存儲系統

github.com/chrislusf/gleam 870+ distributed map reduce system in Go.

本來就對數據處理有一些想法。Go可以比較快的開發迭代。寫起來比較有效率。會讓開發過程開心一點。所以就開始寫。寫的心路過程體驗和大家都很像。我說說我經歷的一些。

1）和做一個公司一樣，大型開源項目也都是慢慢積累出來的。一開始也都是沒有任何人理睬的項目。我記得有50star的時候我還很興奮的告訴朋友。後來就麻木了。

很多項目，你想到了，可能別人也想到了。但是你動手去做了，就是不同。人生那麼短，能讓世界因為你而不一樣，多好。

一開始軟體結構比較簡單。經常有人說，"我看了看SeaweedFS，覺得xx實現不好，就自己寫了一個。" 這樣也可以。起碼動手之後，就知道深淺在哪裡了。設計好什麼去做，什麼不做。這是最重要的，也是最需要經驗的。

2）benchmark number porn。很多github用戶都喜歡測試數據。看見數據好了，點個star，就繼續看下一個項目。一開始我沒有做benchmark工具，star增長就比較緩慢。

3）現在 architect 真多。以前Google GFS 使用了單個 namenode 很久也沒有問題。現在的不論多大的公司，就是不能有single point of failure (SPOF)。有SPOF是不能出來混的。

4）大部分人都是人云亦云。看見star多了，才敢於參與進來。技術博客是最好的擴大影響的傳播工具。

5）名字不是那麼重要，但還是有點重要。SeaweedFS的原名是WeedFS。本來是想取「野草」的本意。weed 也有「大麻」的意思。我覺得這個意思也好。技術革新給人帶來大麻的快感也挺酷 :) 。但是有人說，怎麼跟老闆建議使用這個軟體呢，"I recommend weed ..." 。 還有個日本人告訴我weed在日文里是個很壞的名字。所以我還想了好久，改成什麼名字好。

6）github很不方便使用者交流。我在想，可以做個類似travis CI的圖標插件，直接建立一個chat room， 用github 賬號來登陸。我現在用微信群交流。但是沒有歷史記錄。已經快200人了，但是，每次進來一個人就問，「這裡有沒有人用SeaweedFS呀？」 也不給個紅包，我就懶得回答了。:)

我覺得很難。
大家的分工呢？不會誰想做什麼功能就什麼功能吧。比如emberjs 如何做的呢？

（我認為）大型開源項目包含以下任意一個或多個特徵：

  • GitHub star 數量 1000 +
  • 每周都可以接收到多個 issues 或 PR
  • 有一些公司或其他項目在生產環境中使用
  • 任意一個或多個包管理系統中下載量巨大
  • 在項目所在領域中擁有較大關注度

對於GacUI來說，1滿足，2有時滿足，3滿足，4因為C++模板庫通常是不加入包管理器的pass，5這個很難講，反正網上還是有挺多人討論（逃

其實就那樣，對於我來說，開源只是為了分發C++模板代碼方便，並不是我自己想推動開源的。跟維護自己的其他程序並沒有什麼區別，就是每天興起了寫一寫。

但是在我的心目中，GacUI就是一個小項目。大項目怎麼樣至少cpp文件要擠滿一個今年的U盤吧，不然算大？題主的條件只是定義一個項目是否流行。

推薦閱讀：

※日語好是怎樣一種體驗？
※長得高是種怎樣的體驗？
※和三觀不正的人相處是種怎樣的體驗？
※觀鯨是怎樣的一種體驗？
※在國外丟失護照是種怎樣的體驗？

TAG:程序員 | 編程 | Linux | 開源項目 | X 是種怎樣的體驗 |