顯示具有 開放源碼 標籤的文章。 顯示所有文章
顯示具有 開放源碼 標籤的文章。 顯示所有文章

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 而來的權力。

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

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

2011/10/24

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

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

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

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

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

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

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

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

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

2010/9/22

24 個你可以提昇 Firefox 使用體驗的機會

Firefox 使用體驗團隊的頭兒 Alexander Limi 貼了篇文,列了 24 + 9 個 UX 團隊希望能在 Firefox 4 解決的問題。這些問題,都(還)不會阻擋 Firefox 4 釋出,卻也不單是修圖、微調那類的東西。希望能人異士出手相助,幫助大家提昇使用體驗,或者最少,如果你覺得這問題很重要,到 Bugzilla 提出 block 的建議。以下依據優先序筆記一下前幾項的內容:

  1. 升級時,將未經使用者明確授權即安裝的第三方附加元件(Plug-ins or so)停用,主要影響啟動效能。有點類似 IE9 Beta 啟動時提醒你某個附加元件太拖累的東西,但另外也在意「不經使用者授權即自行安裝」的元件(如 Skype、Norton 軟體、Java 等)。
  2. 自動清理重複的附加元件,又是 Java,似乎 Microsoft DRM 也會重複灌版本號碼不同、但只是升級而已的套件。這應該是沒有好好指定套件 ID 的緣故。
  3. Windows 下視窗最大化時,分頁與標題列同置一行,就像 Google Chrome 一樣,增加瀏覽空間。這好像有人在試了。
  4. 在 Windows 上啟動時,螢幕繪製的狀況比 Fx 3.6 慘。
  5. 更聰明的網址自動補完。有人動手了。
  6. 即便是 HTTPS 的網站,當掉後也要能自動復原。似乎是政策問題多過實做。
  7. 合併停止與重新讀取鈕後,不應使停止鈕出現「停用」狀態。

    萬一頁面讀得很慢,使用者想按下「停止」鈕的時候會發生兩種狀況:

    • 順利停止網頁讀取,或是
    • 網頁在按下前的一瞬間已經讀取完畢、按鈕變成「重新讀取」,所以使用者按到的是「重新讀取」鈕、暴怒。

    為了防止這種情形發生,目前的作法是在網頁讀取完畢後仍暫時顯示「停止」鈕、但採停用狀態以防止誤觸。雖然實際上對網頁讀取速度沒有影響,但多那半秒的「停止」模樣可能會讓使用者以為網頁讀取變慢了。

    又,你覺得 Firefox「抄」其他瀏覽器嗎?這個 Bug 有 Google Chrome 的開發者上去分享 Chrome 設計的理由 XD 且不論「原創」所指為何,請搞清楚在這個世界裡的共創理念。(這個 bug 有人動手了)

  8. 網址列中,網域部份加重顯示,其實我記得以前 Firefox 曾經有過測試版是如此作用的,但沒加到最後版本的原因不明。有人動手了。
  9. 強化拖曳分頁時的視覺提示,MozTW 討論區之前有人提過,目前沒人動手,我也很想要這個功能 :/
  10. 減弱搜尋欄圖示的干擾,或者更準確點描述問題:「那個區域現在已經有星星、RSS icon、重讀、停止等各種顏色的圖示會出現,搜尋引擎的圖示則是另一種本身就五顏六色的干擾源」。不過個人覺得,現在 Fx 的搜尋欄已經是各家有此功能的瀏覽器中最好的一種了(我尤其不喜歡 Safari 的方式,原因同 Comment 5),接下來可以走的方向應該就只有與位址列合併了吧?
  11. 在選單中增加縮放控制的介面元素,類似 Google Chrome 現在的作法。討論中,我不是很喜歡 Google Chrome 7 dev 實做選單中多重控制項的方法,尤其 keyboard inaccessible、and no tooltips 這些小細節。
  12. 「應用程式分頁」中的外部連結,應該開在新分頁裡。可以來討論「什麼叫做外部連結」 XD
  13. 應用程式分頁隱藏瀏覽工具列等元素。好處:很多 Web 應用程式確實不需要瀏覽器內建的導覽列。 壞處:但,有的需要啊!又,「外部連結」的 Bug 裡有人提到,這會讓辨識釣魚網站變得比較困難。應該是不用期待 Firefox 4 會有這個。
  14. 多重選取分頁,又一個邁向提姆所謂「Firefox OS」的東西?

因為我也沒有每個 bug 都點進去看,所以先紀錄到這裡吧。有興趣的可以去看一下原文。其實整份清單還很長,如果你對相關的問題有興趣,可常回 Mozilla Wiki 上參考完整清單。

New Ubuntu, count down!

The next version of Ubuntu is coming soon

我特別貼了,只是因為它上面有兔子!真是有過節氣氛!

2010/9/8

失敗的 SEO 例子 (update)

可惜當時忘了先查一下,應該先了解是什麼時候開始阿貴老師的排名跑到第一個,這樣才有個比較基準。

Yahoo!結果 (我想這是他們的主打)

Google 結果

幾點筆記:

  • 正版 = 購買,這是 BSA 希望你記住的思維,不過對於自由軟體使用者來說倒是笑話了。
  • 但其實 BSA 就是要大眾這麼想,他們並不是笨到連這點都不清楚,事實上網站也列得很詳細。不過,商業軟體組織會這樣,很自然,也沒錯。反應著 BSA 的存在目的就是協助商業公司遊說政府、遏止無授權的軟體流竄。
  • 「全部換正版」應該是個很容易被攻擊的關鍵詞,因為平常實在不多人用,相對來說稍微對搜尋引擎有點了解、就可以輕鬆爬到比官方網站還前面的排名,況且...
  • 況且,BSA 這個活動的網站是全 Flash、看起來也沒有提供 accessibility 功能,所以搜尋引擎都討厭他。你看連畫面上僅有的那幾筆都是新聞頁面,第一頁除了 paid result 外也沒有活動網站連結。

不過這個活動有沒有成功?畢竟,他們就是要喊出來而已。或許這個結果對他們來說,是能接受的結果。我不相信不能接受還用全 Flash, inaccessible 的網站 orz 連 meta tag 跟網站標題都沒有活動關鍵字,真是服了他。說到底,「100 萬」和馬如龍(搭上艋舺的風潮)確實是賺了不少新聞版面(且不論有多少是購買的,我們不會知道)。

BTW 我不知道這網站是誰做的,我寫這篇跟目前任職的公司毫無關係。我都超支持 BSA 的,活動還沒開始就衝了:

全部換正版!響應 BSA!

2010/8/21

立馬加入 W3C 中文 HTML5 討論郵件群組!

我已經加入囉,其他就直接看 Ping 的文章吧,全文轉載如下:


W3C 的 Chinese HTML Interest Group 要成立了!

這個小組目前還在籌備階段,要等章程寫完、被 W3C 批准才能正式成立,但 mailing list 在 W3C 的 Kenny Lu 和 Mike Smith 的熱心幫忙之下,已經建好了!

如果你熱血到要馬上加入,請發信到 public-html-ig-zh-request@w3.org,主題寫 subscribe,然後依收到的指示進行就可以了。

如果你不確定這是什麼,那請繼續往下讀。

W3C Chinese HTML Interest Group 是什麼?

來逐字解讀好了。

W3C = World Wide Web Consortium = 制定 Web 規格的單位,有興趣了解的人可以看維基百科上的中文和英文說明。

Chinese = 中文,包括正體中文和簡體中文。

HTML = HyperText Markup Language = 用來表現網頁的語言,如果你不知道 HTML 是什麼,你大可以忽略這篇文章。  :)

Interest Group 是什麼?如果你去問 Google translate,它會告訴你 "interest group" 是「利益集團」,台灣霹靂火瞬間上身! XD

其實 Interest = 興趣,Group = 一群人,所以 Chinese HTML Interest Group 就是「對 HTML 有興趣的一群講中文的人」。當然任何人都可以號召這樣的一群人,組織起來討論 HTML 的技術和講中文的人對它的需求,但成立在 W3C 裡有不一樣的意義,根據  W3C Groups 網頁的說明,W3C 的任務性小組有四種:

  • Working Groups(工作小組,暫譯):進行規格相關工作並有實際產出的小組,產出可以是技術報告、軟體、測試套件、評審他組產出的報告等等。
  • Interest Groups(興趣小組,暫譯):對評估有潛力的 Web 技術和政策有興趣的人的集結,主要是個交換想法的論壇。
  • Coordination Groups(協調小組,暫譯):和其他組溝通和協調資源的小組。
  • Incubator Groups(培育小組,暫譯):在一年之內快速開發新 Web 技術的小組。

另外有兩個永久編組,就不多說了,對 W3C 組織架構有興趣的人可以上網查。


W3C Chinese HTML Interest Group 可以做什麼?

成立這個「中文 HTML 興趣小組」(暫譯)的想法是 2010 年 8 月 14 日在 COSCUP / GNOME.Asia 2010 的 HTML5 BOF 期間由 Kenny Lu 找 Mike Smith、柏強和我談的,初期的想法是可以在這裡讓大家用中文討論 HTML 的技術和中文這種文字對 HTML 的需求,如果能把全世界各地講中文、關心這個議題的人聚集起來,如果大家成熟到可以理性討論、凝聚出共識,就能把需求遞交給 HTML Working Group 或讓主要瀏覽器開發者重視我們的需求。

一開始提出的議題是:
  • 直排文書的 CSS3 規格和實作
  • Ruby 的 HTML(5) 規格和實作,Ruby 就是像國小課本文字旁的注音符號那樣縮小排到本文旁邊的字。
  • Web font 的中文支援
但小組成員可以自由提出其他議題。

我在 8 月 17 日的 Tossug HTML5 讀書會中宣傳了興趣小組的構想,立刻得到 21 位熱血社群朋友連署響應!申請一個興趣小組據說總是要一個月以上,而 mailing list 在小組成立前是不會建的;但是顯然台灣社群的熱力燒到了 Mike Smith,讓他破格先建了 mailing list,讓大家不用引頸企盼太久。

我有沒有說過 Mike Smith 是 HTML Working Group 的正式窗口,同時是 HTML 規格書的編輯?

所以,熱情的台灣社群朋友們,你還在等什麼呢?

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/1

Why so serious?

有兩件跟 Firefox 相關的事情,我的意見可能跟你相左,所以我描述一下自己的看法:

Firefox 佔有率上不去是退步的象徵?

Firefox 的全球市占率在 25%-30% 之間停了一陣子,有些人覺得這是個問題,表示 Firefox 進步緩慢、將被後起之秀追趕過去。

我曾說過的話:

  • 如果拿到 10% 成為關鍵少數,也就算達成任務了。
  • 如果是 Firefox 佔有率過半,我覺得反而才是要擔心的。

以現況來說,IE9 是肯定會有非常不錯的進展,但吃掉的可能是 IE6-8 的市場;同樣,Google Chrome、Opera 等市占率提昇,吃的也是 IE6-7 的市場 ── Firefox 只是之前狂咬了好幾口、現在吃的速度減緩而已,他自己的市占率沒差些什麼。

因此,多方共享的天下、是可以預期的。或許 Opera 終將拿到 10%、或許 Google Chrome 哪天也奪得 30% 與 Firefox 平起平坐,但多方共享是必然結果。只有下面兩件事情,才會讓我擔心:

  • Mozilla 不再進步了:若然,我八成會比只看佔有率就講話的人先知道,而且自由軟體社群是支持好的軟體、他不行了我們就分支出去,不會有人跟他客氣的。
  • 雖然其他瀏覽器佔有率上升,但吃的都是 Firefox 的市場、而非 IE6-8:那表示 Webkit 及 Opera 陣營推廣的策略完全與「維護網路標準」無關了。

因此,佔有率重不重要?其實破一定水準之後,就不太重要了,只有要拿去唬一下的時候才會看。

瀏覽器的速度十分重要?

瀏覽器的速度本身當然重要。因應網路未來發展,瀏覽器繪製頁面、執行程式的速度是越快越好。

但是做為我的角色而言,比較誰快誰慢,根本不重要:所有瀏覽器將越來越快、直至不分軒輊而人類感覺不到差異,到那時你比較兩個瀏覽器間的毫秒差距,是否有用呢?我懷疑。

又,速度是影響使用者選擇軟體的一環,卻一直不是全部。使用者關心的是足夠、而不是最好,要不然 IE6 早就退出市場了。

「好不好用」除了速度之外,還有很多因素啊!

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/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/26

Put OGV on Internet Archive

我經常覺得有些選擇的出發點攸關理念,因為所謂「政治正確」的理由而下了決定。就好比因為「開放標準」、「先進技術」等品牌印象上的需求,我會希望 COSCUP 2009 所有演講影片除了傳上好用(但不完全「開放」) 的 YouTube 之外,還可以轉成 OGV 放上 Internet Archive。

這次的 COSCUP 全面採用硬碟式 DV 錄影,錄下來的影片不需要再額外轉為檔案、可以直接處理。在不討論批次轉檔的情形下,Linux 裡的 OggConvert 真的是很直覺方便的轉檔小工具 —— 選、轉、完成,不用花太多腦筋,很適合我這 EndUser。轉檔所需時間要看你的設定,在我的電腦上 250 MB 的影片 (MP4, 720HD, 大約五分鐘) 要花上 12 分鐘左右的時間… 是有點久啦,或許壓縮比調整後會快一點,懶得試了 :P 轉好檔案之後就可以開始上傳。

由於影片較大,我採用 Internet Archive 提供的 FTP 上傳方式。如果你跟我一樣、是採用 OpenID 登入 Internet Archive,此時會發現一個問題:FTP 上傳需要的帳號就是你的 Email,不過密碼呢?Internet Archive 當然不會知道你在 OpenID 服務那裡設定的密碼為何,所以其實他們內部有準備另一組密碼給你,只要前往 Patron Info 裡的「Forgot Password」填上 Email 即可,系統會寄給你這個帳號的密碼 (是一組亂碼),你就可以用這組帳號和密碼登入 FTP 開始上傳囉!詳細的操作步驟,可以參考別人寫好的圖文教學。

傳好檔案後還要去「Check In」,表單挺複雜、但必填的欄位不多,無論如何填好後你的檔案就會在他提供的網址上出現了。既然已經將 OGV 傳上 Internet Archive,不來試試 HTML 5 的 VIDEO 標籤不是很可惜嗎? :P

如果你的瀏覽器還不支援 VIDEO 標籤,這個網頁的寫法會自動提供 YouTube 影片供您觀賞;要是你連 YouTube 都看不了,那就只好提供一個連結讓你下載影片回家看囉!除了 Internet Archive 之外不知道還有哪個免費的影片服務可以支援直連 (HotLink)、可上傳容量又如此無限的,大家還是要支持一下介面難用的 Internet Archive 啊 XD

2009/8/13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009/6/18

顛覆網路 35 天 (7a): 開放影片編碼格式的品質

這篇主要比較開放影片編碼格式的品質問題,緣起是 Google 的 Chris DiBona 在 WhatWG 郵件群組貼了一篇文章,裡頭提到:

如果 YouTube 要採用 Theora 編碼、還得維持目前的播放品質,那會佔掉全世界大部份的頻寬。

目前關於影片編碼的論戰已經慢慢嘴炮化、缺乏實質的比較,所以 Greg Maxwell 回了他一篇、並放上下列的比較結果。(本篇由原作者授權張貼於顛覆網路 35 天專欄,柏強我只依據往例、節譯重點。)

以下是將同一段影片分別以兩種尺寸編碼、丟上 YouTube 處理後再下載,然後與 Ogg/Theora+Vorbis 比較的情形,各位可以下載觀看以便比對。

~499kbit/sec 比較

YouTube

Download (H.264+AAC; 17MiB)

Ogg/Theora+Vorbis

Download / Watch (Ogg/Theora+Vorbis; 17MiB)

~327kbit/sec 比較

YouTube

Download (H.263+MP3; 12MiB)

Ogg/Theora+Vorbis

Download / Watch (Ogg/Theora+Vorbis; 12MiB)

位元率都分別標示出來了,而 Theora 的版本故意稍稍降一點位元率,以防止略大一些的檔案大小會被懷疑是故意提高品質。要真的公平比較的話,請把音效也考慮進去,光看靜態圖片絕非比較影片品質的好方法。這邊的靜態圖片只是為了方便讀者而做。

製作方法

以下是這四個檔案的完整製作方法:

  1. 影片來源是 Blender 基金會以創用 CC 授權的動畫片 Big Buck Bunny,版權無慮。在此使用 media.xiph.org 上下載的無失真 640x360 PNG 與 FLAC 版。
  2. 以 ImageMagick 的轉換工具重新取樣成 480x270。
  3. 使用 gstreamer 的 jpegenc,設為 quality=100 的 mjpeg + PCM,產出大約 1.5GB、位元率約為 20Mbit/sec 的檔案。
  4. 將檔案裁剪至 1G 以便符合 YouTube 的限制,產生 input_mjpeg.avi 檔 (706MiB)。
  5. 將檔案上傳到 YouTube,交給它轉換。
  6. 下載 YouTube 產出的 FLV 即 H.264 格式檔,工具很多種、在此用的是 keepvid
  7. 將原始的 input_mjpeg.avi 以 libtheora 1.1a2 與 Vorbis aoTuv 5.7 產出位元率約當於 499kbit/sec 的檔案,這個數值與 YouTube 產出的檔案相同。
  8. 將 input_mjpeg.avi 再重新取樣產出一個 400x226 的檔案。
  9. 接下來步驟同上一個檔案,最後再以一樣 libtheora 1.1a2 與 Vorbis aoTuv 5.7 產出位元率約當於 327kbit/sec 的檔案,這個數值與 YouTube 利用 400x226 的影片產出的檔案相同。

Greg Maxwell 的結論

  1. 較低品質的兩段影片很難辨出高下,而就算是高一點的品質、YouTube 目前所採用的方式也不見得就高到哪裡去。這樣的品質下四段影片檔必定各有缺點,而取捨就見仁見智。
  2. 就以我 (Greg) 的觀點,在 327kbit/sec 的影片 Theora+Vorbis 的格式遠勝過 YouTube 使用的 H.263。遇上聲音更明顯:Vorbis 版可以聽到片頭的蟲鳴、而 YouTube 的檔案中就聽不見了。
  3. 高品質的部份,在細細比較後可能大家會比較偏好 H.264 的版本,但差異不很大,大部分的人應該都分不出來。

Greg Maxwell 的信件可以查閱原文。

更高畫質的影片呢?

拜我偷懶到今天才動手看這篇所賜,有另一篇補充的文章可以即時一併翻譯。Maik Merten 為 HD 畫質的影片也做了比較,截圖如下:說實在差異不大,而且 Theora 的仔細看感覺好像還比 H.264 更好 (注意頭髮的地方)。別忘了看看影片來比較喔:

所以綜上所述,別嘴炮了,要比較畫質還是實際用眼睛看看吧。

2009/3/26

Firefox, Mozilla, and MozTW

在元智大學資訊週的演講,第一次混搭了這麼多議題拼成 90 分鐘滿滿的內容,有點太多… 下次或許可以刪掉代表社群人數的那幾張,一張併起來解決吧。以下是簡報,其他內容可以參考我的簡報資源頁。

前天聽聞微軟在周一的演講中花了很大段時間介紹 IE8,我其實很有興趣知道他們想打哪些點,詢問之下大致不出所料。雖然我處於比較有利的時間點,但由於覺得沒必要提誰比較快啊啥的競爭的話,所以原先也沒打算講些什麼,但工作人員提到微軟說 IE8 比 Firefox 快這件事,mm… 對我來說兩造根本是從不同的角度看事情。

微軟關注解析引擎,而包括 Firefox 在內的其他瀏覽器已經把焦點放在 JavaScript。我不同意「JavaScript 對網頁載入的速度,只有小部分影響。那是一部份,但絕不是最重要的部分。」或者說、這的確是種說法,但在網際應用程式越來越複雜的同時,不加強 JavaScript 就是阻礙進步而已。從這角度,「絕不是最重要的部份」成了真實的藉口。

ZDNet 的 Stephen Shankland 有言「微軟是鎖定現在的網路,而對手們是放眼未來的網路。」我想這的確是 Mozilla 關心的事情:你在用的網路怎麼樣可以更好、更創新、更進步。微軟作為商業組織,服務當前的客戶也十分合理,然「速度」是個看起來很真實、但不太需要在意的項目 —— 目前最快的成像引擎跟最快的 JavaScript 引擎都是開放原始碼的,歡迎互抄、互學習。

不過既然你都提了,我也秀一下這張好了:

瀏覽器 JavaScript 競速圖 from CNET
來源

另一件趣事:前天跟總招品光 (petercpg) 開玩笑說記得叫正妹來接我,結果真的來了蠻可愛的女孩子 @@ 雖然品光說他完全不曉得會這樣,一切只是湊巧… XD

2009/3/8

Firefox 3.1 改了版號,之後呢?

「Firefox 3.1 八成會更名為 3.5」,這是我前幾天看到會議記錄裡註記「考慮要改」之後的感想。昨天很快地看到 mozilla.dev.planning 上已經提出了各項配套,看來就是要改了。為關心的大眾先摘要一下接下來的進展:

  • Firefox 3.1 Beta 3 還是照原訂計劃,依這個名字出
  • 接下來就是 Firefox 3.5 Beta 4 了
  • 原先在 Trunk 裡的 3.2a1pre 接著會改名為 3.6a1pre,不過不代表接著會用 3.6 這個名字出
  • 改名 3.5 大致上不會影響 (已經拖延的) 釋出日期,也不一定會再加新功能。唯有在該功能在 tinderbox/trunk 已經都做完了、不會拖延日期的情況下,才會放進 3.5

其他部份的詳情可以看 Mozilla Wiki,接下來整理一下前天在 Twitter 上跟大家的對談、及我的想法。

導致 3.1 b3 拖延的罪魁禍首之一是提升 JavaScript 速度的新引擎 Trackmonkey,曾經也有提出過是否要砍掉 TM 然後先推出 3.1;隨後,亦有人提議是否將 3.1 更名為 3.5。

我自己是支持保留 TM、改稱 3.5 的,不過這比較是推廣上的考量:首先、使用者的確已經在期待下一版能夠「快很多」,那麼雖然已經改了一些效能問題、但 TM 不進來是不會快「很多」的,可以參考 CNET 最近的測試報告,便知有沒有 TM 的差距;另外,這一版裡加上的各項 CSS 修正搭配 HTML 5 Video/Audio 元素、Tracemonkey、隱密模式等等的其中任何一項,都已經足夠作為一個 0.1 版,這樣一推出我想使用者會預期下一個 0.1 也要有這麼大幅度的改良,這樣壓力也太大了、並且其實一點都不符合 release often 的構想;最後,Firefox 4.0 T-shirt 樣式我已經想好了,不想等到 202x 年才能用啊 XD。

我們可以說一開始把 3.1 塞這麼多東西就是錯誤 (這是我嘆的理由),不過現在改 3.5 我是支持的,以推廣的角度。

alicekey 提到覺得 Mozilla 不嚴謹,並以 Ubuntu 為例、希望可以定期出。對我來說,以 Ubuntu 當標準是絕不認同的啊,這很主觀地因為 8.10 給我的回憶太可怕,從來沒有在灌上後這麼期待半年後新版快到來的 XD。這邊不是要認同「軟體業拖延是常態」 (雖然的確是),但一開始的規劃太龐大是錯誤、改版號在我的觀點來講卻不是。那就是個版號而已,鬆比緊好,大家可以過得比較輕鬆愉快一點。

最後感想:任何對 Mozilla 開發進度認真的人都應該考慮訂閱 planning 這個 mailing list,然後在需要的時候發聲。這是你的軟體,而且你有權可以影響的時候,為何不呢?

2009/1/12

在 Google Sites 上嵌入 SlideShare 的投影片

Google Sites 萬般好,不過天殺地封閉,想放個外部資源還得先看是不是自家產品再說。好在 Google Gadget 並不算難寫,所以我先從解決自己的需求開始、加上了 SlideShare 的投影片功能。

方法簡單:

  • 在 Google Sites 編輯時選「插入>更多」
  • 點選「Search」隔壁的小字連結「輸入網址以新增」
  • 在接下來的網址輸入欄上輸入 http://embedanything.googlecode.com/svn/trunk/insert_slideshare.xml,點選「新增」
  • 設定好大小,貼上 SlideShare 投影片的網址,再點選「確定」 即可,他會自己去找到對的程式碼來貼。

標準寬度是 425、高度為 355,但多寬多高都可以。另,我要很沒良心地說,嘗鮮者用之、遇蟲者報之,有求者可以講但我不見得有能力應就是 — 有能力的人啊,這是 BSD 授權的,歡迎加入修改。

我真的不喜歡寫,但還是得解決自己的問題。

2008/12/12

結束後的 Rule #2

Rule #2: You do blog about barcamp. 所以,即使已經結束了也是要來 blog 一下,況且回顧、甚至繼續討論也是很重要的。身為前期籌備,我有兩個角色可以談論,以下就分開描述:

身為 Barcamp Nano 的參與者

協助提醒時間的人通常很難把一個主題聽/討論完,個人唯一比較完整參加的是小海帶領的「在家做音樂」。我喜歡在家裡錄自己隨便亂哼的調子,但不會任何樂器、五線譜也要算半天還加記號才能跟著唱的我,一直覺得沒辦法紀錄這些東西是很深的遺憾。小海主要跟大家討論的是關於利用組合 loop (不斷重複的旋律片段) 來編曲的方式,自己彈入的主旋律搭配適當的 loop 後就是一首曲子,蠻值得嘗試一下 :P (阿不過我還是只能用軟體拖拉五線譜來寫主旋律… 來去學吉他好了 orz)

loop 是拼貼文化的一份子,我蠻關心「如何找到合適的 loop」 — 這跟 CC 的關係太大了!有好的搜尋方式,就可以讓大家更快速地利用素材,一些以 CC 釋出的音樂也更容易展現在對的人面前。當今科技已經發展了搜尋文字的技術,而如果是圖片、聲音、影片中的文字也有辨識技術可以找出,不過對於音樂的搜尋倒一直是很頭疼的問題。小海也說,這有時是要看運氣,要多聽,或者輸入關鍵字來搜尋附加在聲音檔的文字標籤 (例如「悲傷」、「輕快」、「孤單」等)。我想到 Pandora 這個把旋律拆成元素、可以用來找出相似歌曲的計劃,技術如果發展成熟應該是蠻有看頭的…

清蔚園也有發展過哼歌找曲的技術,不過效果我一直都不太滿意… well,可能是我音不準吧 :P

毛主席講關於 life behind GFW 的事情,很可惜我到處亂跑沒能聽完整,希望有哪位朋友可以分享一下。

身為 Barcamp Nano 的前期籌備者

雖說 Tempo 跟 Cjin 曾經舉辦過「內含 Barcamp」的 HappyWeb 網聚,不過直接以 Barcamp 為名的的活動在台灣似乎是頭一遭,也就是大部份的人都不曉得如何做。除了陳力參加過 Barcamp HK 2008 之外,我因為本來就有在明年發起 FOSS Barcamp 的打算,所以藉著上回去香港的機會、跟許多前輩討教過相關事宜。說實在,這次結果比我原先預想得好多了,因為先天有一些蠻不利 Barcamp 型式會議的「限制」:

  • 場地並不是很適合 Barcamp:就找到的資料跟預想的狀況,Barcamp 應該比較適合在有「隔音 ok,許多小型會議室跟一個大集合場地」的地方。這次的場地顯然不是,也的確有場次被另外的空間影響
  • 時間太短:兩小時實在太短了,這是我為什麼一直表達希望把名稱改為 Barcamp Nano 的原因。或許會有人覺得很無謂吧 orz 我自己是覺得品牌一直很重要,既然大家都同意這是 test run 就讓它有個相符的名字沒什麼不好。
  • 文化:其實我個人是很不想把過錯推給虛無飄渺的東西,這就像是認輸了 :P 不過的確,大部分的場次我們還是看到一人講眾人聽的情況。 (don't get me wrong, 其實現場的情況還不錯,但我覺得比較好是像我在 wiki 與公眾事務那場一樣,很多人發表意見,連我念醫學相關的朋友都以自身角度熱烈參與討論。

這次比想像中好,而下回一定能更好。我發現這回 Barcamp 有些很有意思的特色,多少是因為掛在文化與科技的研討會底下、參與的群眾多少會比 geek 齊聚一堂的會議來得更多元。這或許是我們可以發展的東西,也許下次就可以光明正大地辦「數位公民參與公共政策」Barcamp 那類的東西 :P

是說,我個人比較希望能避免「由數位文化協會主辦」這類的文字,因為 Barcamp 在精神上應該是所有參加者要有「我也是主辦者」的自覺 — 好啦,這很難啦,不過「很難」不是「所以我們就放棄吧」的意思,所以我覺得即使的確必須有一群人執行會前籌備工作,但在名稱跟態度上是應該可以再多思考、以讓 Barcamp 「內建」的自由文化更清楚傳達給第一次參加的人。

我之所以一直不願意稱自己為主籌,原因是這樣。所有跟「主」扯得上關係的我都很努力避開,在我「主」持開幕時也說了類似的話 — 這也跟我早先對 MozTW 的態度一致,只是在 MozTW 的我,已經不再期待救世主了 ^^;

Technorati 標籤: ,

2008/11/29

Rule #2: You do blog about Bar Camp!

Barcamp NANO 台北!

為了遵守規則,在此召告天下:我要去 12/10 在華山藝文中心辦的 Barcamp Nano! 是的,還是在台北,xxxx的台北,不過總之是這樣 ;)

Barcamp 是啥?「霸營」?這是個「非典型」的研討會:一般研討會裡,籌辦人扮演導演的角色,他想拍什麼片就拍、然後邀請你來看;在 Barcamp 裡沒有導演—或者說,老爸老媽哥哥姊姊,只要有心人人都是導演。

你有什麼想發表的東西?這裡給你舞台;早就想凹你朋友傳授一下技巧?要凹就凹到 Barcamp 上來講!在 Barcamp 裡所有的講題,都是現場提出、當場協調排定,人人都是籌辦者。只要你能取得「霸佔」時間空間的權利,要用來討論、分享、共同創作什麼的,都隨你主持。同時分多軌進行的特色,讓你想聽什麼就聽什麼,不必受制於別人。簡言之,這是充滿創意火花與驚喜的研討會,會碰見什麼玩意就只有來了才知道!

台灣還沒有辦過 Barcamp (12/10 這場只有 2 小時、就讓我們稱之為 Barcamp Nano 吧),邀請大家一起來協力舉辦!更多訊息,請直接上 Barcamp Nano Taipei 網站查詢囉!


喂喂,大家要遵守規則啊!老大哥正看著你!

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?)