開源軟體的作者都不上班或者上班沒事做的嗎?

本人之前也想寫點開源的東西,但是每天工作上的東西就疲於應付,根本沒有什麼時間去維護自己開源的東西,後來開源的項目也在網上長草了,廢棄了。

很羨慕那些開源軟體的作者,很好奇,這些人平時都在幹什麼,為啥有那麼多時間可以去維護這些代碼?


我是github上面某個star數700多的項目的作者,應該也算小有感觸了。雖然我的項目還很糙,受認可程度也不高,但畢竟也是投入了許多的汗水。

你需要清楚大部分開源項目尤其是個人主導的開源項目肯定主要是利用業餘時間來寫的。

很羨慕那些開源軟體的作者,很好奇,這些人平時都在幹什麼,為啥有那麼多時間可以去維護這些代碼?

一個開源項目最長的時間是處於維護期,需要堅持。所以你不用 羨慕他們什麼。

這是我目前的持續更新天數,由於沒merge到master分支上,實際已經230天+了。不管周六周日過節與否,發燒了思維難以理順了那也想著完善完善文檔吧。而雖然公司的部分項目採用了我的開源項目,但是公司並沒有給我寫開源項目的時間,所以只能利用業餘時間和提升效率擠出來的公司時間來寫。

如果非要說為什麼我有比別人多的時間來寫開源項目的話,我想那只有兩個字: 熱愛

---------------------update--------------------

沒有想到隨性而寫的竟然收到這麼多贊同和認可,誠惶誠恐之餘,也感覺到大家對熱愛的認同。

很多人問我的項目地址是多少,這裡慚愧的貼一下吧:cymcsg/UltimateAndroid · GitHub ,還請輕拍。


實際上,很多開源的開發是由企業支持,在工作時間完成的。見下圖:

工作日的9點到18點間是Linux Kernel里發生Commit最頻繁的時段。這幅圖來自於2013年一份德國的學術報告,鏈接在下面。

http://dirkriehle.com/wp-content/uploads/2013/08/paid-v8-final-web.pdf

現在,很多大公司都有專門戰略和預算用來支撐開源項目。目前大約70%的開源軟體代碼實際上是由企業出資的程序員貢獻的。

至於企業為什麼出錢支持開源,這是另一個很大的話題了,有空我會在專欄 (Disruption - 知乎專欄) 展開,有興趣的請關注。如果只是簡要地說,包括這些:

較低的開發成本

影響標準制定

更高更快的接受度和認可度(Adoption)

可以圍繞開源展開新的業務(例如SaaS)甚至商業模型(例如Redhat)

經過Peer review的代碼往往更優質

吸引頂尖的開發者

在企業外培養平台的開發者,形成人力資源池

業界聲望

以上。


我的本職工作就是做開源。


在我工作以前,我在學著寫更好的代碼,寫著自己想要的代碼。(7月份以前)

工作以後,我發現白天寫的代碼不是我熱愛的,所以我花更多地時間去commit,去驅動自己。


對於題主的問題,首先給個總括性的回答:大部分開源作者都是有自己的本職工作的,投入在開源項目上的時間主要是自己的業餘時間,而且很多人都像題主描述的一樣,非常疲憊。哪裡有什麼堅持,還不都是硬撐

作為一名開源軟體的作者到底是一種什麼樣的感受?他們的日常生活如何?小開希望用這篇開源作者的自述,揭秘開源作者的日常生活

注意:本文編譯自 Nolan Lawson 的 What it feels like to be an open-source maintainer,會根據理解有部分文字的添加或刪除,歡迎指正。

你的門外有幾百號人在排隊。他們在耐心地等待著你回答他們的問題、抱怨、pull requests 和功能請求。

你很想幫助他們,但是現在你決定把門關緊。或許是因為已經辛苦工作了一整天,你累了,又或許你只是想和你的家人、朋友好好享受一個周末。

但如果你去訪問github.com/notifications,它會一直不斷地提醒你有多少人正在等著你:

好不容易找到一些空閑時間,你打開門並接待了第一個人。他很友善,正嘗試使用你的項目,但是在 API 上遇到了一些困惑。他把自己的代碼粘貼到了評論區中,但是卻忘記或根本不知道怎麼格式化,所以提交過來的代碼非常混亂,難以閱讀。你熱心地將這些代碼進行格式化處理,但即便如此,你仍然需要閱讀很多代碼。而且可能是因為語言或溝通上的問題,他對問題的描述很難理解。

你看了看排在後面的數百個人,糾結是該花半小時來理解這個人的代碼,還是跳過他,只是給他一些有助於解決問題的教程和文檔鏈接。

這時,隊伍里的下一個人開始不耐煩了,抱怨你的項目浪費了他兩個小時,因為某個明確的 API 並沒有像之前說的的那樣如期工作。尖酸刻薄的言辭會讓你感覺很不舒服。因此,你不想在這個人上浪費太多的時間。你簡單地回復一句:「這是一個開源項目,由志願者維護。如果代碼有 bug,請提交可重現的測試代碼或提交 PR 」。

接下來的一個人遇到了一個非常常見的錯誤,你記得之前有處理過類似的錯誤,但是突然想不起來解決方法寫在哪了。到處翻找了一遍後,你粘貼了一個鏈接並送客。

下一位是一名長期貢獻者,你記得他的名字。他遇到了一個非常深奧的問題,並且提出了一個 pull 請求修復。不幸地是,問題很複雜,他的 PR 中包含好幾段解釋文字。想想外面的長隊,你覺得這個人在解決方案上已經做了大量的工作,並且這可能是一個合理的方案,已經通過 Travis 測試。所以想回復一個 「LGTM」 ,然後合併它。但是,你又想起之前有吃過類似的虧。合併過一個 PR 但沒有完整的評估它,以致於後面出現問題讓你非常頭疼。如果你現在合併這個 PR,明天也可能會遇到更多的問題,因此決定先將它滯後,等有更多時間時再去處理它。

下一個人報告了一個阻止他們運行應用的新 bug,但你知道它實際上是兄弟項目中的一個 bug。問題很重要,但你現在沒有時間馬上去修復。因此你回復到:這確實是個問題,但在另一個 repo 里報告會更合適。然後你關閉這個問題,並把它複製到另一個 repo 裡面,並附上一段關於修復該問題的解決方法的評論。

再下一個人只是說了一句「這是什麼狀態?」。你不確定他到底在討論什麼,因此要去查看上下文。結果發現是一個長期的 bug ,許多人不同意原本的解決方案,因此在進行爭議。你需要花很長的時間看完所有的評論去理順他們討論的事情。所以你只好回復一句:「對不起,這個問題已經有一段時間了,但是目前還沒有人解決它。如果有好的想法,一個 pull request 或許是一個好的開始。」

下一個人在運行時遇到了一個之前從未見過的大問題,但不幸的是他沒有提供一丁點關於問題實際發生時的細節。項目用的哪個版本?哪個瀏覽器?要怎麼重現?你只能要求他重新提供一些細節並關閉了這個頁面。

……

流水線

一段時間後,你已經接待了一二十個這樣的人,但仍然還有幾百個人在外面等著。每一個人都有他自己的問題和述求,這很容易讓人感到精疲力盡。

從某種意義上來說,這些通知就是一個關於你的項目的不間斷的消極流。沒有人會因為對你的行為感到滿意時打開一個 issue 或者是 pull request,他們只會在發現缺少某些東西時才會這樣做。儘管你可能只用花費很少的時間來閱讀這些信息,但是仍然能讓你在精神上和情緒上感到疲憊。

家人觀察到你在做完這些事情之後總是脾氣很壞,會問你「如果從事開源工作會讓你這麼生氣,為什麼你還要做呢?」。你想了想,沒有一個很好的答案。

為了自己的身心健康,你嘗試去休息,給自己放一兩周的假。但是你會不時想到有數以百計的人在耐心地等著你。而且每天處理 20-30 消息,總比堆積上百個在那裡要強得多。而且當你回過頭處理這些堆積的問題時,他們可能已經不再關注你或者轉移到另外一個項目了。你很失望,但你也理解他們對你的失望。所以,你決定繼續回答問題,於是,一切又像開頭那樣重新開始。

招募新的貢獻者

像上面這樣處理過很多問題之後,即使你最終清空了收件箱,仍然會發現積壓了大量的 bug 和 pull request。這時,標籤可以幫到你 —— 例如,將問題標記為「需要重現」、「存在測試用例」或者 「good first patch」。「good first patch」 這條尤其有用,因為常常能吸引到新的貢獻者。

等一段時間你會發現,通常吸引新貢獻者解決的那些問題都是非常容易的問題。針對那些問題,記錄下來並且解釋如何修復它比你自己修復它還要重要。你甚至可以特意去創建一些這樣的問題,因為讓新人參與到你的開源項目中是值得的,當 pull request 的提交者告訴你「這是我第一次向開源項目做出貢獻」時,你會覺得很開心。

但通常這些人不會成為長期貢獻者或維護者,你會懷疑自己是不是做錯了,是不是能想點辦法做一些力所能及的,但卻可以吸引新貢獻者並且可以長期減輕負擔的事情。如果你之前有過一個自我維持的項目,一直有一個維護小組在幫你回復每一個問題和 PR,在極其感激這些維護者的同時,會去反思是因為做了什麼事情才有如此多的維護者參與這個項目中,而其他的項目卻只能獨自負責。

展望未來

想到維護的負擔,你不太願意再去創建新項目了。這是一個對立的現象:你的項目越成功,你從 GitHub 的通知那裡得到的「懲罰」就越多。

你偶爾會回憶起創作的激情,從頭開始寫一個新項目,解決之前未解決的問題時的那種喜悅。但是現在你不喜歡這種喜悅,因為任何新項目都會從舊項目中竊取你的時間。你會思考,是不是已經到了正式放棄一些舊項目或者標記它們為不再維護的時候了。

你最想要的是有更多的項目可以自我維護。你嘗試按照最佳實踐:一個 CONTRIBUTING.md 和一個行為準則,並熱情地向所有提交高質量 PR 的人發出邀請,給予所有者許可權。

為每一個項目都做這些事情是非常辛苦的,所以,你並沒有對自己想像中的那樣勤奮,但同時又因為沒有付出足夠的努力來修復問題而焦慮。你想到自己明明可以幫助某人解決他們的問題但是反而讓他們的問題放在那爛了幾個月然後關閉它而內疚,或者明明看到某個人在倉庫發起了他們的第一個 pull request 但是沒有時間去回復而內疚,因此這可能導致他們對開源感到失望。你因自己的所作所為感到內疚,因沒能做到的事情感到內疚,並且不想招募更多的人來分擔你的內疚。

Putting it all together

上面所說的都是基於我自己的經驗,這不代表了所有從事開源軟體事業的人,但是這的確是我個人的感受。

我已經從事開源很長一段時間了(大概 7 年),我一直不願意去對外抱怨這些事情,因為我擔心這會被理解為無意義的發牢騷。畢竟,這種情況不是我自己導致的么?只要願意我可以隨時離開 GitHub,我沒有義務對任何人負責。

還有人會覺得,我不應該感激嗎?我在開源方面的工作讓我獲得了名聲,被邀請在一些會議上演講,在推特有成千上萬的粉絲在聽我說的話並且高度尊重我的意見。可以說我之所以得到了微軟的工作也是因為我在開源方面的經歷。我該抱怨誰?

我知道已經有很多跟我類似的人選擇了放棄,那些曾經積極合併 pull request、修復問題的人消失的無影無蹤。對於其中一些人,我甚至都不會在他們的 repo 上打開 issue,因為我知道他們不會回復。我不會抱怨這些事情,但是我擔心我也會走他們的老路。

我現在已經採取了很多自我保護措施。我不再使用 GitHub 的通知界面,使用郵件進行過濾。因此我可以基於項目或通知類型進行分類。而且使用郵件,也有助於我離線工作,並且在一個地方處理掉所有的事情。

我經常會收到藍色級別的郵件讓我去支持一個我已經停止維護的項目,通常情況下我不會回復他們。還傾向於忽略博客文章裡面的評論、Stack Overflow 答案的回復和郵件里的問題。造成這種情況的原因之一是,我越來越覺得處理問題遠比實際維護一個項目要費時間。換句話說,我經常只有時間閱讀一個問題然後說:「對不起,我現在沒時間看這個」,僅僅是這樣的回復就已經佔用了我原本為開源預留的大部分時間。

Issue templates、GreenKeeper、Travis、travis_retry、Coveralls、 Sauce Labs… 有這麼多針對開源的技術解決方案。我非常感激它們,因為如果沒有這麼多自動化工具,我將無法保持專註。但在某些時候,相比技術問題,你遇到的更多的是社交問題。一個人成不了規模。我甚至不在 前 100 個 npm 貢獻者 之列,就已經感覺到了如此壓力。簡直不敢想像那一百個人會是什麼感覺。

我已經告訴我的妻子,當我們決定開始擁有一個孩子時,可能還是退出開源比較好。我不知道怎樣才能平衡撐起一個家庭和從事開源之間的時間。我希望徹底「核毀滅」能帶來一種積極的生活方式,開啟生活新篇章。

結尾詞

如果你已經閱讀到這裡,並且對開源社區的問題和潛在的解決方案感興趣,或許你會想看看 Nadia Eghbal 寫的 「Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure」,這可能是對問題最清晰和最徹底的分析。

我樂於接受建議,但是請記住,我非常不願意在我的開源項目中將錢和勞動成果混在一起(由於傻傻的理想主義的原因)。雖然,我曾在其他項目中看到二者很好的進行結合。

最後請注意,儘管上邊都是一些消極的話,但是我仍然感覺開源是對我的生活很有價值的補充。我希望能通過這篇文章讓你有所收穫,為自己沒有完成的工作而感到壓力。

如果說我在開源中學到了一件事,那就是:你做的工作越多,你就越需要工作。而且我知道,這個問題無解。

本文轉載自作為一名開源軟體的作者是一種什麼樣的感受? - 開源中國社區


很多公司都有專門做開源的部門,比如英特爾開源技術中心,甚至commit數、bp數將作為個人KPI,公司支持開源也是為了更好的支持自家產品或者提高公司影響力。當然也有很多極客就是熱愛開源,興趣所在,因此樂此不彼。


堅持每天半小時沒你想像中那麼難


恰恰相反,大部分開源軟體的開發都是企業支持的,是專職開發人員開發的,你可以查查kernel的代碼貢獻比例,獨立個人提交的代碼不到10%


不一定,有些有組織的,可能會專屬管理的就會有工資,可能像例如Linus大神

不過大部分,都是有大公司的工作,然後工作中業餘,或者完全業餘。


現身說法
本人是有班上的
我的開源項目六七個吧
大部分項目本身就是工作時抽象出來的
另外本人對coding感興趣
我是每天回家都忍不住摸一把
大過年在家無聊也會寫寫代碼
有癮


也就是用你玩lol的時間來做別的事而已


多數開源軟體的提交者應該都是在上班的,少數是自由職業,極少數是通過開源本身自給自足。

工作任務不可能一直都佔滿自己的時間的,比較閑的時候做下開源提交我覺得很正常,甚至私活性質的項目也沒問題。當然,前提是工作任務完成得棒棒噠,和工友們相親相愛一家人。

另外,下班後時間更充裕,時間就像你懂的,擠擠總是有的。

附:開源經驗談 - 黑客派


現在很多開源軟體都有公司在維護啊,比如我們組用的Spark,Kafka和Elasticsearch(本質上講Elasticsearch不算,本身就是產品被公司開源了)。這些很流行的開源項目的很大一部分commit都是這些公司的人做的


有個競爭對手請了一個boost庫的主要貢獻者,主要是review大家的代碼然後批評之。普通人可以給開源項目提交補丁之類來參與


我現在上班正職是做開源。然後自己有些開源的小項目,基本都是自用的小東西,按自己需求更新。很多都是每天都在用的,只是沒需求更新就一直丟在那。


時間就像乳溝,擠一擠總是會有的!


也有公務員事業單位等成天上班沒事玩玩開源代碼的。多的去了。不要舉報我呀。現在四風很緊的。民怨沸騰。


《黑客與畫家》中有一段恰好解釋了你的問題。大意是畫家,歌唱家並不是每天都在為了自己的興趣工作,他們也需要吃飯,也需要掙錢。所以這些藝術家往往都有一個"day job",他們白天去做那些為了糊口的工作,比如為別人畫像,或是在酒吧唱歌,在晚上才開始做他們真正熱愛的事情。黑客和歌手,畫家一樣,同樣是藝術家。


開源作者之一, 開源百度網盤搜索引擎 https://github.com/callmelanmao/yunshare

在線搜索地址: http://www.biliworld.com


見過同事參與開源項目大多是做的和自己工作相關的東西,比如發現自己用的第三方庫有問題,就直接改進提交到github


推薦閱讀:

你人生中的第一個一萬行代碼是如何寫出的?
做主程序員是怎樣的體驗?
程序員大神都如何支配自己的薪水?
程序員轉行燒烤需要做哪些準備,有哪些優勢和劣勢?
知乎上的程序員大神的擇偶要求高嗎?

TAG:互聯網 | 程序員 | 開源軟體 | GitHub | 程序員生活 |