在软件生态中，有一类特殊的布道者，他们与那些乐意将开源工具整合到自己的产品中的组织合作。这些“集成商”（有时叫增值经销商或电脑顾问）能促成在某次交易使用某软件，因为他们是无直接销售合约的可信赖的第三方。如果你能找到这些人，并吸引住他们，你的项目今后的发展就有了强有力的保证。
他们是一个开源项目能有的最佳伙伴。一旦集成商看上某个开源项目，他们就会想知道关于它的一切。他们会迷上那些让他们过得更好的（即：帮助他们更快地保质交付）项目，保证他们的选民每天都能安安全全、没麻烦和放心。
得到满足的集成商们会帮忙推销你的项目，游说他们的客户使用，跟他们的合伙人说某某项目如何使他们的工作大为改观。相应地，如果集成商们觉得自己没有得到应有的重视，下至开发者、设计师，上及项目领导者都将会发现除了自己以外完全没有人在用这个项目。
宝贝，乐得宠你
集成商们愿意关注你的项目。在很多情况下，那些人（跟他们所在的公司）的工作就是针对某商业需求向他们的客户提供一个稳定且可靠的解决方法。他们跟任何咨询顾问—-特别是那些收费固定的一样，他们要的就是能正常跑起来的、方便定制的且收费实惠的工具。开源项目对这些人一直都很是受用。
当集成商们在你的项目尝到大甜头时，他们就会四处推荐。他们会将你的项目推给他们的老板呀、合作伙伴呀、客户呀，甚至坐飞机时身边的某底层高管。
尝到甜头的集成商通常是项目和社区的福音。他们是潜在的开发者，每天带着你的代码冲进现实世界中的电子商务和企业里。他们代表终端用户的需求，因为他们用你的项目实现软件里的功能。那同样带给他们更多的经验，因为他们用这软件可以解决多种类型的问题。
这同样给集成商们一个参与项目同时的秀自己能力的机会。如果他们进行代码定制，他们就会不时来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
译文连接：http://www.oschina.net/translate/improve-your-open-source-project-adoption-by-catering-to-integrators
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/43005.html