(這是 Allison Randal 在 OSDC.tw 的演講中譯本。請參見原文及錄影。)
這幾年來,我慢慢覺得,我們參與開源社群,就像是在一條道路上並肩而行:這不僅讓我們成為更好的程式設計者,也讓我們通過與人合作,而成為更好的人。
您可以將它想成一條修行之道,讓身而為人的我們能夠不斷成長。接下來,我想談談我對開源世界的個人觀點,希望能與您分享。
(這是 Allison Randal 在 OSDC.tw 的演講中譯本。請參見原文及錄影。)
這幾年來,我慢慢覺得,我們參與開源社群,就像是在一條道路上並肩而行:這不僅讓我們成為更好的程式設計者,也讓我們通過與人合作,而成為更好的人。
您可以將它想成一條修行之道,讓身而為人的我們能夠不斷成長。接下來,我想談談我對開源世界的個人觀點,希望能與您分享。
首先,人是一切開源專案的核心。程式碼是很重要,但最核心的永遠是人。
人們透過各種不同的方式來參與專案:有人寫程式,有人寫文件,有人寫測試。而使用軟體的人,同樣也是專案裡不可或缺的一部分。
您的專案也許會用到別人開發的軟體,而因此接觸到上游的專案,或許偶爾也會向他們提出建議和修正。
又或許您開發的是一套程式庫或模組,提供給其他專案的人使用。此時,您就是他們的上游專案,他們也會用相同的方式來與您溝通。
所以,人們到底為什麼要做開源軟體呢?如果您想理解開源模式如何運作,這是一個很關鍵的問題。
許多人在日常工作中,可能已經常常和軟體打交道了。我們為什麼要花額外的心力,來參與開源專案呢?一部分的原因,是因為這能夠讓人迅速接觸到刺激、有趣的新鮮技術。
能夠與人分享,也是一個主因:透過與人分享,我們可以認識開源專案裡的同好,來提升彼此的樂趣。
投入開源專案的人,往往也帶著分享奉獻的精神。能夠伸出雙手幫助別人,是身而為人很重要的一部份。
除了這些內在因素,參與開源專案工作,也可以得到許多回報。其中一項,是獲得別人的敬重:當我們創造新的事物與人分享,進而吸引人們一同合作時,人們自然會認識我們的人品與才能,從而為我們自己帶來成就感。
換個角度來看,這也意味著:我們應當對於加入專案的人表示尊重,這樣人們才會願意繼續參與專案的活動。
欣賞別人的作品也很重要。當人們發表自己的作品,而您有機會與他們交流時,即使是一封簡單的電子郵件感謝函,說「您的專案對我很重要」,也足以營造出一種正向的文化,讓大家都能保有繼續創造的動力。
懂得讚美也很重要。當您介紹專案時,不要忘了讚賞您身邊的人,讓大家認識這些人是誰、做了多麼棒的貢獻,以建立社群的認同感。
之所以有那麼多人持續對開源專案保持興趣,其中一個原因是這樣的:在合力工作時,我們的能力會愈來愈強,能做的事也愈來愈多。
光用簡單的算數來想:如果我們有兩倍的人,至少就可以寫兩倍多的程式,有三倍的人就可以寫出三倍的程式。不過,我們的能力遠遠不止這些。
在一起合作時,我們可以透過彼此鼓勵,讓彼此變得更好更強大。當您看到其他人正在解決艱難的問題時,您不妨鼓勵他們,跟他們說:「你做得很好,而且我看得出來,你在未來會做得更棒。」
僅僅是透過談話和分享,您就可以為他人培力,讓對方變得更好。
還有一點就是,當許多人聚在一起的時候,每個人都有不同的能力。一起工作時,可能您知道專案需要的五樣東西,而其他人知道另外五樣東西,您們互補長短,就有了一整套技能足以完成專案,而這是單打獨鬥時做不到的事情。
所以在多人合作時,不只是生產力倍增,還可以達到互相加乘的效果。
另一件很重要的事,是鼓勵彼此放眼未來、看得更遠。我們可以給其他人靈感,幫助他們解決有意思的問題。有時,只要說「我有這個想法...」,別人就可以將它化為現實。
有些時候,您只要看看別人在做些什麼,然後告訴他們您想到的關鍵之處,不必自己跳下去實作,也可以幫助他們走得更好更遠。
在做開源工作時,我們得時常提醒自己,我們並不是孤身一人。由於需要和許多人合作,我們最需要注意的,就是不斷改進自己的溝通技巧。
我們經常會彼此溝通對未來的規劃,例如軟體專案的發展藍圖,以及我們的個人計劃,像是接下來想要實作哪些功能等等。
在開源社群中,我注意到一件事情:人們對如何做軟體往往有很好的規劃,可是卻由於缺乏良好的溝通,而讓彼此的計劃互相衝突。如果您朝向某個規劃埋頭開發,而沒有與人溝通的話,很可能會傷害到其他朝向不同方向開發的人。
我們就像一窩在蜂巢裡的蜜蜂,要經常發出嗡嗡聲,才能讓彼此持續發揮功能。
此外,我們還會不時討論技術問題,嘗試找出最好的解決方案。在面對技術問題的時候,人們可能會互相爭論、甚至大動肝火,讓事情難以獲得實質的進展。
所以,我們在工作過程裡,要逐漸學會接受各種各樣的可能性。對於您自己想到的解法,您當然應該持續努力,但也不妨對別人所提出的其他可能性,抱持開放的態度。
而在您自己的工作有所進展時,也可以透過各種通訊管道,讓大家知道您做了些什麼。發電郵、寫推特… 有很多方法能讓人們知道您的進度。
有時候我們可能會覺得害羞,或是不想被別人認為自己在吹噓。但其實事情完全不是這樣!多溝通對專案有好處,對專案裡的人也是好事,因為他們可以從您所作的事情裡學到東西。
溝通的另一個重點是問問題。有社群的好處,就是可能有人已經解決過您正在面對的問題。透過論壇或聊天室主動發問,可以為您省去很多時間。
同樣的道理,當別人想要學習時,您也可以認真回應,而不是對簡單的問題拋下一句「RTFM(去看該死的說明書)」就算了。
如果您回答「RTFM」,的確可以為自己省些時間,但是您一旦這麼做,同時也是在告訴別人說,他們一開始就不應該問問題。而這絕對不是您想要的效果,您要的是培養對方溝通的意願。
學著如何去給別人有幫助的答案,幫助他們一同走上這條開源之道,日後他們才能把這條路走得更長、更遠。
有些時候,批評別人是必要的。雖然我們對各種可能性抱持開放的態度,但針對特定的技術問題,確實可能有某種解法比其他的都要正確。即使如此,當您想要讓別人改變他們的看法,最好的方式是用友善的態度提出回應,對方才會用開放的胸懷來向您學習。
即使對方態度惡劣,也請保持優雅。難免有些人會對您很不客氣,但這也是參與開源的必經之路。有時候,臉皮厚一點也有好處。雖然有些人的溝通方式有待加強,但他們說的內容或許也有可取之處,您還是可以從中學到東西。
從這個角度來看,就算人們說話的時候不禮貌,您還是可以禮貌地回應他們。
溝通的另一部分不是說話,而是傾聽。有時我們須要做的,不是告訴別人我們的想法,而是靜靜地坐好,讓別人暢所欲言。
光是聆聽是不夠的,我們還需要有同理心。英文有句俗話說:「如果您真想瞭解某人的話,請穿上他的鞋走一哩路。」 — 或許只有這樣,您才能明白別人所經過的煎熬。
有些人以為,能夠從事開源軟體工作的人,個個都得是天才。事實絕非如此。的確有 Larry、Guido、Linus 這樣的人物,但其實任何一個專案,都需要各方面具有不同才能的人加入。
重要的是,無論您有多聰明,都要保持謙虛。因為只有謙虛的人,才能以開放的態度面對其他人,學會用新方法來做事。謙遜的心態,讓您能歡迎其他人加入您的專案。相反的,抱持驕傲自大的態度,就等於是在跟其他人說:「我不需要你們,我用自己的方法做事就夠了。」
也是因為謙遜,我們才能歡迎各種性別、各種文化的人加入社群,為開源軟體帶來多元而豐富的人才。
就像各個國家有不同的語言和文化一樣,相同的多元性,也體現在各式各樣的開源專案裡。舉例來說,Linux 社群、Perl 社群、Ruby 社群和 Python 社群,都各自用獨特的方式來交流合作。
只要我們懷著一顆謙卑的心,就可以看到自己專案所屬的社群並不是唯一的途徑,也才能夠欣賞其他社群裡的合作方式。
另外,做開源專案並不只是享受樂趣而已。樂趣當然是有,但同時也有責任。當您承諾參與一個專案時,您是讓雙肩扛上了重量。這是件好事,因為責任能讓我們進步,變成更好的人。
但是人生中還有其他的事情,像是您的伴侶、父母、孩子、職業等等。對於開源專案,我們可能會承擔一段時間的責任,但到了某天,我們可能會發現,自己不能再負起那麼多的責任了。
我們要意識到這是一個循環。一開始我們加入社群,然後逐漸負起越來越多的責任。但當人生到達某個階段之後,您總會逐漸減少所負的責任。這個過程完全是自然的,而且在專案的生命週期裡一定會發生。
所以我們不妨想想:「哪天我無法再付出那麼多心力的時候,誰來繼續我的工作呢?」
為了確保其他人能繼續我們的工作,我們可以創造出某種持續前進的過程:盡力教導與分享我們所學到的一切,同時也向其他人學習更多的事物。這是一個不斷吸收與分享知識的過程。
最後,當您在為開源工作的時候,請保持快樂吧,讓您的臉上帶著笑容,讓其他人分享您的喜悅!因為正是這種樂趣給予我們力量,讓我們能創造出偉大的事物。
您現在更快樂了嗎?:-)
(這是 Day 24 – Yule the Ancient Troll-tide Carol 的中譯,作者是 Larry Wall。)
(感謝康寧馨斧正譯文。)
你在耶誕夜拆開禮物,發現了一面鏡子,裡頭可以看到自己。
鏡面上刻鑄一行聲明:
鏡子裡的主體,實際上比看起來近。
但它一點兒也不像汽車後視鏡。看來雖然脆弱,可結實得很,兩歲的你再怎麼費勁,也弄不破它。
「啥?鏡子裡怎麼會出現以前的我?」
你把鏡子扳來扳去,裡面不祇出現了你過去的尷尬身影,還有你未來可能成為的模樣,好的壞的都有。
「哇!」
突然一陣五內翻騰,天旋地轉後,你看著鏡子,但,不是從外頭看著鏡面,而是從鏡子裡朝外看:除了你的各個倒影之外,還出現了許多人,從鏡外看著你。你是他們過去或未來的模樣。
顯然,出於一場意外,你被吸進了超維鏡裡——現在你是 Perl 6 社群的一員了。
我們(包括你)獻給你(包括我們)的禮物,就是我們夢想中自己的模樣。
換句話說,你被黑克了!甚至,是被博格了!不過,也許你會試著喜歡這件事。
Perl 不祇是技術,也是一種文化:Perl 是一套鼓勵技術黑克的技術,也是一種鼓勵文化黑克的文化。
Perl 歷史上的第一個黑克,就是「捐出實作程式,交由社群維護」。之後還有許多別的黑克,大的小的都有。其中有些黑克也出現在你持有的鏡子裡。呃,我是說持有你的鏡子裡。
第二個文化大黑克則顛覆了 Unix 文化裡的還原論思想,讓它也能適用在還原論之外的情況。
「採用雙重授權」是第三個文化黑克,讓企業和 FSF 都能接受 Perl。
還有個眾所周知的黑克:寫一本電腦書,讓它不僅有料,而且還很有趣!
但這些不過是粗淺的黑克而已。Perl 文化的深層黑克,是讓社群能夠自我引導,自己黑克自己,遞迴建構、日新又新。(通常,是往好的方向走。)
Perl 6 也延續了「Positive Trolling」的優良傳統。在古英語裡,Troll 的意思是「歡唱」,好比說「Troll the ancient yuletide carol」。我們的「Perl 6 耶誕倒數」活動,正是這類歡唱的好例子。(它也是遞迴式社群自我建構的模範之一。)
還有許多別的例子。
好比說,打開 perl6.org 的首頁,立刻就能看到幾項文化黑克。最醒目的,自然是我們的蝴蝶標誌「Camelia」。
她透過圖象和文字,來為文化黑克發聲。圖象在說:
從反面來說:
我們發現 Camelia 是很有用的文化黑克:從它挑起的情緒反應,我們可以辨認出想偷走耶誕節的搗蛋鬼是哪些人。
凡是社群,都有新加入的成員,其中難免有些人態度惡劣。像 Camelia 這樣鮮明的攻擊目標,往往讓這些人忍不住做出一些白目的行為,就像是在說:「嗨,我是小白。擁抱我吧。」
這裡可以看到 Perl 6 社群的另一項文化黑克:我們擁抱小白。(在某個限度以內。)
Camelia 用文字說得很清楚:「要想加入我們社群,你必須有能力善待各種不同的人。」小白也是人,所以我們都有善待小白的能力。(如果我們對某位小白不好,那是因為我們決定要對他不好,不是因為我們無能。)
我們社群裡有些成員,當年也曾經是小白出身。就像先前提到的那面超維鏡一樣,我們在結伴同行的生命旅程裡,都從彼此身上看到自己的影子。
我們大多希望未來能成為更好的人,也願意承認自己過去的種種缺失。但世界上仍有不少還沒立志向善的人,包括許多小白在內。有些小白確實心術不正,有些只是還沒學到怎樣與人好好相處而已。
因此,當我們說「擁抱小白」時,在操作上的意思是這樣的:當你加入我們的社群時,我們並不介意你當下的狀態有多麼白目。我們在意的,是你的一階和二階導數。
為了讓我們有時間來做差分,我們通常會借力使力、施展語言合氣道,使你有機會表達出更深層的渴望,而你或許只覺得是在折磨我們而已。
如果你立身不正,但願意積極向上,我們一定留住你,直到你改過遷善為止。你想當個好人。我們會幫助你。
如果你立身不正,也不願積極向上,那我們會看看你有沒有逐漸改善的跡象,也就是你的加速度是否為正。你還不想變成好人,但或許你會想變成「想變成好人」的人。這我們可能也幫得上忙。只要保持正向加速度,最後,速度和位置總是會跟上的。
總之,社群裡確實有搗蛋鬼,但有些搗蛋鬼是會懺悔的。我們想給他們一個機會。因此,有時候當搗蛋鬼來偷禮物時,我們只是站在一旁唱歌。
但是,有些搗蛋鬼就是死不悔改。
我們有沒有提醒過你,Camelia 的翅膀展開有三米長,而且她喜歡抓住死不悔改的搗蛋鬼、吸出他們的腦漿?不僅如此,幼蟲期的 Camelia 是隻駱駝,所以,她也會噴口水。你絕對、絕對不會想要嘗到被 Camelia 吸出腦漿,再噴出腦漿的滋味。
話說回來,大多數人的腦子並不需要吸或噴,只需要好好洗洗。
人們一旦領略了 Perl 的元哲學,便會發現,探索技術和文化的融合是一場多麼華麗的冒險。相形之下,惹人討厭的搗蛋行徑簡直是無聊透了,也簡單透了。
我們希望你喜歡這面新的超維鏡,也希望你喜歡曾享用過(或即將享用)的這二十四篇文章。
祝你有個璀璨的倒數,加入我們華麗的冒險。
Pugs 帶來了決定性的變化。隨著唐鳳的「非官方」Perl 6 實作完成度愈來愈高,不少人也開始發展自己的「小規模」實作。
從 2005 年到今天,有十來個「小規模」實作陸續出現,其中不少到現在仍在持續開發。其中有些是為了探索 Perl 6 某部份的設計,也有的是想要實作出整個語言。
(我稱它們為「小規模」,是因為開發者人數較少,使用者也不多的緣故。)
從 Pugs 登場到離場的這兩年多裡,在 Parrot 上實作 Perl 6 的腳步並未稍停。但因為當時 Parrot 還不夠成熟,想要慢慢搭建起編譯器所需的工具鏈,勢必得花上許多時間。
早在 2005 年時,Patrick Michaud 就已著手在 Parrot 上實作文法引擎(PGE)及編譯器工具集(PCT)。到了 2007 年,Patrick 終於得以開始正式實作 Perl 6;這個計劃在 2008 年初命名為 Rakudo(樂土)。
老實說,我是在它取名為「樂土」之後,纔注意到這個計劃的。
Patrick 的願景是這樣的:一個完整的 Perl 6 實作,首先需要有良好的 Perl 6 文法引擎,以及完善的的編譯器工具鏈作為基礎。在完成這兩項計劃之後,Patrick 才轉而開發實際的 Perl 6 編譯器和執行環境。
當時,一位名叫 Jonathan Worthington 的強人不慎答應 Patrick,要在 Rakudo 上實作 Junction(連接值)功能。(後來他纔發現,要實作連接值,得先實作多重分派,而這又得先實作型別系統,所以又得先完成大部份的物件導向系統... XD)
於是在 2008 上半年,Patrick 和 Jonathan 齊心協力,為 Rakudo 寫出了一個接一個的功能。
雖然 Rakudo 並不像唐鳳開發 Pugs 時那樣輕鬆寫意,而且早期版本實作的功能通常漏洞百出,但它確實讓 Perl 6 社群再度活躍起來。
在相對完整但發展停滯的 Pugs 計劃,與緩慢但穩定地追上 Pugs 的 Rakudo 計劃之間,我逐漸把注意力轉向後者。
2008 年的夏天過得很快;我和 viklund 合作,用當時還乳臭未乾的 Rakudo 寫一套圍紀引擎(純粹為了好玩而已)。
我們對自己說,如果竟然能寫出來,那我們就到 YAPC::EU 會議上,以它為主題來一場閃電演講。
嗯,最後我們真的寫出來了,也真的到 YAPC::EU 講了一場。與會者聽到有人能用 Perl 6 寫網站程式,反應十分熱烈,我們也很開心。
可是,中間我們繞了多大的彎,避開了多少還沒實作的功能,又發現了多少瑕疵啊!
而且,既然這是個秘密計劃,我們就不能在 #perl6 上直接貼出有問題的程式。要回報瑕疵之前,我們得先把代碼清理到看不出和圍紀有任何關係纔行。在那段時間裡,我學會了在瑕疵回報上打高爾夫(Golfing,壓縮字數)的價值。
那年夏天,我提交了許多瑕疵回報,每份的代碼都清理過了。就像小孩子收集瓶蓋一樣,我開始熱衷於此。
當時 Rakudo 的瑕疵不少。有一陣子,瑕疵似乎無所不在。這不能怪 Patrick 和 Jonathan;他們一直都很盡責。但任何專案都要經歷實地運用的考驗,而 viklund 和我恰好是首先拿 Rakudo 來用的人。
實地測試和回報瑕疵成了我的嗜好,驅使我不斷重複著「拿 Rakudo 做些新鮮事」、「看 Rakudo 爆炸」、「寫瑕疵報告」的無盡迴圈。
能脫離粉絲階段,正式參與開發,這讓我非常高興。日後我寫了更多 Perl 6 代碼,甚至還拿到了 Rakudo 的提交權... 但我想我會一直當那個「專門提瑕疵報告的傢伙」吧。
目前頻道上的幽默以大笑貓(lolcat)、奇特的顏文字,以及其他時下的網路流行語彙為主。頻道上的氛圍輕鬆有趣;大笑貓和編譯器內核開發的對比,時常令人耳目一新。
<pmichaud> 早安, #perl6 <jnthn> 早, pmichaud <PerlJam> pm 你好 <colomon> o/ <mathw> o/ pmichaud <moritz_> /o/ <mathw> \o\ <jnthn> \o/ |\o/| o< /o\ <jnthn> ;-) <mathw> 啊啊啊啊 * mathw 躲起來 <okeCay> o/\o !
隨著 Rakudo 漸趨成熟,「綱要」也隨之作出修訂。也許有人覺得這很可怕。要怎樣去學一門不斷變化的語言呢?為什麼不讓規範文件確定下來呢?
我個人的想法是:我不希望語言規範被「鎖定」或「凍結」住,因為目前的修訂已經愈來愈小,大都是為了修正 Rakudo 等實作回報出的問題。
雖然 Perl 6 的規格改動幅度超過我所知的其他語言,但另一方面,它也一天天變得更加穩定。我們稱它為「漩渦式開發模型」,實作和規範雖然相互影響,但最終仍是往同一個單點收歛。
相對於某些 IRC 頻道的粗暴文化,#perl6 可說是網路上最親切的地方之一。我們花非常多的時間回答新手的問題、幫忙修正語法錯誤、並為訪客和開發團隊釐清各式術語及設計方針。我們互相幫忙看代碼和網誌文章,讓頻道上洋溢著彼此尊重和互相照顧的感覺。
今天的 #perl6 幾乎是「日不落頻道」,擁有來自全球各地的人積極參與。我們不僅覺得這裡有個非常酷、足以向世界展示的語言,也很自豪於 Perl 6 文化的良好素質。
2008 年以來,Rakudo 逐漸領先其他實作,完成度甚至超越了 Pugs。目前絕大多數的算符和控制結構都已完工,更有強大的正規表示式與文法引擎(感謝 Patrick!)以及優秀的物件導向、多重分派支援(感謝 Jonathan!),許多其他功能也已充份實作。
我們還有許多「小規模」的 Perl 6 實作,幫忙推動「綱要」發展和探索實作策略。但投注於 Rakudo 開發的人力,確實遠大於其他實作。Rakudo 每月釋出新版的工作人員名單,通常都在二三十人以上。
重新回到「Perl 6 每天都更近一些」的日子真好。
我仍然每天回報一則 Rakudo 的瑕疵,但通常是關於尚未實作的進階語言特性,而不是缺少什麼常用的功能。
2009 年至今,Rakudo 成功完成了幾項龐大的重構任務。首先是文法系統,隨後其他各元件也都分別重新寫過。
對開發者來說,這些小計劃統合成了所謂的「Rakudo 大重構」。
對於外界來說,這就是即將正式發表的 Rakudo Star,「樂土之星」。