參與開放源碼本應的模式

今年開放源碼界 (open source community) 發生過開放源碼名書 The Cathedral and the Bazaar 作者 ESR 被 Open Source Initiative mailing list 禁言。之後又發生過三位 pytest 的核心開發者因麻煩人參與而先後請辭,最後由餘下的核心開發者決定禁麻煩人參與,離開的三位才回到 pytest。

我亦曾聽過有人說:「我都支持 open source 架……blah blah blah」
又有聽過:「我都搞 open source 架……blah blah blah」

聽到有人講支持及搞 open source 固然好事,很高興。不過有時候再聽下去,或者後來觀察其行為,我會有疑問:「到底他的行為是否依 open source 而行呢?」

這情況絕不是香港獨有的情況,當 open source 流行起來,這世界便不斷發生一些對 open source 的誤解,或脫離原有的開源框架的行為,讓我這種老一輩開源人不禁回想 open source 本應是怎樣?

當今年我準備一個新計劃:incubator program,以類似 coaching 方式,幫助新貢獻者或project等投入開放源碼的project社群模式。其中一樣我認為要做的:讓新貢獻者或project owner重新思考開放源碼本應模式。這些經驗分享能幫助他們或projects的發展。

Open Source 不是只放 Source Code

第一,open source 並不是只放 source code 上 GitHub 出來就是 open source。至少你還要說明 source code 的「授權條款」(licensing),而該 license 必需合乎 OSI 或 FSF 所有 open source 授權要求才是 open source license。以一般例子比喻,只放圖片、媒體檔、presentation slides上網上 GitHub 不算是 open 開放給大眾,你也必需以例如共享創意 (Creative Commons) 授權條款才是 open 放給大眾。

Pull Requests 不是你想就入

當 open source 出來後,也許有用家尋找到你的 project,試過合用,然後用家社群可能擴大起來,就多了機會有用家給contributions(pull requests)。

當有 pull requests 時,由 project owner 決定合併 (merge) 或是拒絕 (decline)。並不是每次有人願意 contribute 就獲得接納而 merge,project owner 會依據當時不同因素而決定是否接納。每個 contributor 都會覺得自己有心 contribute,有理據有經驗有技能去 make this contribution,但這是否合乎 project owner 要求、觀點、取態、目標、roadmap……?這些就由 project owner 依據他的經驗去判斷把關,沒有絕對的對與錯。

行為守則與社群發展

現實中不同 open source projects 都有機會有人挑戰 project owner或其他 contributors 的決定,大多 open source projects 設有行為守則 Code of Conduct 去做一個正面態度既社群 (positive environment)。

The GNOME project 行為守則 Code of Conduct 中的 Community Guidelines,就有寫明 Be considerate. Remember that decisions are often a difficult choice between competing priorities. Focus on what is best for the community. 意譯就是:落決定通常唔係一件容易既事,通常都係比較唔同輕重,為社群的最好來著想。

創始人創立一個 open source project,亦是這 project 的 project owner 及最終決策人,他做得好,project就會成長擴大,繼續走下去,很難想像一個創立好project的創始人不為社群的最好來著想。直到創始人決定退出,就可能交棒由新決策人成為 project owner,或是沒有人再 maintain project 就完結任務。當有新決策人,就會有新的作風,那麼project的發展就自然跟原有的不同,屬另一個發展,對社群發展是好事還是壞事就要看前因後果和發展情況了。

最後一招: Fork but not f__k

決策人作出最後決定,你還是對 project 不滿?你可以 fork 而不是 f__k﹐或是開一個新 project。

當你對當事人 f__k、對別人 f__k、在公眾場合 f__k、或是自以為對空氣 f__k,這些行為都是有違 open source 的原則,也不是恰當、不是 positive 的行為。當然你可以抒發個人情緒,你可以心裡 f__k,你也可以在私人地方對著願意讓你抒發個人情緒的人 f__k。

Think positive, be considerate 是參與 open source 的應有態度。

講一句「支持 open source,搞 open source」很易,門檻很低,做起來還是要靠自身的實作、經驗和堅穩的信念。如果人錯你對,有心人何不 fork 或另起來做呢?

兄弟爬山,各自努力,互相包容,才能創造出最好的 open source 環境。

圖片作者: Vkw.studiogood (CC BY-SA 4.0)



自製港鐵即時班次資料一頁過

查港鐵即時班次一直有一個UX問題,就係響APP碌來碌去先查到。有時響車站等人想知道大約抵達時間,就要碌好多次來自行估計,如果等既人需要轉綫,碌得重多。

不幸之中既大幸係,港鐵響舊年透過data.gov.hk提供即時班次既開放數據,早兩個月有晚就手痕,快快手用python寫左個web scraper(網絡爬蟲)。不過這方式不能直接在網頁顯示數據,就再寫一個javascript版本直接render出資料。

呢個第一版港鐵列車即時班次javascript最岩我用係一頁過顯示成條綫既班次時間,只需開呢頁,就好方便自行評估到底朋友幾時到站。就算係查某站下班車時間,都係好直接方便。

有第一版後,當然想繼續改造成第二三四版。其實已經有第二版,不過收埋響較隱蔽地方。

Hong Kong Open Weather Data

Select_weather_data_to_change_Django_site_admin_-_2014-05-11_02.53.29

In Hong Kong, weather data is not ready for open, only 7 RSS feeds of latest news/updates from different weather reports are available on Data.One. which I presented at BarCampHK 2013, and announced my open source project hk0weather to be an interim solution of Hong Kong Open Weather Data.

hk0weather provides few open source web scrapers and parsers to scrap Hong Kong Observatory web pages, and parse data into useful machine readable data format.

Last week, I made parsed weather data stored to Django, so we can read data on Django web admin. And Hong Kong rainfall data is added to hk0weather early this week.

You are welcome to contact with me to look at demonstrations and develop your own front-end to use data produced by my software.