為何身為程序員的你，不選擇開源？

近年來，「開源」成為各大科技公司技術加速落地與普及的推動力，不過在不斷迭代的發展中，我們也發現一個至關重要且亟需解決的一個問題：發布自行研製的開源軟體通常需要開發人員投入海量的不可預見的工作。如今雖然開源軟體在科技界被公認為至關重要的軟體，但它的資金支持卻是不可持續的。

此前，我們也根據諸多的調查報告發現，很多個人開發者之所以不選擇開源的首要原因就是在時間精力有限的情況下維護開源項目的成本太高。

針對這一問題，究竟該如何在研發維護與資金支持間保持平衡？對此，你有著什麼樣的看法？

作者 | Anna Nowogrodzki

譯者 | 蘇本如，責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

4月10日，天體物理學家宣布他們拍攝了有史以來第一張黑洞照片。這是一個令人振奮的消息，但是這些令人眼花繚亂的新聞卻沒有一個提到，如果沒有開源軟體的幫助，拍攝這個照片是不可能的。這張照片是使用 Matplotlib 這個 Python 的繪圖庫, 以及開源 Python 生態系統的其他組件創建的。然而，就在五天後，美國國家科學基金會（NSF）否決了一項資助該開源生態系統的撥款提案，稱該軟體缺乏足夠的影響力。

這是一個常見的問題：開源軟體在科技界被公認為至關重要的軟體，但它的資金支持卻是不可持續的。開源軟體的支持工作通常由過份努力的研究生和博士後加班處理，這往往導致他們筋疲力盡。位於馬薩諸塞州劍橋市的哈佛大學暨麻省理工學院的布羅德研究所的計算生物學家安妮·卡彭特（Anne Carpenter）所在的實驗室開發了圖像分析工具 CellProfiler，她說。「這就像當他們的奶奶去醫院的時候，有醫療保險支持和只能依靠 GoFundMe 眾籌平台的區別。對開源軟體而言，這不是一種健康的生存方式。」

編寫開源軟體的科學家往往缺乏軟體工程方面的正規培訓，這意味著他們可能永遠不會有機會學習代碼文檔和測試的最佳實踐。但維護不善的軟體又會浪費時間和精力，並妨礙軟體的重用性。紐約冷泉港實驗室的計算生物學家亞當·西佩爾（Adam Siepel）說，使用計算工具軟體的生物學家通常要花費「一個又一個小時」的時間來讓其他研究人員寫的代碼運行起來。亞當·西佩爾同時也是 PHAST 的一名維護人員，而 PHAST 是一種用於比較和演化基因組學的工具軟體。「他們要花時間找到這些代碼，但有時沒有網站可找，或者鏈接斷了，或者編譯不通過，或者當他們試圖在他們自己的數據上運行軟體時，軟體崩潰了。」

但也有一些資源可以提供幫助，還有一些模型可以模仿。德國海德堡歐洲分子生物學實驗室的計算生物學家沃爾夫岡·胡貝爾（Wolfgang Huber）說，如果你的研究小組計劃發布開源軟體，你可以開始為軟體的支持工作以及人們開始使用後出現的問題做準備了。這項工作並不容易，但它可以為開發人員贏得讚譽並提高他們的知名度，同時提高該領域的工作效率。他另外補充道，「我認為這是一種樂趣。」

有一個計劃

對於科學軟體的開發人員來說，軟體發布日不是工作的結束，而是開始。來自北卡羅來納州羅利市的賽倫斯的數據科學家蒂姆·霍珀（Tim Hopper）在 Twitter 上說道：「給一個人一條魚，你只需要喂他一天。寫一個為他釣魚的程序，你就要用一輩子來維護它。」安妮·卡彭特僱傭了一名全職軟體工程師來處理 CellProfiler 軟體的維護工作，該程序每年記錄大約 700 個問題和 100 個錯誤報告或新功能請求，或者每周記錄大約 15 個問題。但大多數開源軟體維護都是基於自願的基礎上完成的。「這些維護工作都是我自己在午夜後做的。」承擔了 PHAST 技術支持工作的亞當·西佩爾說。

為了應對即將發生的事情，了解你將要從事的工作性質會很有幫助。一些軟體只需要短期支持，而其他軟體可能會使用幾十年。Nelle Varoquaux 指出，在生物學機器學習領域，軟體工具很快就會過時，因為數據集的大小變化是如此之快。Nelle Varoquaux 是加州大學伯克利分校的計算生物學家，也是Scikit-Learn（一種基於 Python 語言的機器學習工具包）的共同開發人員。她說：「當我開始攻讀博士學位時，我所做的每件事都需要用到隨機存取存儲器，而且我從來沒有碰到過內存問題。」但是今天，內存變成了一個巨大的挑戰。她估計，她為了分析 DNA 和染色體構造而建立的兩個工具(Iced 和 Pastis)，在經過五年的維護時間後，就會變成過時了。

她補充說，軟體過時並不是一件壞事：知道何時停止對軟體的支持是一項重要技能。「在一個工具的效用達到極限時讓其死去，或者當維護者想要退出時，讓它成為孤兒並為它尋找一個養父母。」 沃爾夫岡·胡貝爾 這樣建議道。

約哥倫比亞大學的機器學習科學家安德烈亞斯·穆勒（Andreas Mueller）指出，無論你的軟體要使用多長時間，良好的軟體工程實踐和文檔都是必不可少的。這些包括持續集成系統（如TravisCI），版本控制（Git）和單元測試。穆勒說道：「持續集成系統會在你每次修改代碼時後，告訴你代碼是否仍然有效，或者是否遭到了破壞，只要你為它編寫正確的測試程序來運行。版本控制則是一個記錄源代碼更改的系統，這樣你就能夠在必要時將代碼恢復到任何以前的版本；而單元測試則測試每個單獨的組件，以確保它的完好無損。三者結合在一起，會100%節省你的時間」。一些組織，如志願者運營的Software Carpentry和西雅圖華盛頓大學的eScience研究所，舉辦軟體開發訓練營，並在Github上提供教程。位於阿姆斯特丹的荷蘭eScience中心則在網站https://guide.escience center.nl上提供了軟體開發最佳實踐指南。

為了便於維護，Nelle Varoquaux建議將重點放在代碼可讀性上，而不是峰值性能上。她說：「我總是努力讓代碼保持良好的可讀性，有良好的文檔記錄和並且仔細測試，這樣如果有什麼東西壞了，我可以很快修復它。」

當涉及到軟體時，這是不可避免的：「一旦你有了用戶，他們就會發現bug，」 Nelle Varoquaux說道。而沃爾夫岡·胡貝爾則建議通過使用像Stack Overflow這樣的公共論壇來回答用戶問題，在那裡用戶可以使用軟體名稱來標記他們遇到的問題。他建議：「不要回復用戶發來的尋求支持的私人郵件。」並指出公共論壇有三個優勢。首先，他們接觸的用戶比單個電子郵件多。相對於一個寫電子郵件的人來說，可能會有100個人太害羞了而不敢提問。第二，他們傾向於鼓勵更專註和更深思熟慮的問題。第三，他們可以阻止用戶不要發送同樣的問題給多個軟體維護人員從而浪費他們的寶貴時間。

沃爾夫岡·胡貝爾還建議將你的軟體提交到一個代碼存儲庫，如CRAN（Comprehensive R Archive Network）或Bioconductor中，而不是發布到你的個人主頁或Github中。CRAN或Bioconductor是一個用R語言編寫的生物軟體的傘狀存檔網路。像科學期刊一樣，這樣的存儲庫有專人管理，並且在提交時有命名規範和組件要求的指南。沃爾夫岡·胡貝爾提出，CRAN和Bioconductor在多個平台上提供測試和持續集成，以及強大、易於使用的安裝程序。

資金支持

軟體支持需要時間和資金。但資金可能難以獲得。美國國立衛生研究院（NIH）和美國國家科學基金會（NSF）關注於新技術的研究，而開源軟體的維護工作往往不符合他們的要求。安妮·卡彭特說：「總的來說，這確實是資助機構的悲劇。他們會資助50個不同的小組來創造50種不同的演算法，但他們不會為一個軟體工程師付錢。」

但這些組織和其他組織確實提供了一些資金。一個Twitter話題（詳見go.nature.com/2yekao5）記錄了來自NSF的生物基礎設施司，NIH的人類基因組研究所和國家癌症研究所，以及NSF和英國生物技術和生物科學研究委員會（現為英國國家科研與創新署（UKRI）的一部分）的聯合項目的資助。私人的美國基金會，如戈登和貝蒂摩爾基金會，艾爾弗·斯隆基金會和扎克伯格夫婦成立的CZI基金會也在資助開源軟體的支持工作。CZI基金會為基於Python的圖像處理軟體scikit-image，ImageJ和Fiji platforms提供資金支持，同時也為安妮·卡彭特團隊的軟體工程師提供資金支持。

在英國，愛丁堡大學的軟體可持續發展研究所為英國的研究人員或其合作者提供免費的、簡短的軟體可持續性在線評估，以及3000英鎊（合3800美元）的獎學金。該研究所定期為人們提供長達六個月的時間與專家合作開發新軟體或改進現有軟體和維護實踐的機會。在德國，沃爾夫岡·胡貝爾建議歐盟網路撥款委員會和德國科技部下轄的deNBI基金會為Bioconductor提供資金支持。

數字基礎設施維護的普遍問題越來越受到重視。Nelle Varoquaux和她的同事從艾爾弗·斯隆基金會和福特基金會獲得了138,000美元的資助，用於研究「維護開源軟體的可見和不可見的工作」，包括投入時間從事這項工作的研究人員的過度勞累。這筆資助是由13個數字基礎設施研究項目組成的投資組合的一部分，總計資助總額達130萬美元之多。今年5月，CZI基金會宣布批准三項要求資助開源生物醫學軟體的申請，其中第一項資助將於今年6月開始。亞當·西佩爾在《基因組生物學》雜誌上也發表了一篇評論文章，討論了對開源軟體的支持工作提供資助面臨的挑戰。

編寫方便他人在廣泛數據基礎上使用的軟體比編寫只為你自己工作的軟體要花費更多的精力。沃爾夫岡·胡貝爾說道：「這個差別非常之大，至少相當於一篇發表在《自然》雜誌上經過潤色的論文和在實驗室會議上演示基本實驗結果的第一堆幻燈片之間的差別。」

不過，這種時間和精力的投入還是有實際價值的。亞當·西佩爾的團隊有時會回答用戶提出的問題，並指出他們將軟體應用在錯誤的數據上。這是進化生物學家才會注意到的細微之處，但是軟體工程師可能不會注意到。「有一句慣用語叫：吃自己的狗糧。」 沃爾夫岡·胡貝爾說：「如果你用自己開發的軟體來解決你面臨的真正的問題，那麼你就會知道這個軟體哪裡不好，哪裡有缺失。讓一個領域專家編寫解決這個領域問題的軟體往往會使這個軟體更加有價值。」

原文: https://www.nature.com/articles/d41586-019-02046-0

【End】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！