通過迎合整合商來提高你的開源專案使用率

　　在軟體生態中，有一類特殊的佈道者，他們與那些樂意將開源工具整合到自己的產品中的組織合作。這些“整合商”（有時叫增值經銷商或電腦顧問）能促成在某次交易使用某軟體，因為他們是無直接銷售合約的可信賴的第三方。如果你能找到這些人，並吸引住他們，你的專案今後的發展就有了強有力的保證。

　　他們是一個開源專案能有的最佳夥伴。一旦整合商看上某個開源專案，他們就會想知道關於它的一切。他們會迷上那些讓他們過得更好的（即：幫助他們更快地保質交付）專案，保證他們的選民每天都能安安全全、沒麻煩和放心。

　　得到滿足的整合商們會幫忙推銷你的專案，遊說他們的客戶使用，跟他們的合夥人說某某專案如何使他們的工作大為改觀。相應地，如果整合商們覺得自己沒有得到應有的重視，下至開發者、設計師，上及專案領導者都將會發現除了自己以外完全沒有人在用這個專案。

　　寶貝，樂得寵你

　　整合商們願意關注你的專案。在很多情況下，那些人（跟他們所在的公司）的工作就是針對某商業需求向他們的客戶提供一個穩定且可靠的解決方法。他們跟任何諮詢顧問----特別是那些收費固定的一樣，他們要的就是能正常跑起來的、方便定製的且收費實惠的工具。開源專案對這些人一直都很是受用。

　　當整合商們在你的專案嚐到大甜頭時，他們就會四處推薦。他們會將你的專案推給他們的老闆呀、合作伙伴呀、客戶呀，甚至坐飛機時身邊的某底層高管。

　　嚐到甜頭的整合商通常是專案和社群的福音。他們是潛在的開發者，每天帶著你的程式碼衝進現實世界中的電子商務和企業裡。他們代表終端使用者的需求，因為他們用你的專案實現軟體裡的功能。那同樣帶給他們更多的經驗，因為他們用這軟體可以解決多種型別的問題。

　　這同樣給整合商們一個參與專案同時的秀自己能力的機會。如果他們進行程式碼定製，他們就會不時來IRC頻道遊蕩或者參與線上討論。對於有經驗的顧問，這不失為一個發掘潛在客戶的極好的方式----想用但沒用過又沒時間或專業人士來做定製的老闆們很容易就會直接去找那些吹自己是這方面的專家的整合商。也就是說整合商們也得出現在討論區和郵件列表裡。（實際上我就是在SmartBear上碰到我的編輯的。）

　　適當地向整合商們表示謝意，關注他們給專案帶來的東西。那怕這些人不會像你的核心團隊那樣在GitHub上頻繁提交，整合商們能決定專案能否盈利，因為他們能左右專案用在哪裡以及怎麼用。問問他們哪些功能最有用，哪些特性不夠直觀，有哪些挑戰。測試的時候也讓他們參與。

　　倘若哪天眾口難調，找到在整合商的需求和維護專案完整間的折衷點是你繼續保持專案----和它的社群----穩定且符合市場需求的關鍵。

　　我寫，故我是

　　有一個提高整合商積極性的方法是請他們幫忙指導終端使用者說明書的編寫。這樣能提高專案的接受度，因為這文件是用來索引那些不熟悉程式碼的人遇到的問題的。核心開發者寫文件時傾向於預設讀者也是開發者----通常情況下這意味著這文件裡到處都是做了諸多可能不正確的關於終端使用者如何使用專案的假設下的“內部”語言。

　　整合商們拿著你的程式碼與現實裡的終端使用者打交道。因而他們能帶來可導向諸多場景的使用情形和例項。他們嶄新和獨特的視角能指出那些核心團隊沒碰到過的可用性問題。畢竟，他們沒有埋頭程式碼堆裡六個月之久。將整合商們的實戰經驗結合到你的終端使用者文件裡，能為你帶來更多的整合商，進而使專案和社群能取得長足發展。

　　瞭解你的整合商

　　你可以故意迎合你的整合商。組織一兩次視訊短會，請整合商們也參加，然後跟進他們的發言。跟他們扯到你們要加新元件時需要些什麼。忽悠他們幫你測試某個新的涉及使用者友好的特性。這真的如你想的那樣是使用者友好的麼？為什麼？

　　聽聽他們關心的是什麼。如果你的專案是一個內容管理系統，可能你們的所見即所得編輯器對某每天都要用的MarCom部門太複雜了----他們需要一個簡單但又容易定製的東西。這種需求通常會為核心開發者帶來很大的問題。改變編輯器的話能不能使專案更好用、更受使用者歡迎呢？

　　作為整合商我組織並參加了一些關於一個我最喜歡的專案的視訊短會，在與開發者的互動中，我發現我對專案的整體認知大大提高了。因此我能提出一些關鍵問題。通常情況下，這些問題會孵化出一組新的特性或功能，這是參與短會前無法預料的。

　　進兩步退一步

　　可以理解開發者是傾向於往專案里加新特性的。在當下，向後相容是前提。但是確實是這樣的麼？

　　整合商們通常一而再的被警告不要對核心程式碼進行定製，因此我們（開發方）能方便的幫客戶升級到最新版。我們被這樣告知：擱置你的定製。然後我們樂呵呵的執行。

　　用新的樣式主題或者更好的檔案系統對於開發者們和專案領導來說是振奮人心的。但不幸地，對於整合商來說，如果不能對一個採用舊版本的站點進行更新，這個新版是沒用的，不管它是多麼漂亮。不向後相容意味著我們（這裡指整合商的顧問們）必須向老闆說我們不能升級到新版，或者這需要花費大量人力物力將程式碼庫升級到最新。如果想用更新中某個特性的站點必須因此支付大筆費用給顧問們，肯定會使某些人發瘋的。

　　一個看起來很簡單的主題或站點管理更新對整合商們來說可能是一場惡夢。在新舊版間引入衝突會疏遠整合商們，進而導致（通過購買整合商的產品）使用這專案的組織離你而去。讓整合商們參與整個流程、測試新舊版間可能有的衝突，能使他們有動力將可能有麻煩的模組的反饋給你，保住專案細水長流。

　　改變可以是有益的，有時也是必要的，因為要保證走在最前。導致了分歧和災難的不是改變或改變本身，而是整合商們沒有被告知這會怎樣影響到他們的使用習慣。

　　不通知整合商們就引入激進的樣式主題或管理方式是死路一條。他們是根據日常使用情況與使用者打交道的，也是基於此日常使用情況覺得怎樣好看怎樣管理合適。整合商們會棄你而去，你甚至不會知道你這個大改進已經使專案陷入泥潭。

　　沉默並不是總是一件好的事情。假如你想轉移到一種新的方式做一些事情，例如專案模組如何被打包，資產管理方式等等。可以試著介紹他們的時候慢一些並且留下一些原來的方式作為使用者適應過程中的可選項。包括整合商在做重大的決策時，他們會獎勵你通過更多的採納和強大的使用者群。

　　關於作者：

　　Donna M Snow 是一位矽谷移民，當前住在拉斯維加斯。是一位有著超過15年同開源打交道的整合商和設計者。並且有著同管理和開發團隊打交道的第一手經驗。她從事的技術包括Zope,Plone,Django,Drupal,ModX,Pimcore,WebGUI和WordPress.當她沒有被一個新專案纏身的話，她便狂熱的在本週視訊遊戲中練一些toon。

　　英文原文：Improve Your Open Source Project Adoption by Catering to Integrators