緣起

筆者自從學習資訊技術以來,一直受惠於開源文化,也嚮往著開源的工作。在幫公司開發軟體時,也同時對世界多一份貢獻,真是非常美好的事情。
很幸運地,我曾經受前公司的老闆賦予這樣的任務:「替公司創造一個開源產品,並以社群方式經營它」,雖然最終沒有太大的成果,但卻是一個很難得的經驗呢。

事實上,有許多的企業都在做一樣的事情 - 選擇性地將工作產出開源,甚至有許多的企業能做到 100% 以開源的方式進行開發。

不知道你是否也有這樣的經驗呢?因為工作需要而使用了某一個 Open Source 軟體,發現了一些問題,你 trace 了很久,最終將它修正了,很想把這個修正回饋回上游。

但是你遲疑了。
「公司允許我這樣做嗎?」
「我發 Patch(或 Pull Request)時要用公司的 Email 嗎?」

有沒有一個工作環境是可以讓我安心地玩社群、掛 IRC、不用區分我的產出是在工作時間內還是私人時間呢?

事隔多年,我在悠夏爾遇到了一群開源同好,我們經過一番努力,我們逐步讓開源文化在公司內成形。

這些年來,因為開放的內部文化,使得我們的溝通更順暢、工作也更愉快了。我們留下了越來越多的程式元件、文件、設計稿、讀書會影片。每個人都樂於分享、樂於向他人學習。我們也不斷成長,勇於打破不適合的規則。我們對於自己的貢獻會「持續保持開放」感到安心。

更進一步地,因為這樣的開源文化,使得大家勇於將產出對外開源。雖然受限於對客戶的合約與責任,我們還無法成為 100% 將工作產出開源的公司,但這是一個好的開始,對吧 ;)

我認為,塑造開源文化應該「由內而外」、「內外兼顧」才是自然。對許多人來說,長久以來習慣是:部門內的員工只能看到自己部門的文件、只能存取自己負責的 Git Repo,這時,如果他們得到公司的指示:「我們鼓勵您將心血開源,給公司外的人無限制地使用」,是很刻意的。

這些年為了促成悠夏爾的開源文化,我與公司夥伴們列出了一些開源工作原則,以下我們就來逐一介紹這些原則。
雖然還沒有做得很好,但我們會朝這個方向繼續努力的。

內部持續開放原則

在公司內就放心學習、無限制地分享吧!

「內部持續開放原則」是指:「無論公司如何成長,所有內部成員享有學習及改良任何公司技術、設計及專案文件的自由,不會改變

舉例來說,以下這些是開放的:

  1. 所有的 Git Repositories 永遠開放給每一位公司成員讀寫。無須取得授權,無須問過「我可不可以這樣改?」
  2. 所有工作規則、工作筆記、專案需求等文件以及設計原始檔,永遠開放給每一位成員閱讀、使用和修改。同上,做任何修改是不需要問過他人的,即便這篇文件是主管擬定的工作規則。(反正有歷史記錄在啊)
  3. 所有成員均可自由地於內部聊天頻道暢所欲言(目前是使用 slack)
  4. 所有成員均可放心地指出目前工作流程或工作習慣中的不良處,提出改善方式。
  5. 想學習公司所知的任何技術,都可以在稱為「許願池」的地方提出,公司馬上會安排人分享。

公司內部就像是一個小型的開源社群,所有人因相同的願景而聚在一起,互相學習、成長。我們盡可能地共享資源,將公司內部變成一個知識寶庫。

有朝一日,公司也許會有更多人、有更多不同的部門。我能否自由學習其他部門中感興趣的項目呢?我能否對它們貢獻所長?或是會被拒於門外?

我相信團隊人數增加後,我們會有更多的顧慮。但我們會努力捍衛這個原則的。

可重用原則

擁有自由之後,提升分享的品質吧!

「可重用原則」用意在於提升開源品質,白話一點的解釋是:「所有的文件、設計、程式與流程,需致力於讓他人方便使用。

依「內部持續開放原則」,所有的內部分享、伺服器管理紀錄、檢討報告、專案日誌、程式產出等,均是對內開放的。當數量越來越多、越來越雜,有許多東西漸漸沒人看得懂了。我們需要致力於改善它的可重用性,讓下一次需要這些項目的人得以快速地使用它。

舉例來說,某一些程式在開發初期可能是寫死的,只有某一個專案可以使用。但因為可重用原則,我們會提醒自己致力於將這個程式元件化,即便會多花一點時間。

另外舉一個文件的例子:
當我們對產品做了一個重要決策,如果它的會議紀錄只是一個 「2017-05-05 會議記錄:經過投票,結論是使用 A 方案」這樣的描述,對於想從各方角度了解會議的其他人幫助不大。我們採取共筆方式完成,相關與會人員會補上:「選擇 A 方案的人的人的理由是什麼?」、「反對它的人的理由是什麼?」、「其他的選項是什麼?」,讓往後他人可以快速查找並進入當下的情境。這樣子使得這份記錄被review的機會增加,它的價值提升了。

這個原則幫助我們時常思考要怎麼讓產出被他人持續使用,而不只是淪為自己一個人看得懂得東西。在軟體上,它同等於致力於優良的設計模式。在文件上,它代表著以文字或圖像精準表達出自己的思維。

為了更有效地提升品質,目前我們我們採用的做法是:「程式使用 TDD 開發」、「文件以 Executable Spec 為最終目標」。限於篇幅,先不繼續討論它,下回我們會分享我們努力朝這個方向前進的心路歷程,請繼續支持我們的 How We Work 系列文章囉。

開放優先原則

自在分享

當「內部持續開放原則」與「可重用原則」進行了好一陣子後,我們有越來越多的內部私有產出。

這些私有產出中不乏我們認為對外部也有價值的軟體元件或文件,我們很想將它開放,然而,我們時常顧慮著:「這裡面會不會很多 typo 啊?」、「這邊程式寫得很醜會丟臉耶」、「網路上已經有別人做得更好了」、「這開放出去被學走好嗎」等。

因為這些顧慮,使得這些項目隱藏了許多的「開源門檻」,阻擋我們將它們真正開源到 GitHub 或部落格上,這些隱藏門檻有:

  1. 不違法、不違背合約
  2. 夠獨立、夠泛用
  3. 真的對他人有幫助
  4. 文件充足,用得人看得懂
  5. 不造成公司損失
  6. 得到技術主管同意並且 review 過
  7. … 可能還有很多很多

但仔細想來,只有第 1 點是必須遵守的條件。

為了鼓勵開源,我們新列了一項原則,稱為「開放優先原則」,它的意思是:

在不違法、不違反合約的前提下,優先以開源的方式開發所有的元件及文件。例如在 GitHub 上開源開發元件,再引入私有專案使用。不需要取得公司同意。

有了這個原則,我們來回應一下一開始的兩個疑問吧!

「公司允許我這樣做嗎?」 => 當然,公司直接鼓勵我這樣做!

「我發 patch(或 PR)時要用公司的 email 嗎?」 => 看喜歡用哪個就用哪個囉!

當然我們更喜歡同事把公司開源項目放在 GitHub 中的 UniSharp 群組內,畢竟這樣比較好找。而且因為群組內同仁都有寫入權,因此要修改時不需要發 PR 會更方便,會更符合第一個「內部持續開放原則」的!

同時我們也鼓勵同事經營自己個人帳號下的開源項目。無論是與公司業務有關或無關的。

這樣的原則下,使我們近年在 GitHub 上的開源項目大爆發。雖然因為不刻意行銷,也時常是工程師的神來一筆,沒有留下什麼好文件,不一定有很多關注。然而本著 Release Early, Release Often 的精神,及早開放就是及早得以討論與分享。我們很開心也自豪地會繼續這樣做。

最後,也是開始

人類的生命及專注力是有限的資源,必須珍惜。希望某一天,在地球的某一處,有人因為我們的分享而無痛完成一項工作,得以有時間回家幫小孩過生日,或是用這些時間把自己擅長的事情分享給其他人,讓這樣的分享持續下去。

感謝各開源社群帶給我們的幫助,無論我們做得好不好,都希望能將這份精神傳遞出去。

特別謝謝 Allison RandalOpen Source Enlightenment唐鳳 精彩的「開源之道」分享,每當我對「工作的意義」甚至「人生的目標」感到迷惘時,這份簡報總是幫助我撥雲見日、找到方向。

開源不神聖,它僅自然的、快樂的。請加入我們吧!