本次於奧斯汀召開的OpenStack峰會成為大家交換開源項目管理經驗的絕佳平台。事實證明，在經歷了多年的社區參與及項目貢獻工作之後，我對這方面事務還是有點兒發言權的。
不過，在今天的文章中，我打算以反面視角解讀這一議題，即討論開源項目管理當中不可取的種種作法。
1.給貢獻者們增添煩惱
軟件的開發者與維護者已經很忙了，所以過量的任務分配只會令人更加反感。事實上，開源領域最大的誤解之一就是，管理者往往以為鋪天蓋地的工作能夠增加成員的參與感。這裡說得直白一點，任務太多的話人家可能干脆就走人了。我有位好朋友自2013年開始，就一直在為Ceilometer做出貢獻。他的代碼審查水平相當高，甚至能發現許多旁人意識不到的錯誤。項目管理團隊最終讓他晉升為核心審查員——而非單純交給他更多任務。相信我，正是這種成就感讓更多水平超群的技術人員繼續留在項目當中。
2.只讓人們參與枯燥的工作
在新人加入時，他們的動機往往不盡相同。部分用戶希望通過貢獻實現自身價值，也有些人是抱著學習的目的。但一般來說，人們其實比較抗拒始終接觸最低級的枯燥工作。如果管理者對於底層貢獻者的感受毫不關心，那麼無聊的內容再結合上一條提到的工作強度，肯定會讓很多有志於開源的朋友迅速撤離。
3.不重視點滴貢獻
改個錯字也能算貢獻?重新捋順說明文檔也能算貢獻?這種心態在開源項目中並不罕見，但事實證明這類工作其實同樣具有重要價值。
我個人就曾經在某個項目中負責修復文檔錯誤，並在短時間之內發布了56項補丁、修正了部分bug並添加了些額外的功能。沒人因為這些都是小事而看輕我，我也相信自己的工作確實擁有其價值。
4.為新人們設置過高的門檻
新人在參與開源項目時，其個人技術水平與從業經歷往往千差萬別。而很多管理者則直接給他們設置太過復雜的任務，這會讓很多人遭遇挫折感，甚至覺得自己太笨而默默退出。事實上，我們應當對新人進行技術水平評估(簡單的交流應該能大致摸清其程度)，而後再為其分配力所能及但又有些挑戰的工作。
5.要求人們犧牲自己的個人生活
大多數參與者只會拿出空閒時間進行開源貢獻，這也是種非常健康的發展方式。請注意，不要指望項目成員犧牲個人生活進行貢獻，那樣既不現實也不利於項目的長期發展。另外，過於頻繁的視頻會議乃至IRC會議也會讓人感到厭煩。開源項目應當以人為本，並針對不同成員采取不同的交流及貢獻方式。
6.潛在的行為准則太難融入
隨著社區的發展，總會有種潛在的風格或者行事方式成為其個性標簽。雖然這能讓老鳥們樂在其中，但卻也可能讓新人們望而卻步。誠然，我們沒必要就行為規范整理什麼說明指南。但作為項目管理者，大家最好是能讓團隊在保持個性的同時，充分考慮新人的感受。有事沒事拋出一大堆內部用語或者“梗”，除了妨礙組織規模進一步擴大外真的沒什麼好處。
7.讓非英語為母語的發言者感到毫無參與感
絕大多數開源項目社區會以英語進行交流，而這也成為大家協作的重要前提。然而，我們也應該考慮到部分技術人員來自非英語為母語的國家，這意味著他們可能很難與原有成員順暢溝通，甚至因此受到打擊。面對這種方式，我們可以想想其他的辦法進行替代。例如采用異步溝通方式，以文本為載體發送交流內容。如此一來，對方即可借助翻譯軟件大致理解其中的含義，同時也避免了開口說外語所帶來的緊張感。
8.缺乏遠見，不願放權
這兩項錯誤常見於各類開源項目。事實上，部分貢獻者在加入後會開發新功能並向原有成員尋求反饋意見，這時負責維護的管理者可能意識到自己並不熟悉這部分技術，甚至因此決定退出。必須強調的是，項目的發展願景與圍繞這一點展開的溝通非常重要，這樣我們才能讓各位成員擁有相同的判斷並了解是否應當留在隊伍裡發揮作用。另外，就是應當將部分職責放心交給其他成員，而非全部由自己掌控。補丁審查、子系統設計、錯誤修正以及文檔編寫等都可以由專人負責。通過這種方式，每位成員都能感受到自己的作用與價值，並更為積極地留在項目團隊當中。
9.不承認貢獻者們的成績
為開源項目做出貢獻的方式多種多樣，絕不限於編寫代碼。說明文檔、bug調試、用戶支持、體驗設計、傳播乃至翻譯等等，這一切都是非常重要的工作。因此，我們應當對非技術貢獻予以充分的重視，並在建立團隊成員階層時小心再小心，以免遺漏了任何一類人才。
10.缺少感恩的心態
作為結尾，我要強調開源項目中感恩心態的重要性。這類項目往往是由參與者無償構建而成的，作為管理者我們要為每個人的分享精神喝彩——當然，要用能讓他們直觀感受到的方式!
