顯示具有 非營利組織 標籤的文章。 顯示所有文章
顯示具有 非營利組織 標籤的文章。 顯示所有文章

2013/2/1

菁英政治

從 Open Source 界不願承認的九件事一文中,引一段有意思的:

More often, though, it is heavily qualified. In many projects, documentation writers or artists are less influential than programmers. Often, who you know can influence whether your contributions are accepted as much as the actually quality of your work.

Similarly, the famous are more likely to influence decision-making than the rank and file, regardless of what they have done recently. People like Mark Shuttleworth or corporations like Google can buy their way to influence. Community projects can find their governing bodies dominated by their corporate sponsors, as has usually been the case with Fedora. Although meritocracy is the ideal, it is almost never the sole practice.

不敢說自己看得很多,不過以上大部份都正確。很久以前,我記得聽人說過 Open Source 的環境是菁英政治而非純然民主;Mitchell Baker 也曾說過 Mozilla 的文化上應該是 Earned authority;或說我自己在關於社群式管理的心得隨筆也描述過在程式碼上貢獻與應允者間的關係往來。

「打馬碼的最大」是這類社群的常見現象,我們也經常低估文件、繪圖者的貢獻程度。這有點像一間公司獨尊業務的作法,只有有「營收產出」的能拿到最豐碩的果實,而忽略其他人在輔助支援上的努力。這點應該是我們致力改善的,如果都像 TonyQ 一樣把視覺設計視為心中的神或許不壞 :P

有名的人也確實比較有影響力,不過這沒什麼不好。以瞎透舞姿先生來說,他的「有名」其來有自,必然也經過了許多努力而生 -- 生下來就有名的人不多見,在這個社群內更不太發生,而無論他做了什麼、也都會對他後續的影響力產生影響。又,在每個環境裡的「有名」,也不見得會能夠被帶到另一個環境裡。如果在商普界知名的 Mr. xxxxx 們來談 Open Source,我們應該會請他講中文。因此這份「有名」事實上也是 earned authority 的代表,而我們也不愛單純由 given 而來的權力。

至於贊助商主宰,嗯,慣於用資源而非道理來控制人的群體充斥我們周圍,我自己仍然會記得即使是這些人也仍是「社群」的一份子,也代表著部份的聲音,應獲得一定尊重(說到底資源的贊助也屬於一種貢獻啊);又,不喜歡原也不必勉強,你總可以選擇自己不被那些勢力左右,就開個分支或離開吧。

是以,我還是抱持樂觀的態度看這些缺失。會向著更好的地方去,中途的曲折只是必然要來的墊背。

2012/9/6

COSCUP 2012 - 改變與檢討 (1) 交誼廳、Workshop、接駁車

檢討的部份或許檢討會上可以再補充,先列一些我們嘗試的改變,並提一些個人的看法 -- 如同沒有人能夠代表社群一般,即使作為 COSCUP 2012 的總召,我仍沒有意思在這裡代表整個籌辦團隊發言。以下的紀錄,或可說是分享,但更多其實是為以後的自己記錄。為免富奸上身,寫幾點我就貼一篇,就算真的上身了至少還有產出...

取消交誼廳議程

IMG_0149

除了行政部份「一切從簡、降低負擔」這種與會者看不見的變化之外(之後會討論,不富奸的話),取消交誼廳議程或許是最早決定的改變,源自於 COSCUP 裡有幾年的「交誼廳其實不適合放議程」爭議。去年已經稍有改變,在第二天改以 Unconference 的方式進行而只預排了一天議程,今年我跟議程組長打開始就希望讓交誼廳回到「交誼」性質,讓想休息的人有個地方可以去。

實際狀況裡,或許因為宣傳不力、或者在中研院的場地裡空一間出來隨便大家搞仍是新機制,總之「交誼」的效果似乎不佳。又,今年 COSCUP 很幸運的逃過颱風,而且居然一滴雨也沒下,於是交誼廳當然也不會有以前發生過的積水問題。這倒無損我認為應該尋求別的方式來消化場地總人數的想法。

說「場地總人數」,因為中研院人文館單論座位,其實無論如何是無法容納上千人的會議。取消交誼廳會讓這個問題更嚴重,所以一方面第二天仍有 Unconference,二方面我們需要多一些東西來幫忙消化人,這就是下一項「Workshop」。總地來說,取消交誼廳議程其實並不那麼不可行,以中研院的場地對照單日會眾人數近千人但有兩百左右在會議室外(工作人員、攤位人員)來說,塞一下還是進得去的。

增加 Workshop

COSCUP 2012 Day 2

因應取消交誼廳,我們搬出了另一個很久以前也討論過的東西:Workshop。在以前的討論裡,是希望舉辦 Workshop 將 COSCUP 變成一個三天的研討會:第一天是 Workshop,接著兩天是原本 COSCUP 研討會型式的會議,今年既然是要處理人數問題,那自然就是一起辦。

在原來的規劃上,COSCUP 主辦團隊只負責場地,與最基本的電力與網路協助,其他在這三小時裡要搞什麼,就全部交給審核通過的社群搞。某種程度上,你或許也可以把它視為外包給某個社群的議程區段 -- 事實上 JuluOSDev 的方式,就很像理想中的狀況,也確實吸引很多聽眾。不過由於第一次辦,分工上沒討論清楚讓大家忙得團團轉,有了這次的經驗,下次再明白定一下分工(大聲地說出「COSCUP 只負責場地,報到及現場其他工作人員等請自行處理或另外提出需求)應該可以跑得很順。

「Workshop 主辦人是否具備講師資格」也是一項爭議,我的定義裡是不算:這三小時基本上就是讓接手的社群自己決定要怎麼搞,你可以像 Fire.app 一樣就是一個講師從頭到尾,也可以像 Julu OS 一樣一堆人輪番上陣;或者可以是一個人主講、另一堆人協助與會者動手做,也當然可以就直接作為相互討論特定主題的園地、只有協助秩序的「主持」而沒有講師。由於型式太多樣,我們也不願多做限制,那相對來講就不將「COSCUP 講師」資格賦予講者。我們看到 Julu OS 自己額外做了 T-shirt 鼓勵分享者,是很好的範例。或許下次雖然 Workshop 講者仍不直接賦與 COSCUP 講師相關回饋,但可提供主辦社群定額 VIP 及兩個講者晚宴出席名額,可以平衡一下,也避免「Workshop 講師比較不重要」的誤會 -- 單純是因為定義不同而已。

不過為了確保 Workshop 人數,先前採獨立招生的方式讓我們吃了點苦頭,最後的決定「讓 Workshop 參與者同時擁有 COSCUP 入場資格」也有不少意見。如果再來一次,我想我會選擇回到「讓 Workshop 跟 COSCUP 報名完全脫勾」的想法,並且在市區另開戰場、於周五舉辦。這個想法優劣並存,讓下一屆的人去評估得失吧。以前的 Workshop 討論裡,其實還有「Workshop 就獨立收費」的想法存在過,不過不在這次的考量中,就不多談。

這是我們第一次辦 Workshop,招待不週請多包涵,也歡迎留下你的想法、甚至搶先表達明年當工作人員的意願 :P

取消去程接駁車

很多人以為這次 COSCUP 取消一大堆東西是因為經費不足,其實反而是先為了要節省資源降低負擔,才決定多所限制。這包括設立工作人員員額制度(很神奇吧,想當 COSCUP 志工也會有名額有限的一天...)、取消二籌見面會議改以兩次線上討論取代、降低會前會與檢討會人員餐費等行政項目,也包括取消上午點心、減少便當數(這兩個加起來有不良影響,容後討論),以及這一段要討論的「取消去程接駁車」等影響會眾的事情。

第一班接駁車

COSCUP 從在中研院辦的 2010 年起,首開先例設置了「接駁車」,方便當時只能從捷運南港站來的會眾前往中研院,到後來其他研討會也多有跟進。過去成效不算差,那這次為什麼要取消?原先是我在 PyCon Taiwan 時跟一群在辦研討會的人提到,從南港展覽館到中研院的車超多,似乎沒那麼必要提供接駁車,且我也希望由會眾自己負擔一些費用。小朱提出一個看法:早上真的有點懶得走中研院門口到人文館的那段路,沒來過的人面對這段路也怕迷失。於是大家討論出計程車共乘是個好方法:每個人分 25 塊並不是多大的負擔,不用等太久、滿四人就走的方式也比接駁車好一點,另外我個人也奢望能造成一點額外的作用 - 本來開源人們就是要拿出家裡的青菜煮石頭湯,鼓勵共乘讓大家一起坐小黃也增加認識同好的機會。於是,在公開討論區發表取得共識後,決定取消早上到會場的接駁車、改以配套機制鼓勵計程車共乘。

這個作法似乎招來了一些抱怨,不過大致上來說接受度也還不錯。兩天的駐點時間(上午八點起的一個小時)都有約 30 班次小黃前往中研院,保守推估兩天各有 90 人以上搭乘計程車前往會場,我個人覺得下次還可以比照辦理。

那麼晚上的接駁車何以不一併取消?一方面要叫計程車進來人文館並不方便,二方面在夜裡讓不熟悉場地的會眾從人文館走到中研院門口好像也不太保險,有鑑於安全與方便,仍然提供晚間接駁車。是說,大家在第二天結束的時候不太捧場,據說坐不滿一班?或許第二天晚間的接駁車還可以再減少班次避免浪費。


這三項基本上結果都還算可接受,或甚至可以說是好的。下一篇再來談有不良影響的「點心減量」 + 「便當限量」... 不富奸的話。

2012/8/19

Chat with Aaron Seigo

其實 Social 不是我擅長的事情,每每要耗掉相當多精神,所以如果能夠避免、我就盡量避免,加上自己英文也不是很好,所以雖然這次作為 COSCUP 的主辦,我沒什麼跟國外的講者打交道。但因為一點意外,我試著跟 Aaron Seigo 找點話題來聊(不然,他都在講者休息室裡打電動 XD),沒想到卻有一些想法讓我不得不記下。

Aaron 在他的 Keynote 裡提到社群的組合,剛好跟我前陣子想的東西很近似。我的想法裡,雖然有些剛接觸的人可能會覺得同個「社群」的人就是該整齊劃一地朝一個地方前進,但事實上這種事情從來沒發生過:社群裡的每個個體,仍是十足十的獨立個體,有時他們向著同個方向前進,有時各自集結各自努力,有時又散落一地叫不醒。翻譯 Code Rush 的時候,片裡有提到,管理一群程式設計師就像放牧一群貓 -- 你喜歡他們的獨特之處而集結他們,但他們並不總喜歡向著同一個方向走。

於是我問他對於社群與商業組織(例如,C 社跟 U 作業系統、M 社跟 F 瀏覽器等)之間合作組織的看法,他提了幾個有趣的點,我筆記一下:

  • 傳統管理會希望從趨勢裡去預測結果,不過志工團體你基本無法預測結果。並不會有「做了某是,就讓某幾個 patch 被誰修掉」這麼好的事情,畢竟他們都是志工。你真的要求到這麼精準,拿錢雇人來換。
  • 有很多時候社群的行為,在傳統管理的視角裡會覺得一團混亂,但並不見得。以氣球來比喻,你根本無法控制裡面氣體分子的運動,但整體就是那個形狀。
  • 以他的經驗來說,比較有效的方式是衡量做完的事情,然後找出規律、用以作為下次的目標。若達不到目標,再修即可(不必變成是非有不可的 KPI 那種形式)
  • 有些努力還是可以做的。

先記這樣,下一篇希望是 COSCUP 2012 的些許感想。

2012/7/31

出力、出錢

註記一下我的想法。我記得以前好像在哪個地方說過,但總之註記一下。

我覺得志工團體出了力就要追求不必出錢。讓有錢無力的人出錢、鼓勵有力無錢的出力,比較能促進正循環,將「參與者」的範圍擴到最大。如果有人有力又有錢,想兩個都出呢?倒無不可,只是支出的費用都要詳實記載,避免日後有人錯估情勢。

假設阿鴻為了辦 Redfox Party,自己出了點心費,而只跟夥伴說「反正點心費我出就對了」。出錢並無不可,只要心甘情願行有餘力就行,但沒將實際花費講明,其他夥伴就錯失認識「辦這樣一個活動,食物要花多少錢」的機會,也無法正確評估花這些錢是否值得。

又,如果錢來得太容易(意義上有如「有富爸爸」),很容易失去控管的意識。我很希望我們的社群每個人都對資源的控管與流動有所意識,金錢也是、時間也是,這樣的我們才能在兵源薄弱的狀況下,能人所不能。平衡才是我們最終的挑戰。

2011/10/24

關於社群式管理的心得隨筆

本來今天打算來 MozTW Lab 整理一下週末討論的活動定位,不過今天在公車上看的書 -- 「約耳續談軟體」,裡面頭幾篇跟管理相關的文章,實在與我對社群的看法太也相近,決定先把一些東西打起來分享給大家。第四章的第一句話就是作為社群協調者要面對的、最重要的問題:「如果你想領導一個團隊、一家公司、一支軍隊,甚至是一個國家,首要問題就是讓大家都朝著同一個方向前進。這話說得很客氣,意思就是『讓別人做你想要的事』。」

正如大家所知,Open Source 程式貢獻者本質上都是做爽的。記得以前 XDite 也曾經提過類似的話:這群被視為「愛分享」的人不見得真的那麼愛分享,許多情形下分享出去的東西都只是自己已經獲得利益後的殘渣。我們撰寫程式許多時候是為了讓自己用更好的軟體,至於別人怎麼用那些成果,反正我們也不太介意 -- 我們的問題已經解決了。當然,某些人更會因為基於「我也踏在別人的肩膀上,應該回饋」的心情,把這些想法更提升到道德的層次,但這畢竟不是多數人。

所以,我覺得志工就是不能要求(註)的 -- 要用什麼當作這份「要求」的誘因?用約耳說的「指揮與控制管理法」,以嚴厲的恐懼讓大家能以最快的速度反應一致嗎?還是「經濟學 101 管理法」,用獎勵代替懲罰,鼓勵這群人往一致的目標前進?書裡提到,「軍隊裡會使用指揮與控制的方法,是因為沒有別的辦法能讓 18 歲青年衝過地雷區,並不是認為在各種狀況下,這都是最好的管理方法」;又說經濟學101管理法的大問題「就是內在動機會被外在動機取代」。我想這兩種方法也就是所謂的棒子與胡蘿蔔,一則脅之以威,另一則誘之以利。

我相信 Open Source 專案裡是這樣的:你有意見就送補綴(patch),讓比較有信譽、受信任的人審閱程式碼。審過以後,補綴就會被收進主幹裡,成為之後新軟體的一部分,皆大歡喜。而萬一審不過,或許代表程式寫得不夠好(例如不符合 coding style,這會讓別人日後維護非常麻煩),也還有另一種可能是解法不被認同。一旦兩人在程式解法上出現爭議,這時雙方一般會開始辯論可行作法,接著若仍無法取得審閱者的同意,則要不就不補,要不就把這套程式直接搬回家打上自己的補綴、出自己的版本。這套作法裡,審閱者跟補綴者並沒有層級上的差別,審閱者只是把自己工作做好,而補綴者也可以選擇自己用行動(把程式搬回家自己出一版)來證明所持方案的可行性。

那麼審閱者若真的希望補綴者能繼續投入貢獻(我相信每個居於協調人的角色都會把這件事情視為使命),該怎麼「讓別人做你想要的事」?我想「利誘」還是正確的作法,不過這邊要用以誘之的「利」我想並不真指錢財禮品等的東西,更重要的是自我動機,這也就是約耳提的認同管理法。審閱者站在「程式上游」(mainstream)的角度,能做的就是說服補綴者也認同自己的方法即使不是最佳、也是比較能被接受的作法。這麼一來,補綴者才可能願意以審閱者的論調貢獻重寫後的程式。由於補綴者是志工,並沒有人可以用扣薪水的方式「逼迫」他何時要把問題解決,也沒人可以用加薪水的方式「獎勵」他把問題解決,那麼只能讓他自己也接受「這種方式是這個時間點上最可行的解決方案」才行。

我們當然可以「要求」補綴者照自己的作法走,但在過程中必然含有非常多的溝通與討論,而到最後當某一方被說服,也就不會是「要求」了,因為被說服的那方已然認同了對方的思考。做事也是一樣的。希望某件事情改變作法,就動手參與;覺得「審閱者」或「補綴者」做得不對,就以開放態度盡力溝通,以求讓對方能夠繼續(在這個問題、或其他方面)貢獻心力。

那我怎麼知道你是更好的?請證明。此時你是審閱者,如果我送的補綴你不想接,請證明你的想法即使不是最佳、也是比較能被接受的作法。否則,我可以不做。

註:「要求」的定義或有不同,我這邊採取是以最壞的「我是對的,請照我的方法做」這種態度行事的作為。當然你可以說這個詞非常中性,我同意,只是我也相信每個人的感受會有差異、也不真的都能這麼邏輯分明地就事論事。

2010/8/26

社群?

也是紀錄一下對話。

社群的英文是「Community」,中國譯為「社區」,這個詞也確實從地理概念下手比較容易理解:住在某個區域範圍的人都是那個「社區」的一份子,無論他多喜歡或不喜歡鄰居、他會說「我住大東夜市旁」、「我是左營人」,那類的。他們都是這個地理社區的成員,也(大多)會關心衍生的相關事情,例如巷口開了一家小七、或者垃圾車幾點會到等等。

所以換到虛擬的環境來,社群(或社區,看你的翻譯)也必然是共享某些屬性的人。這個「屬性」可能是使用的工具、可能是興趣、可能(仍舊)是地理區域、可能是對某件事情的看法。社群是自然形成的,那些所謂「建立社群」的事情,大部分(if not all)是把原本已經有的一群人兜起來,再加以發展。例如說 TOSSUG 是「台北開放原始碼軟體使用者社群」,在還沒有這個名字之前台北也是有一群使用 FLOSS 的人,他們難道是因為 TOSSUG 建立所以一下子蹦出來的嗎?當然不是。確實,有些人會因為這個社群有個名字、有集體辦些活動,所以被吸引而萌發興趣、「加入」社群,但若討論「創立」這件事情,我想更多是創立「組織」,不會是創立「社群」。

如果其實沒什麼「建立社群」這種事情,那麼我們談的「建立」、或者一旦這群人有了個名字,那其實早就已經進入了組織階段。這個「組織」不必然是社團法人或其他有階級的型態,但如果會仰賴特定一小組人來號招,「階級」已經自然形成。其實這也很正常,沒什麼好擔心的。一群小孩子玩在一起,也必然有個「孩子王」,而他們的關係也不一定是上對下,只是某些人講的話就是會比較有人聽、或者有些人就是想要多做點事情,很正常。

孩子王會不會覺得自己是這群朋友間的 leader?我想不盡然。我知道因為個性關係,朋友經常都願意了解我的想法,不過我並不預期他們就會照著我講的做,從來也不會這麼預期。

有空再整理。

2010/6/3

聊網路非營利組織社群營運 (1)

昨天下午難得有機會再跟 Saint 閒聊一些與 Mozilla 相關的事情。或許又經過了一些時日,我終於也能再次精鍊我的想法,於是終於覺得她臉上的疑問減少很多很多,當然也可能因為鐙鐙的用語讓她稍微進入了這個世界,所以我能再更深地描述我的觀點。無論如何,對談的某些問答紀錄,混合晚上與鐙鐙再聊過的事情,希望可以分幾次整理一下,於是這是第一次:


問:企劃總需要一個目的,這個組織的目的到底是什麼?

答:其實在這個組織活動了將近八年,我對於 Mozilla 作為一個非營利組織、而非單純的「開放源碼專案」有日漸加深的認同感。Mozilla,乃至於 MozTW,真正該努力要努力的不是讓 Firefox 這個瀏覽器市佔率極大化,而是如其「使命」所說的,維護網路上的選擇與創新。不過當然,「使命」這種東西,不是能直來直往地對一般使用者說明的 -- 對於這些使用者來說,網路從來都極富創新、也有不少選擇 -- 雖然他們這麼想確實忽略了很多事情,但如果了解他們怎麼想,就能明白直接講根本不可能有用。我們以 Firefox 及其他軟體提供使用者選擇,致力促使網際網路上的良性競爭,同時確保「創新」這件事情能因為保持競爭而持續下去,讓使用者能擁有更好的網路。

因為真正的「目的」不在市佔率,所以有時我甚至會覺得,某個活動能增加多少 Firefox 使用者,隨緣就好。

附帶一提:我覺得 Mozilla 很巧妙地選擇了「平衡」這件事情(維護網路選擇與創新,都屬於「平衡」)作為使命,因為平衡並不是達到了以後就可以不用繼續努力的,反而在求得平衡後還得致力維持平衡才行,這蠻可以確保我們總是有該努力的目標、且方向不會變動。好的非營利組織使命宣言,應當如此。


問:「隨緣就好」,那效率問題呢?

答:其實就我的角度來講,讓社群成員做事情做得開心,並且願意再投入下一次,是更該關心的部份。志工不支薪參與,為的就是要「爽」。這個「爽」有很多可能,或許只是因為跟一群朋友一起做事就是開心、或許是可以提高名望、或許是可以讓自己愛用的軟體變得更好、或許是追求成就感等等,但無論如何,不爽是沒辦法持續的。

而關於我們想推廣的終極目標「使命宣言」部份,其實除了難以對一般消費者描述外,甚至難以對部份既有的社群成員描述。有的人只是要讓自己的不便變得方便,網路開放與否他完全不關心;也有人只關心技術發展方向,「技術會不會因為獨裁而失去創新動機」這個層面,他也不擔心。當然,也有些夥伴才剛加入而已,一下把這些議題丟到他頭上,只怕是難以吸收。

所以首先為了「做得爽」,我個人可以放棄效率。

不過與一般組織合作時會有問題,所以這類時候我的作法是自己接一下類似專案管理的角色,找好願意協助的兵馬、大家簽下「這個專案完全照我的意思進行」的賣身契之後,我就可以跟其他組織用他們願意的方式溝通。

與一般組織相較,我們這類社群在做推廣企劃時很像散兵在打游擊戰,而一般組織則是玩組織團體戰。

又,既然談到效率,總要有個評量方法。開源組織的推廣評量方式是什麼呢?我個人認為現在強烈依賴 SNS 的我們,要評量很難。如同我們家的小莎,什麼好友粉絲幾個人啦、每天發幾噗啦都絕不會是決定性的價值,那麼她的價值如何判斷?我與一些朋友,包括在公關公司工作的老同學討論過這個問題,我想目前應該是沒有好方法。商業組織最後可能可以用營收來算,不巧我們又沒有「營收」這件事情,那就...

總之我最在意的是社群成員願不願意因為做得開心而留下來再做一次,第二次、第三次之後,慢慢感覺這個組織想要做的是什麼,然後從任務的接收者成為規劃者 -- 因為那時他已經懂了,可以依據自己的判斷決定行為,我就不用解釋太多。

當然,偶爾還是會有些不見得那麼熟悉使命的夥伴想嘗試規劃帶兵,我覺得就開放而行即可,如果吸引得到兵來帶,就有存在的價值,有何不可?

2010/5/20

Breaking: Download Firefox nightly and try WebM!

如果你是個關心網路影音發展的開發者,那麼快去下載今天的 Firefox nightly 吧。

方才在 Google I/O 上,Google 終於確實做了大家期待他做的事情:開放 OGG Theora 的同門師弟「VP8」的編碼專利,成立 WebM 專案。目前有包括 Mozilla、Opera 以及想當然爾會相挺 Google 的一些軟硬體廠商為這項計畫站台,這很可能一舉終結目前 HTML 5 中 VIDEO 標籤的編碼大戰。

YouTube 已經開始提供 WebM 的 HTML5 版,首先以支援 WebM 的瀏覽器(例如剛剛請你快點去下載的 Firefox nightly trunk)開啟 www.youtube.com/html5 點選「Join HTML5 Beta」,搜尋影片的時候在網址後加上「&webm=1」即可。目前我還沒辦法測出來,但相信很快就可以玩玩。接下來等 WebM 的硬解晶片上場,我想這場小戰役就可以宣告終結了。財大氣粗有財大氣粗的玩法,看過富豪刑事的人一定很了解啊!

不過還是真的要說句感謝咕狗大神,總算我們可以確保網路持續開放。

2010/4/21

台北的 MozTW Lab,都在幹麼?

集合一下回答 Toomore 的 tweets,整理成這篇:


台北這邊的 Lab 從來都不是為了有什麼目標或者要作什麼事情而聚的:進「研究室」做各自的事,有新消息聊、有困難找人討論,但不需要有統一的目標。

事實上,本來 MozTW Lab 最原始的規劃,就是刻意地不要有集中式的目標。大家不出來見面的理由,有一部分是「有事情要忙」,但其實一起做事可能更容易解決問題,不如來一起忙好了?有忙也可以互幫。

那所以到底為什麼要來?或許你可能經常需要別人的意見、或者你只是想跟大家聊聊天、或者東西吃不完知道那邊有人可以分,啥的。當然,你也可以當成來上 MozTW 的班,不過至少原本「我自己」的設計就是「隨便你」,不是一定要如何。

強調「我自己」,因為那是我在做事的方法,而別人怎麼做,只要有人願意附和、我通常沒什麼意見,也覺得沒什麼立場有意見 -- 若真有意見,我自己會想辦法參與並更正問題。

當然,表達也是種參與,但單向的表達比較難改變什麼就是了。

對了,小莎請不要推這篇,嚴肅過頭了。小朋友也不必想太多,負責來玩就好 :P

2010/3/31

我們社群的款項,適不適合交給軟體自由協會代收?

您的 FLOSS 社群要良善地經營下去,無可避免會遇到錢的問題。事實上,個人早期在 MozTW 的想法是,能不碰錢就不碰、想捐的統統捐給 SLAT 等單位,因為我需要時會跟他們伸手;不過,這樣的型態終究會在社群需要擴大發展時遭遇瓶頸,例如:

  • 您知道嗎:目前除了 Firefox 3.5 mini party 外,所有的 Firefox Party 都是在活動前一個多月才開始籌辦的。為什麼?因為不知道能不能找到經費來辦。
  • 各位拿到的貼紙其實不算什麼大錢,但由於個人並不喜歡出力的人還得自掏腰包的行為,所以以身作則不捐錢給 MozTW 的情況下,我們連印個貼紙都要想看看經費哪裡來,並且不確定這錢是否該花。如果有常備經費的機制,就能夠評估可行性。

即便不搞這麼大,有時您可能還是會希望能辦點活動什麼的,宣揚國威增加曝光來招募新血。那麼說辦 30 人的中型聚會好了,假設原先的計畫是讓參與者自行付費攤平成本,那場地食物的訂金付下去、就會開始擔心是不是真的能拉到 30 人來… 何必把時間浪費在這種地方呢?有風險管理概念的話就可以比較放心做事,而要做風險管理、先知道有(或可能有)多少資源可以消耗,也是需要的吧!

如果可以讓社群有公款的財務機制,這件事情可能就方便些;有了公款之後,接著就會想到錢要怎麼進入的問題,常見的方法當然就是呼朋引伴齊捐款啦!這時會遭遇的麻煩是,因為社群通常沒有非營利(或營利)的法人組織可以合法收款、開收據,延伸出的問題包括捐款人無法享受稅務減免、道德公信有瑕疵等等。當然,申請個法人就可以解決這個問題,但多少會需要把有形無形的資源消耗在維持法人體制運作的事情上,我們也不能奢求每個社群都有能力與意願經營法人。那怎麼辦?

軟自協的代收辦法正是為此而來。由軟自協以法人的身份,出面代替您的社群收款、開收據,然後協助您依據合法的報帳流程、以較有公信力的方式把錢花到原本想花的地方。目前我們社群已經順利使用過一次這個機制,讓台南某印刷廠的老闆能在贊助 MozTW 印貼紙的同時、也享受一下折抵稅款的優惠。

思考是否交給軟自協代收,當然有很多包括信任關係在內的考量,不過除了這些我什麼也幫不上忙的思量外,您應該會想要了解「某類捐款,適不適合這個代收機制?就算適合好了,在現行辦法上交給軟自協代收,會對我造成什麼麻煩?」這就是我可以回答的問題了!事實上,剛剛正是回答了某社群的來信,我才發現寫一篇這玩意好像不錯 :P 以下其實改寫自我針對此問題的回信,打些馬賽克、並且補註一些要點。在確定信任軟自協、想尋求軟自協代收款項後,輪到代收辦法上場向您提出一些問題:

這次的收費,是營利行為嗎?

營利行為的定義請自由心證… 我的定義是「除了打平開銷外、目標是小賺」。

如果是,那麼其實由公司來收比較好… 事實上,是「才可以」,因為軟自協收到的費用必須有合乎規定的報帳方式,不然還是會被課稅。如果社群這次的收費是會讓某人有一定利益,那這塊利益的部份想來是無法有合乎規定的報帳方式滴~

代收是哪類款項?

反正名義上一定是捐款,這沒有問題。

以這次被問到的例子來說,算是中型研討會的報名費。其實若是報名費,那麼既然當場收了錢就好、且不是營利行為、隨手付清款項也就行,原本就不會有稅務問題,給軟自協代收的理由就大概剩下收據跟人工問題吧。不過軟自協目前不代收單筆不足新台幣 5000 元的捐款,所以也沒辦法省人工,於是除非您的研討會每人入場費要 5000 元,否則此路不通囉!(每人要 5000 元的研討會是租到什麼場地請到什麼講師啊?軟自協講師費只能報每小時 1600 喔!)

但,如果是「由軟自協出面,代表貴社群收企業的贊助款」,那蠻適合的,軟自協的代收辦法就是為此而存在。不過這樣又要考慮另一個問題:

錢會很快花掉嗎?

目前的代收辦法中,最大的缺點是捐款必須在一個月內,依據軟自協的規定,花掉並且提供合乎報帳原則的憑證 ── 事實上,打一開始您申請代收款項,就必須說明這筆款項要用在何處、讓協會協助您用合乎規定的方式報帳。這個期限最多延展至三個月。

也就是說,如果想要「存著等以後用」,那依據規定來說軟自協幫不上忙。我自己也參與社群,當然知道社群會有這方面的需求,不過此辦法推行初期,為了避免搞太大有什麼問題沒考慮到,在各方面都有一定的限縮,例如只收 5000 以上的款項這點也是,還請多擔待。

當然如果社群要作內外帳,那軟自協橫豎是不可能知情,不過就有法律與道德上的瑕疵,責任請自負。


我自己蠻希望在我理事任期滿之前處理完「接受小額捐款」及「捐款流入社群專款帳戶」兩個問題(然後就卸任 XD),不過人很懶,需要有點動力。有興趣一起討論、或具有這方面的法律知識者,找個週一晚上來生態綠一起聊聊吧 :)

2009/9/4

Creative Commons for Mozilla Service Week

Mozilla Service Week 是 Mozilla 在今年 9 月 14 到 21 日舉辦的全球性活動,提供非營利組織與志工之間的配對、鼓勵大家在這一週奉獻時間心力。雖然很可惜的是台灣找不到人接手籌畫所以沒有參與,但我意外發現這件事情又不小心跟我的工作串了起來。

創用 CC 的美國總部響應 Service Week,號召志工於該周前往 IRC 解答新手疑問。無論你想要發問、或願意幫忙,都可以在那段時間裡於 Freenode 上的 #cc 聊天室找到自己的位子。為了確保一定有人在場能夠回答新手問題,有意願協助的朋友可以前往 CC 的 Wiki 上自願排班,藉以協調人力;當然,也別忘了到 Mozilla Service Week 網頁上登記一下自己的貢獻時數吧。

我本來想也來發起一下中文的 help desk,不過一方面是實在不確定會不會有足夠的志工來協助回答問題、二方面是平常根本也沒多少人寄信到 CC 來發問啊 XD 這回就先跳過了,提醒大家有相關問題還是可以寄信或者直接打來問,也可以在 Twitter、Plurk、Facebook、我的 Blog 上跟我討論喔 :)

這些東西都連在一起的,怎麼能分開呢?

2009/9/3

Mozilla Labs: Bespin

去年十月 Mozilla Labs 推出了「雲端版」的程式碼編輯器 —— Bespin。你可以想成是 Google Docs 的程式碼編輯器版本,讓你能夠以任何 (符合先進規格的) 瀏覽器隨處修改、編寫程式碼。對我這個並不自視為開發者的人來說,剛推出這個專案時只是為了了解一下而試玩一陣子,短評:有趣,但還看不出哪裡有用。昨天因為去 GTUG 時 Gasolin 提起而又把他開出來,士別三日還真是成長得很快啊!

Bespin 的開發原意是要打造開放、可擴充、能提高開發綜效的網際程式編輯環境;另外如同我們對 GFX 的期望一樣,也肩負推廣開放標準的責任。因此,這個專案有幾個目標:

  • 當然是要好用。這包括介面設計、類似 Emacs 的命令列工具等等,當然執行速度上也有一定要求。
  • 既然是網路,當然也要協同作業。因此,你可以將專案分享給其他人即時共同編輯。
  • 要做到開放、可擴充,首先應該自身就應該以符合網際標準的程式開發,讓支援先進標準的瀏覽器 (例如 Google Chrome 等) 也能使用,而不能限制在 Firefox 上;另外,應該要能以 JavaScript 擴充這個編輯器,讓特定需求的使用者用起來更順手,像是 Eclipse 一樣。 (當然更不用說這應該要 OpenSource)

這兩天玩的想法

去年剛開始時玩沒有很大感覺,不過我昨天玩的版本 (0.4.2) 倒是足以讓大眾對這個十分大器的專案備感信心。雖然中文輸入上有先天限制 (他把鍵盤事件都抓走了,無法打中文、只能貼上),但豐富的自訂能力與方便的命令列還真不簡單。

  • 目前協作功能還在實驗中、預設並未開啟,要試試看的話可以自己動手打開。除了這個功能之外,還有很多、很多設定都藏在 BespinSettings 裡的 Settings 檔案,可以直接編輯、或者用命令列 (Ctrl-J) 型式開啟。

  • 命令列的命令可以自己用 JavaScript 寫,就跟 Ubiquity 一樣。已經有人寫了些東西,我覺得 pastebox 應該可以用來暫時繞過中文輸入問題,但還沒試過。
  • 他可以直接引入公開的 SVN 或 Mercurial 專案,也當然可以執行相對應的各種操作 (co, ci… etc.)。我還沒測試把 MozTW 網站整個 co 過去,因為…
  • 開放給大家玩的主機,單帳號容量限制為 15MB 而已 XD 感覺起來好像少到炸開?但一方面別忘了這還只是剛開始、二方面對大部分的專案程式碼其實也還夠用;另外別忘了這可是個自由軟體專案 (with MPL 1.1),你可以把程式碼拿回去架在自己團隊的主機上玩啊!

開放

事隔這個專案推出快一年,動手寫這篇的緣故主要還是沒看到有介紹新發展的中文文章。發表初期的文章裡我覺得網路資訊雜誌這篇寫得蠻不錯,不過有一點並不太同意:「讓程式開發人員與 Power User 更離不開 Firefox」。

就算不提這本來就是個跨瀏覽器都能用的專案,我的觀點是,Mozilla (and MozTW) 做的事情並不是為了要讓大家黏住。例如你可以拿 Bespin 回去修改、整合在自己的專案裡 (已經有人對他的 XWiki 動手腳了),或者想像一下 Google App Engine 裡附上 Bespin 讓開發者在只想小修的時候也有個方便的工具;上面這些整合方法都可以把 Bespin 乃至於 Mozilla 的品牌名稱全部拿掉、僅留簡單 credit,並且弄出完全不同的計劃 (像 WebKit 與 KHTML)。Mozilla 得到什麼?除了所謂的理念推廣或者品牌印象之外,absolute nothing。如果 Mozilla 企圖讓人減少選擇,那麼我們這群支持者會第一個跳出來對幹。

加入吧!

所以總之,如果你對這類工作模式有興趣,也熟悉 JavaScript,或許可以考慮參與這個專案。只要一點點力氣、寫個 command 或許就造福很多人,這是十分輕鬆的貢獻方式。


隨手記:昨天後來有跟另一位先生聊天,他問話的方式我其實不很喜歡 —— 「你們做這個都是為了好玩嗎?會考慮商業價值嗎?」這幾件事情不衝突,我們該接受的挑戰就是如何兼顧。畢竟,你知道資訊流竄的未來,並不是想辦法固守機密就能存活的時代。Copy 太簡單,方法也太多了。

2009/8/13

使用、推廣、開發等角色與 GFX

自由軟體的參與者,依據 COSCUP 的分類法是開發、推廣、使用三個層面(我完全不知道這是誰先提出來的,所以請恕我無法準確姓名標示 :P) 。這三層有些要點:

  • 所有人一定至少是使用者,不使用但參與開發和推廣的難有熱情支撐
  • 推廣者不見得會開發
  • 開發者不見得想推廣
  • 以為自己會開發的推廣者跟以為自己會推廣的開發者都很多

所謂的推廣者,在這邊我想稍微清楚由自己的角度定義一下。「推廣行為」指會直接擴展使用者或貢獻者數目的行為,所以如果只是接 ticket 開發就很明顯不是,而跟左鄰右舍好康倒相報的算是。幾年前 COSCUP 網站上曾提過推廣者是「把軟體包裝成套件」這類的,雖然打包的技術門檻不很高、不過畢竟稍稍有一點,所以我私心還是會推到「兼具些微開發能力的推廣者」或「兼具推廣興趣的開發者」那邊去。

又,之前也提過消費者和使用者的區別,但我這邊先混雜在一起了;如果強要分類的話,我想由於軟體的開發畢竟還是萬事的起源,所以行為無法對開發這件事情有直接或間接貢獻的、或許就可以算是消費者。無論如何這邊先不分,那麼以此三者應該可以繪製成這樣的圖:

既然都被稱為是三隻腳了,理論上三者的關係應該會是彼此互助通力合作的:

不過實際上由於種種因素,我個人的感覺好像是這樣:

這邊看起來好像使用者能做的事情真的很少。以前就提過關於貢獻率的問題,我一直在想:有什麼是單純作為一個使用者可以貢獻的事情?

  • 捐錢贊助自己支持的軟體,此為正解。
  • 跟朋友推荐嗎?那你就變成推廣者了 (恭喜~)

…後來發現自己真的想不太到,這樣要怎麼提高貢獻率呢?要大家多捐錢嗎? (你捐了嗎?)

我想 GFX 或許就是路徑之一。如同之前所說,我自己是希望「提供更多、更輕鬆並且容易抽身的參與機會,讓人進來先挽起袖子動手碰碰看再說。」除了方便推廣之外,也更提供一個「讓你自己說」的途徑。整個專案從頭到尾,我們都希望把「選你自己的選擇」這個意念傳達給使用者:你不需要在我們站上註冊、用你自己選擇的帳號供應商就好;你不需要侷限於 Firefox 產品頁上的介紹文、選你自己推薦的理由就好。這就是你自己的推薦網頁,你自己可以做決定。當然限於時間人力等因素,我們還沒有辦法做到更高度的自訂,但的確是朝著這個方向前進的。

朝著這個方向前進,也就是說除了勸大家多捐錢之外,我們正試圖讓更多一般使用者也能搖身成為推廣者。

目前 GFX 已經為我們多帶了數百位推廣者進來,這些人裡很多我們早已熟悉、也有很多是先前不認識的,無論如何效應的確有做出來。接下來或許就是要好好考慮幾個方向:

  • 怎麼讓推的人覺得更有意義?成就感更高?
  • 怎麼在加強自訂功能與降低複雜度間取得平衡?
  • 還有什麼 Open 的概念可以幻化為其中的功能、介紹給使用者?

一直記得推廣活動的成功與否要看能帶進多少長期參與者。一切應該會更好吧,我這麼相信著。

2009/3/26

該怎麼定義 MozTW 社群?

早上寫的信,整理如下、表達一下我的看法:你怎麼定義誰是 MozTW 社群、或不是?我個人是傾向不定義。或者先換個角度,社群成員應該會有哪些行為?你可以

  • 單純因為支持網際標準而推荐別人使用 Firefox
  • 設計一些好看的海報協助宣傳
  • 從社會運動角度、寫支持網際自由的文章,為他人提供思考的衝擊
  • 在討論區上為新手解答疑惑、或者就寫教學文件降低進入門檻
  • 協助辦活動,協助募款
  • 提供行銷企劃方案
  • 提出網路使用行為的分析報告,協助大家改良網路體驗
  • 或者,最單純最單純地,你使用 Firefox,讓各大網站設計師有遵循標準的理由 (或說壓力)。

在 Mozilla 這樣的專案裡,貢獻的方式千奇百怪,若要限定一個範圍才叫作「社群成員」,不免排除其他方式、排除其他可能。面對他人的詢問,我經常用這樣的回答:「廣義來說、有用 Firefox 就是社群成員;狹義的話,就是經常參與:討論、分享、協助辦活動等等。」其實,這依然刻意避免定下範圍。之前在近期碎念裡提過的,「之所以老回答不出來『社群有多少人』,正是因為不想忽視、貶低任何一點支持的力量」,是依循這般信念寫下的。

MozTW 本來就是個在網路上的社群,是或不是 —— 你覺得是就是,不是就不是。這說法很詐,不過實情確實是如此。

但正如你我一樣、社群成員可以有各自的思考,這部份是獨立的。那麼我們怎麼知道社群的意識是什麼?事實上,這不是以人、而是以事為主聚集的群體,而對事情的看法即便是一個人也能有眾多面向:你擁護 Open Source 不見得要擁護 Free Software,但至少這兩件事情都是「自由」這個理念的面向之一,是以、我至少可以說這個社群是熱愛網路、熱愛自由的,也因此形成所謂的社群。

或許最好的公約數是「熱愛網路自由」,並由任何角度參與 MozTW。這些就是社群,社群就是我們。

那麼誰是所謂的「Official」呢?或者、「Official」這個概念在這類的社群裡面,該怎麼變化?目前來說,我的職稱是因為實際需要而定下的 (記者看不懂「社群成員」這四個字,有時也很難解釋),而通常正式發言時我也只敢說「我的想法是」而避免用「我們的想法是」來企圖代表社群。不過無論如何,實質上我可以控制主機、實質上我對專案的參與比較積極、實質上別人乃至於 Mozilla 基金會要找台灣的時候會找到我 (以及 MozTW.org),那麼我只能力求自己反應社群意識、然後就依據自我判斷行事了。我是不是官方的一份子?不是也是、是也不是。

或許等到哪天我開公司來養 MozTW 的時候,這個問題會比較好解答 XD

2009/1/24

雜記

這其實牽扯很多事情,我不願意向自己的思緒裡挖得太深、畢竟速記才是我的目的:

  • 公共關係
  • 訊息的完整正確性,在這個訊息四散快速流動的世界裡,是否仍是不可妥協? (我私心認為完全可以妥協 —— 長期看來是不能妥協的,但應該允許「部份」事實逐次流出,進而構成「完整」)
  • 怎樣的參與是參與?哪些方式的參與才能真正達到目的?若無法定義這個,你就沒資格說我的參與不是參與,而我嚴重懷疑是否能定義。「廣義來說,使用 Firefox 等軟體的,都可以算是社群成員。」
  • 或者,用利害關係人的概念更清楚些:即便是反對你的人,散佈反對訊息的同時都等於正對這個話題提出貢獻。
  • 如果我們,「網路原生種」的我們,的確必須連線才能發揮最強威力,那麼為何定要離線?這不可以是「沒有網路我什麼都做不成」的藉口,但同時要檢視「該離線」的言論,你只需問他五個「為何?」

2009/1/22

今天我去了野莓之家

我是因著黑熊的召喚去的。雖然其實當初我不曾真的主動協助他們對外「拉票」,但畢竟廣場去了、名簽了、Wiki 編了、人訪談了(紀錄我給了阿孝老師),甚至還因著 Tyler 的要求、陪他們顧到半夜三點過,總不能說自己全無責任 —— 是的,責任,上面講這些並非邀功、反而是覺得自己有責任:不是對他們,是對自己。我對他們近來的公關能力大搖其頭,需要知道自己應不應該繼續支持這個團體。如果他們無法提供相關的訊息,或許責任就還是自己得擔起來。

即使我僅代表我自己、應該也可以舉手發問,因此我就去了、沒有預告地支身前往。地方離捷運古亭站不遠,而我到達時正值晚餐時間、野莓之家內僅有數名成員留守。我探頭、舉手,向最容易以眼神接觸的女性打個招呼。

「你好。」她微笑回答,但聲音感覺沙啞,也略帶疲累。

「請問… 有財務人員在嗎?」

此話一出,我視野所見的三人明顯多了分戒備,空氣也更尷尬了些。

「他出去吃飯了耶,請問有什麼事情嗎?」另一位女孩驅前問道。

「我想來看一下財務部份的紀錄…」

他們的表情告訴我,我並不是第一個來訪的不速之客。甚至我懷疑,或許在第一句的招呼裡,我的來意便已遮掩不住 —— 這也無妨,我本來就打算直接表明自己的目的,能省事是最好了。

「嗯… 財務出去吃飯了,」站在一旁的高個男生接話「我們有影印完整的資料您可以參考…」說著,他便轉身向資料處步行而去。

方才驅身向前的女孩 (我早該為他們命個「甲」、「乙」那類的名字) 一邊招呼,說財務只是去用餐、很快就回來,也順道問我的身份,這問題讓我有點尷尬。我並不曉得對她而言、怎樣的我的身份才是適宜的。我是一個路人、是你們活動曾經的參與者、是一個網誌寫作者、是愛好自由文化的訪客,「職稱」總是很方便的介紹用語,聽者可以直接套用相關的成見在你身上、試圖把你與其它他想像中的群體歸於同類。不過這些稱呼對妳是足夠的資訊嗎?事實上妳問了的期待是什麼呢?

「我… 什麼都不是。」他們笑了,稍微化解了尷尬的氣氛。幽默是最好的藥,聽起來像玩笑的實話也是。

那男生招呼我進門,拿了本厚厚的影印資料給我,語帶抱歉地說:「我們人力不太夠,所以有很多資料還沒辦法輸入成電腦檔案,真不好意思。」這些資料大抵是收據與各種開銷的憑據,說實在對我來說更希望獲得的是一份清單。我追問了不回應網誌質疑的原因,獲得的答案大概還是人力不足云云。如你所想,我不覺得這是理由。

於是剩下來的選擇似乎只有等或不等了。雖然明白 Tyler 在 Twitter 上說的「大概就是賭你不會去看吧」是玩笑話,不過我仍希望能幫忙把這洞給補起來。要補洞,就目前來講,實體的參與還是必要的 —— 但這樣等要到何時呢?一個陌生人在他們的「家」裡,或許更顯尷尬。到現在,這篇文章裡已經出現了四次「尷尬」,我低調又嬌羞地決定留下名片離開。

我離開後大約一個多小時,人已經在生態綠咖啡店,剛對著老連不上無線網路的電腦生完悶氣,閱讀著。此時財務來電,向我解釋目前的狀況。他說得很多、剛從書中抬起頭來的我吸收上有點吃力,但拜字句不斷重複所賜、還是大概抓到了幾個要點:

「大家拼期末,人力不足,網路上丟出疑問的人們、也不見來幫忙」

「我到剛剛才知道網誌上的留言,明天大家會開會討論怎麼回應目前的狀況」

「我們也想快點公佈」

「希望能把資料都整理好再一次公佈」

「我算是記帳、主要的財務還在忙…」 (口試?我記不太住了,不過對我來說、忙些什麼無關緊要,總之是在忙)

「來到野莓之家提出問題或留下資料的,我們都會一一解釋」

「我便是接受龜去來嘻訪問的人,捐款數字講錯的也是我… 那時資料亂」

對於這些解釋,我無心確認精確度,也終究是沒有問出「能一一私下談為何不一次公開講」這樣的問題。事實上我獲得的解釋與網路上已知的回應無甚差別,同樣在志工組織做事的我也可以部份理解,不過總覺得有點騷不到癢處。

「沒關係,我想我直接說一下我的態度,」面對即將再次重複的句子,我打斷他,「事實上我會來,是因為我也想知道該不該請你們刪掉我的連署資料 —— 這樣似乎是有點不負責任,畢竟當初的訴求我依然支持,但你們不回應的情形下會讓我也不想支持,所以我想了解狀況、以及為什麼。」

在咖啡廳裡大聲喧譁或許是有罪的,我盡可能放慢速度、降低音量,但還是不免吸引了別人的注意。或許他們也好奇著我們談論的內容、心裡也正猜著那頭的是誰。無論如何,掛上電話前我仍沒有講出的話是:我是想來幫忙的。如果你們忙到連貼文的時間都沒有,那麼我會把我聽到看到的東西貼出來。於是在明早還要開會的情形下,我仍找死地、寫這些不曉得會被誰閱讀的文字。

如果這篇看起來像小說,那肯定是我故意的。我最近在練習作文,各位老師請多留言指教。

2008/11/18

叫 FOSS 開發者「以使用者為本」?

某長輩的論調,我個人覺得這絕對是錯誤的路徑。

路徑錯誤不代表這件事情是錯的,設計軟體本應傾聽、以使用者的需求為導向來開發。不過單純請 FOSS 去傾聽「別的」使用者意見,很多人不會買這個帳,因為這句話實在忽略了一件很重要的事情:大部份 FOSS 開發者,是做爽的。開發要不就是為了興趣,要不也只是為了自己。無論他想要的是名是利、不爽的事情怎麼可能去做呢?

所以是說就不要管別的使用者,蠻幹就成?也不盡然,開發者必定希望自己的軟體 (從某個角度) 是有用的,所以說服他「修改了這個,更有用」無疑是使用者該做的事。抱怨的人通常要負起「把話講清楚」的責任,而不是要求人家猜測你的心情。

不過,這些事情或許可以藉由 Promoter 的角色做得更 smooth 一些。除了推廣之外,promoter (我指像我一般,不太寫程式的人) 可以藉由測試,收集、分析回饋,寫「開發者看得懂的」錯誤回報、解釋狀況等工作,幫助 Coder 更清楚分辨哪些事情是真正重要的。

是不是有點像代議式的政治呢?其實我們並不試圖把 Coder 藏起來,有心的人都可以自己學習如何把「回報」這件事情做得更好。不過,對於一些沒時間學 (我並不想單純說他們懶) 的人來說,或許這樣的角色還是相當有價值的。

Promoter 對 FOSS Project 的貢獻其實比較容易想像,但 User 對 FOSS 的貢獻、除了「捐錢」之外好像不太想得到些什麼?這或許是我接下來必須思考的東西。(say, learn to be a promoter, or even a coder? how?)

2008/11/14

平衡

忘了有沒有講過一件我夢見的故事

某小弟畢業後前往某新興餐廳工作。由於某小弟對餐飲無經驗、只是興趣而有心從頭學,所以應徵了內場 (廚房) 助理。據說因為什麼稅務的關係,某小弟等服務員的底薪並不高,很大部份要靠一些名目上的獎金來加成。由於主廚確有一手,餐廳形象也很好,所以起初對於薪資某小弟並不很在意。

很在意的,是工時。

做為一家新餐廳,老闆請了四位內場服務人員 (主副廚,兩位助理)。餐廳從中餐開始營業、晚間十點打烊,所以這四位內場人員每天早上九點就要進場處理食材,打烊後也常需要準備隔天要用的東西。初期,忙到半夜是常有的事情,況且餐廳並不能休假日,所以每週也只有周一公休可以放假。某小弟原先只有微薄的抱怨,但畢竟是剛開始,大家都期盼著更好的明天,也就努力做下去。依照這樣的工時做了半個月,某小弟拿到近兩萬元的薪資,對比工時其實還不錯,也就繼續打拼。

這家新餐廳開在熱鬧的地方,價格跟餐點都瞄準高消費族群,第一個月雖然無法打平,銷售額跟名氣卻扶搖直上,也吸引許多饕客與名人前來用餐。某小弟想著,這個月也是辛勤的工作,依照上個月的數字來算,或許應該有個四萬?工時的確遠遠超過上班族,但也不是沒有相應報酬,便十分期待發薪日到來。

大概是三萬五,某小弟不太開心。每天的忙碌加上切菜切到發炎的手腕,這些薪資似乎不太成比例。

不過同事們拿到薪資單好像都很高興,外場的伙伴拍著某小弟的肩膀:「大哥,這就是餐飲業啊!」好吧,好吧,那麼便再繼續吧。某小弟知道雖然營業額成長不少、薪資無法反映,但老闆其實還沒賺錢。新公司初期總有些不順遂,這也沒什麼。

下個月薪資單上的「兩萬八」倒是嚴重挑戰了這個想法。

某小弟知道這個月營業額其實還是成長的,那麼到底問題出在哪裡呢?腦袋裡倒是想起了月初老闆娘說的「責任制」的事情。老闆娘希望內場改用兩班制,讓內場人員有較正常的休息時間,於是請主廚再去物色新成員進來幫忙。其實,每天內場人員都忙得暈頭轉向 (相較於內場,外場人員是兩倍有餘,尚堪應付),這件事情列在待辦事項中許久,也沒真能施行。

所以老闆就以所謂「責任制」的薪資,要求內場人員盡速尋覓新人。

因為尋人責任由內場管理 (主廚) 負責,於是沒做到就以六折的薪資懲罰整組內場人員。這邏輯好像跟「因為上游剝削加盟店,加盟店主沒辦法生存、只好剝削工讀生」很接近… 嗯?不同嗎?我只覺得都是狗屁不通。

夢裡讓我最難過的是,某小弟的同事們似乎只覺得這是回到其他餐廳的待遇一樣,認命地繼續做事。所以這是常態,所以這樣薪資跟工時不成正比、沒有簽約保障也不清楚勞健保情形的狀況,在餐飲業是常態?某小弟說:「我其實不曉得是我不正常,還是這整個體系都不正常。」

我們真的需要這些不剝削就活不下去的企業嗎?

然後我就醒了,以上都是我夢見的事情。

2008/10/7

教育部資訊志工期初:CC 與 Web2.0, 其之 2

之前提過南區分享的事情,這回是中區的部份。簡報基本上沒有修,不過還是先在這裡集成一下資訊方便大夥下載:

創用 CC

雖然收到「時間不足、不講 Web 2.0」的指令,不過我仍「置入」了「我不要三聚氰胺」網站當作合作範例,略為提一下現在在網路上面彼此合作、以及與 CC 之間的關係及好處。如果想知道本來會講些什麼,可以參考個人式數位典藏上的資料。

無論如何希望大家還滿意