疲勞流行證明開源機器上有太多 Rust

https://www.theregister.com/2024/01/22/rust_project_burnout/

開源開發者的疲憊流行症證實了齒輪上的鏽蝕問題過於嚴重

開源疲憊問題再次浮出水面,這次與 Rust 項目有關。然而,這個問題並非新問題,解決方案也不是。一篇由資深 Rust 工程師 Jynn Nelson 上週發表的長篇部落格文章詳細記錄了這個問題,稱:「因疲憊而離開 Rust 項目的人數非常之高,同時,接近疲憊的人數也非常之高。」Rust 項目最初是 Mozilla 的一個副項目,目前由 Rust Foundation 支持。根據 2023 年 Stack Overflow 開發者調查,這是開發者最欽佩的創新語言。然而,這也是一個眾所周知的問題,對於貢獻者來說也是一個眾所周知的模式。一位工程師熱衷於參與該項目,開啟問題追蹤器,發現了一些他們關心並希望修復的問題。這些問題都很棘手,因為所有簡單的問題都已經解決。尋找導師很困難,因為如 Nelson 所說,「所有有經驗的人都過勞和疲憊了」,所以工程師最終獨立進行了大部分的工作。「猜猜你在這個時候已經學會什麼了」Neslon 寫道。「除非你親自推動,否則這個項目不會進行。」工程師成為了更積極的貢獻者,以至於現有的維護者轉交了許多責任給他。他們最終要審核 PR 並為發現的錯誤負責。無法跟上 PR,他們開始感到疲憊…等等。疲憊可能以多種方式表現,避免疲憊歸結於自我關懷。「Rust Foundation」不願對此問題發表評論,但疲憊問題在開源世界中和商業世界中一樣普遍,甚至更加普遍。DataStax 開發人員關係副總裁和 Apache Cassandra 共同提交者 Patrick McFadin 告訴 The Register 說:「問題可能在於『如果我不做,就沒有人會做』的心態。在一個大多數人獨立但協調工作的項目中工作可能會變得繁瑣。大多數開源項目都沒有專門的專案管理或支持人員來幫助。事實上,大多數項目對於企業提供這項服務都不樂見,因為這看起來像控制。結果是在許多開源項目中產生了經典的「共有財悲劇」問題:很多人受益,但付出回報的人卻不夠多。」他的建議與 Nelson 的類似,後者建議處理疲憊的文件至少和處理技術問題、調解衝突一樣重要。「花更多時間進行協調和專案規劃,比你認為需要的更多。然後再多做一些。不要讓個人覺得這都是他們的責任。」Percona 的技術推廣者 Dave Stokes 也指出在開源社區中疲憊的風險。他表示:「對於獨立或小型團隊項目來說,往往缺乏人才深度來分散工作或應對緊急情況。許多項目都是在工作之餘進行的兼職工作,影響著家庭或個人時間。對於工作得如此辛苦的人來說,說不出『不行』是很困難的。很多人發現很難自我監測疲憊,也很少知道如何在不完全脫勾的情況下離開。」Stokes 還指出了辨識這些跡象的困難。 「如果 GitHub 等工具能夠在開發人員提交代碼時進行檢查就好了。然而,社區必須自我監督,在這個遠程世界中幾乎是不可能做到的。」Stokes 最後稱讚了各個開源社區生產的代碼質量和一致性。「像是 PostgreSQL 這樣的大項目每年都交付出比之前版本性能更好的版本。」但代價是什麼? ®

via The Register

January 22, 2024 at 11:35PM

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *