過去寫了這麼多在Automattic工作的好事，今天趁著在等程式碼發佈的空檔，來寫個數年來懸宕未解的問題：維護孤兒 —— 發佈之後，儘管使用者眾多，也永遠拿不到資源維護的專案。
會下這麼聳動的標題，是因為我覺得這是我們鬆散、高彈性、強調速度、根源於開源專案的工作文化的一體兩面。我們內部同時啟動的專案非常多，一個專案也通常短則1~2週，長則2~3月就發佈了，發佈之後呢？人就四散去做別的事情去了。在剛開始的一兩個月，要找到原班人馬處理後續維護還算可行，但隨著時間過去，要追溯愈來愈困難，優先序也逐漸受到新的專案擠壓；issue延宕的時間從本來可能2到3週，逐漸推進到2到3個月，當開始出現超過半年也沒人解的issue，我們便又多得到一個維護孤兒，可喜可樂、可喜可樂。以前曾讀過某篇文章論中國的高速經濟擴張弊病，裡面有一句神比喻：「步子邁太大，扯到蛋了」，差不多就像這種感覺吧？衝太快，掉好多包了。
一個很好的例子是calypso專案的自動化end-to-end測試。概念上，每當有一個PR被標上"needs review"，我們的系統會自動在calypso.live上設立起一個docker container來跑該分枝的calypso，再用tests/e2e下分類為canary tests的自動測試去確認基本的正確性。如果進一步標上"needs e2e tests"，那就會有好幾卡車的桌面版與行動版end-to-end測試對它這捏那拉、上沖下洗的，跑到PR吱吱叫。
這聽起來很美好，但有個問題：calypso.live相當不穩定，所以就會常常發生automated e2e tests不過，打開一看是calypso.live起始失敗：
這造成很多問題。開發人員常常被迫去檢查這個false negative，一開始大家還會想說重跑一下，久而久之大家就開始留下「此錯誤與本PR無關」等話，然後就忽視過去了。結果呢？曾經發生過有些不該忽視的也被忽視，造成好一段時間帳號註冊無法使用。由於一旦出錯，CircleCI會自動通知該repo的所有人，這類訊息看久了大家紛紛設inbox filter直接把它濾掉，試問這樣CI的意義還剩下多少？
這樣天天在用的東西，應該很快就會被修好吧？很遺憾，大概快一年了都還是這樣。像這樣即使很多人在用仍然成為維護孤兒的內部工具多到不行，今天舉calypso.live為例只是它會出現在公開的源碼庫中，比較方便講而已。
換個角度想，這也是為什麼一旦組織大起來，自幹前要三思 —— 長期維護成本難以估計，自己能投入多久亦未知。
軟人手札 