原来有理论分析的...好哪！

---------- Forwarded message ----------
From: lvs <lvscar在gmail.com>
Date: 2008/5/20
Subject: [kspeg:1059] 何能使自由軟體計畫存活於麻煩人物之中?
To: kspeg在googlegroups.com






Sent to you by lvs via Google Reader:


何能使自由軟體計畫存活於麻煩人物之中?<http://people.debian.org.tw/%7Echihchun/2008/05/20/how-open-source-projects-survive-poisonous-people/>
via Rex's blah blah blah <http://people.debian.org.tw/%7Echihchun> by Rex
Tsai on 5/19/08

這其實是去年就聽過的主題，不過近來又再次接觸到所謂「麻煩人物」的攻訐，因此特意整理此段演講分享社群中人參考。也作為內省之用。

基本上，這麼一些人長年以來到處與人唱反調，

   - 若你辦了協會，他會質疑你立意不佳。
   - 若你舉辦了票選活動，他會質疑你好大喜功。
   - 若你參加了票選活動，他會說你灌票，貪圖虛名。
   - 若你不幸被安了社群職位，他會說你沽名釣譽。
   - 若你有幸取了企業或政府資源贊助，他會說你分贓利益。
   - 若你剛刻了一個新軟體，他會說架構全錯，應該依照他的先知卓見重寫。
   - 若你刻了個好用的軟體，他說嫌棄功能不全。該用其他設計健全的軟體。
   - 若你失敗的經營了軟體社群，他會理所當然要你好好反省並影射你無能。
   - 若你成功的經營了新軟體社群，他會批評你政治不正確，號招成員出走。
   - 若你….他會….

可能是透過網路溝通的誤解或短時間內的情緒問題或過度自負或天生心理殘障或後天傷害悲觀或者根本是憤世嫉俗而造成上述的行為。

大體來說，這些行為是有益於社群發展。但問題是這群人基本上拒絕合作。他們願意抱怨，不願貢獻，很多時候根本是個戳樂
(Troller)<http://en.wikipedia.org/wiki/Internet_troll>
，他們以戳你為樂。你要跟他們客觀的分析問題，他們會很主觀的訴求於情緒。你誠心的想聽他們的意見，他們卻說不出個所以然。你邀他們出席聚會，他們會出污泥不染的拒絕參與。你邀他們主辦，他們會說這不是他們的使命。

到頭來，你只是自找罪受的徒勞無功。你甚至無法從討論中找出一點點建設性的意義。於是、於是你得好好的研究一個方法來辨識、管理他們。

這段標題為 "How Open Source Projects Survive Poisonous People" 的演講是由 Ben
Collins-Sussman <http://www.red-bean.com/sussman/> 與 Brian W.
Fitzpatrick<http://www.red-bean.com/fitz/>於 Google
Tech Talk<http://video.google.com/videosearch?q=type%3Agoogle+engEDU&page;=1&lv;=0&so;=1>中所分享。Ben
Collins Sussman 與 Brian Fitzpatick 目前都是 Google 的工程師，兩位長久以來都致力於開發
subversion <http://subversion.tigris.org/> 計畫。

這個主題的基礎參考書是《生產開放原碼軟體，如何經營一個成功的自由軟體計畫》 (Producing Open Source Software, How
to Run a Successful Free Software Project) <http://producingoss.com/>。

若你並非自由軟體開發者也無所謂，讀完整篇文章，你會發現這裡的情境適用於普遍的狀態，包含企業、NGO、社區、社群等。因為，到處都有這樣的人存在。甚至，你也可以找到類似的商業書籍中有相似的處理建議，像是
《成功開發員工潛能的24堂課》<http://www.books.com.tw/exep/prod/booksfile.php?item=0010241474>
(Dealing with People You Can't
Stand<http://www.thericks.com/dpcs/dpcs-index.htm>)、《搞定頭痛人物》（How
to Deal With Difficult People）等書。
生產開放原碼軟體，如何經營一個成功的自由軟體計畫


身為一個想認真瞭解開放原碼 <http://en.wikipedia.org/wiki/Open_source>或自由軟體<http://en.wikipedia.org/wiki/Free_software>的讀者，你肯定已經讀了
Eric S. Raymond <http://catb.org/%7Eesr/>
的教堂與市集<http://www.oreilly.com/catalog/9780596001087/>
，因而學習了所謂市集模式為你的軟體計畫帶了甚麼樣的好處，你大約也從書中習得幾個重要的準則，像是擁有使用者、儘早發表、頻繁發表等等。

不過，教堂與市集中並沒有告訴你該如何經營一個自由軟體計畫。很快你會發現，經營一個自由軟體計畫並沒有你想像中的簡單，除了各式各樣的術語<http://www.catb.org/jargon/>
與文化 <http://www.gnu.org/philosophy/>，你還得學會經營社群與「管理」你的使用者們。

這本由 Karl Fogel <http://www.red-bean.com/kfogel/> 所著作的
《生產開放原碼軟體，如何經營一個成功的自由軟體計畫》 <http://producingoss.com/> 傳授了所有相關的眉角
(訣竅)，主題廣泛的含括了

   - 啟動一個自由軟體專案，包含選擇專案名稱、定義計畫聲明書、計畫之資訊提供與敘述。
   - 技術基礎建設 (溝通管道之郵遞論壇、IRC、Wiki、版本控制系統、臭蟲追蹤系統)
   - 軟體專案計畫之社交行為與政治方法。
   - 資金籌措方式。
   - 溝通技巧，學習對話調性、辨識無禮/理的人、應對難搞的人、運營成長的社群。
   - 軟體套件封裝、發表、分支管理等。
   - 義工管理。
   - 授權、版權與專利等問題。

這本書非常適合剛想踏入自由軟體開發世界的開發者，也適宜任何一位想瞭解如何經營一個自由軟體計畫的讀者。
溝通

Ben Collins Sussman 與 Brian Fitzpatick
的演講主要是著重在《生產開放原碼軟體，如何經營一個成功的自由軟體計畫》<http://producingoss.com/>
一書第六章的【溝通】 <http://producingoss.com/en/communications.html>
。重點在於自由軟體計畫中，該如何辨識所謂「缺德人士」，以及如何驅離他們。

之所以需要遠離缺德鬼的原因在於，自由軟體計畫發展最重要、最有價值的唯一資源是專注參與的義工們。任何一位無恥之徒的行為都可能污染快樂開發社群中的空氣，造成計畫中的義工們分心，甚至放棄參與計畫。

然而任何一個自由軟體計畫都會碰到這樣的人。原因在於領導開發者或協調者，總是必須在權宜的狀態下作抉擇。你得抉擇分支的目標、里程碑目標、修改建議的取捨。麻煩的是，凡是決定總無法令每個人滿意。因此你得準備好接受社群的其他人所給你的挑戰或批評。

然而，大部分的情況下，社群其他成員總是可以透過合理的溝通妥協於主協調者的決策。然而，有另外一群人的反應則不是如此。這群人就是演講中討論的頭痛人物。
頭痛人物

這裡所說的頭痛人物泛指任何使軟體開發受挫的人。若要評估一個自由軟體計畫的活躍度，我們通常會計算所謂的公車指數 (Bus
factor)<http://www.shlomifish.org/philosophy/computers/open-source/linus-torvalds-bus-factor/>，Bus
factor 意指重要開發成員的多寡，指數意義在於萬一火車頭成員被公車撞死，計畫持續的機會有多大。

影響公車係數的變因很多，可能是因為工作內容改變、生活形式的改變、談了戀愛、失戀、生了小孩等等。或者是浪費時間在回應頭痛人物，或者被缺德鬼激怒，因此分心而降低生產力。

最常出現的頭痛人物就是日常即興加入的新手，他們帶著全部大寫或是 'root' 的暱稱闖進 IRC 頻道或論壇，毫無禮貌的要求支援或宣告訴求。

或者是過度熱心的參與者，在演講中，提到一個案例 <http://producingoss.com/en/difficult-people.html>。在
Subversion 的發展期間，大約是 2003
年的最後幾個月，有一位人士回覆每一篇文章，以至於他在當下的排名在頭六名中，然而其他五名都是主要的開發者，而他純粹發信，如此行為嚴重影響其他開發者的產能。這當然也算是一種麻煩人物。

但頭痛人物並不見得是新手，也可能是資深的社群人士，甚至是德高望重的前輩。既然軟體由人寫成，不可避免的總會碰到缺德難搞的人事問題，也並不是成功軟體計畫的主開發者/協調者就是一個容易相處的人，例如
Linus <http://en.wikipedia.org/wiki/Linus_Torvalds> 長久以來就讓
Gnome<http://www.gnome.org/>計畫
很難過<https://lists.linux-foundation.org/pipermail/desktop_architects/2005-December/000390.html>
。

我們必須說，這樣的行為是非常不道德的。

你要知道，開放原碼社群是基於大家對名譽的重視所驅動，隱性的名譽機製為社群中的人提供了一種微妙的壓力系統，驅使人們往正向的方面發展。特別是開源軟體社群名譽壓力系統也拉引了好管閒事之徒的興趣，顯然破壞他人的名譽也是一種賺取名譽的方式。

身為一位自由軟體開發計畫的成員，你應該小心的保護專案的產能，以免計畫被老鼠屎拖累。
辨識

麻煩人物的通常有幾個主要的特徵，你可以依據這些特徵來辨識

   - 惡毒的人
      - 潑冷水、污辱現狀
      - 憤怒的索求
      - 散佈黑函
      - 刻意激怒他人
      - 偏執狂似陰謀論者、拚命指責別人
    - 自負
      - 拒絕承認他人的意見。
      - 以偏概全的主張。
      - 重啟已達成共識的話題。
    - 拒絕合作
      - 很愛抱怨，但不願意修正任何問題。
      - 不願意討論解決問題的構思。

有些人會帶著惡毒的心態踏進你的計畫裡面。他們可能會潑你冷水，將你的成就嫌棄的一文不值。另外一些人，認為你理所當然要提供服務，無論是技術支援或者是活動舉辦，你應該要
*立即妥善的滿足*他的需求。有些人會散佈黑函甚至偏執的在認為計畫後面有某種陰謀，或者刻意的激怒他人。

另外有些人則是過度自負，認為他自己的主張才是正確的，相信任何事情都有正義是非，而他們自然永遠都是正義那一方。最麻煩的是他們以偏概全的訴求，往往會綁架專案的發展方向。或者他們會過份在意每一項討論，老是重提那些已經達成共識的老話題。

另外一些人則純粹拒絕合作，他們只是不希望看到你成功。因此會帶著負面的態度慢慢的污染你周圍的空氣，直到它發出惡臭，鬧走你的成員為止。
處置

你可以發現，其實有許多麻煩似乎都是溝通的問題。事實也是，由於開放原碼社群的對話討論一向都是在網路上進行，偶爾才有面對面的接觸。誤解似乎是多少難以避免的問題。例如，有些文化避免難堪公開的指責，有些文化則痛恨私下批評，你似乎很難判斷陌生人喜歡那一種溝通方式，很容易就會觸怒對方

然而有幾個準則是通用於任何處置方式的

   - 重點 (Comprehead)
      - 保持注意力與專注力 (preserve attention and focus)
    - 防禦 (Fortify)
      - 建立一個建康的社群 (Build a healthy community)
    - 辨識 (Identify )
      - 偵測搬弄是非的跡象 (Look for tell-tale signs)
    - 消毒 (Disinfect)
      - 保持鎮靜與自我立場 (Maintain calm and stand your ground)

在實務上，有幾個事項是在演講中所分享的。其中之一是不要把自己的名字擺進程式碼裡面，因為這會造成自尊膨脹的問題，這似乎是宣示此為你的地盤，外人誤觸的禁忌，這種習慣會妨礙整體計畫的發展與自由，應該有所避免。

此外，應該避免私下溝通<http://producingoss.com/en/setting-tone.html#avoid-private-discussions>
。私下溝通是一件很容易使用的政治工具，透過私下溝通你總是可以比較輕易的做下決策。然而，這樣的行為卻排擠其他人的意見與想法。計畫成長後，你總會不停的為新來的人解釋當初的決策。總之是一種得不償失的手段。

另外則是郵遞論壇的禮儀、重啟舊議題等。特別容易發生於敵對的議題上，偶爾，你會發現有一人不停的重開那些反對他意見的對話。他的目的大約在於持續的張貼再張貼，直到對方疲累放棄，而獲得最終毫無意義的勝利感！

通常你可以很快速的辨識出這種戳樂毒瘤，原則上只要你保持情緒，客觀的進行討論通常可以達到有建設性的具體結論。然而，更多時候，戳樂會惱羞成怒的激動不已，甚至出口傷人。這種情況下，如果沒有提早為社群建立一個健康的政策防護機制，你也只能被動的請社群公斷啦。

雖然這篇文章是為了避免麻煩人物所寫，但是有時候這些人性問題也會出現在社群經營者身上。根據 Rober Kaye
的意見<http://www.oreillynet.com/conferences/blog/2006/07/oscon_how_open_source_projects.html>
，無論你是參與者或經營者，都必須具備同理心，以及以下的態度，才能在社群中廣受歡迎

   - 禮貌 (Politeness)
   - 尊重 (Respect)
   - 互信 (Trust)
   - 謙卑 (Humility)

缺乏以上態度，你也可能會犯了過度自負的毛病，而做了不受社群歡迎的錯事呢。這篇短文大約四千字主要參考由 Ben
Collins-Sussman<http://www.red-bean.com/sussman/>與 Brian
W. Fitzpatric <http://www.red-bean.com/fitz/>的演講 - "How Open Source Projects
Survive Poisonous
People<http://video.google.nl/videoplay?docid=-4216011961522818645>"
以及 由 Karl Fogel <http://www.red-bean.com/kfogel/> 所著作的
《生產開放原碼軟體，如何經營一個成功的自由軟體計畫》 <http://producingoss.com/> 一文。敬請收聽以下演講




Things you can do from here:

   - Subscribe to Rex's blah blah
blah<http://www.google.com/reader/view/feed%2Fhttp%3A%2F%2Fpeople.debian.org.tw%2F%7Echihchun%2Ffeed%2F?source=email>using
   *Google Reader*
   - Get started using Google
Reader<http://www.google.com/reader/?source=email>to easily keep up
with
   *all your favorite sites*


  --~--~---------~--~----~------------~-------~--~----~
邮件发自 Google 列表"KsPEG"~金山过程改进组:
发言: kspeg在googlegroups.com
退订: kspeg-unsubscribe在googlegroups.com
团队列表: http://groups.google.com/group/kspeg
团队Trac: http://trac.rdev.kingsoft.net/kspeg
团队SVN: http://doc.rdev.kingsoft.net/matter
内部维基: http://wiki.rdev.kingsoft.net/moin/DMC
-~----------~----~----~----~------~----~------~--~---




-- 
'''过程改进乃是开始催生可促生靠谱的人的组织!
PI keeps evolving organizations which promoting people be good!
'''http://zoomquiet.org
Pls. usage OOo to replace M$ Office. http://zh.openoffice.org
Pls. usage 7-zip to replace WinRAR/WinZip. http://7-zip.org
You can get the truely Freedom 4 software.
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: http://www.zeuux.org/pipermail/zeuux-universe/attachments/20080521/d65b7526/attachment-0001.html