我写，故我是有一个提高集成商积极性的方法是请他们帮忙指导终端用户说明书的编写。这样能提高项目的接受度，因为这文档是用来索引那些不熟悉代码的人遇到的问题的。核心开发者写文档时倾向于默认读者也是开发者----通常情况下这意味着这文档里到处都是做了诸多可能不正确的关于终端用户如何使用项目的假设下的“内部”语言。 集成商们拿着你的代码与现实里的终端用户打交道。因而他们能带来可导向诸多场景的使用情形和实例。他们崭新和独特的视角能指出那些核心团队没碰到过的可用性问题。毕竟，他们没有埋头代码堆里六个月之久。将集成商们的实战经验结合到你的终端用户文档里，能为你带来更多的集成商，进而使项目和社区能取得长足发展。 了解你的集成商你可以故意迎合你的集成商。组织一两次视频短会，请集成商们也参加，然后跟进他们的发言。跟他们扯到你们要加新组件时需要些什么。忽悠他们帮你测试某个新的涉及用户友好的特性。这真的如你想的那样是用户友好的么？为什么？ 听听他们关心的是什么。如果你的项目是一个内容管理系统，可能你们的所见即所得编辑器对某每天都要用的MarCom部门太复杂了----他们需要一个简单但又容易定制的东西。这种需求通常会为核心开发者带来很大的问题。改变编辑器的话能不能使项目更好用、更受用户欢迎呢？ 作为集成商我组织并参加了一些关于一个我最喜欢的项目的视频短会，在与开发者的交互中，我发现我对项目的整体认知大大提高了。因此我能提出一些关键问题。通常情况下，这些问题会孵化出一组新的特性或功能，这是参与短会前无法预料的。 进两步退一步可以理解开发者是倾向于往项目里加新特性的。在当下，向后兼容是前提。但是确实是这样的么？ 集成商们通常一而再的被警告不要对核心代码进行定制，因此我们（开发方）能方便的帮客户升级到最新版。我们被这样告知：搁置你的定制。然后我们乐呵呵的执行。 用新的样式主题或者更好的文件系统对于开发者们和项目领导来说是振奋人心的。但不幸地，对于集成商来说，如果不能对一个采用旧版本的站点进行更新，这个新版是没用的，不管它是多么漂亮。不向后兼容意味着我们（这里指集成商的顾问们）必须向老板说我们不能升级到新版，或者这需要花费大量人力物力将代码库升级到最新。如果想用更新中某个特性的站点必须因此支付大笔费用给顾问们，肯定会使某些人发疯的。 一个看起来很简单的主题或站点管理更新对集成商们来说可能是一场恶梦。在新旧版间引入冲突会疏远集成商们，进而导致（通过购买集成商的产品）使用这项目的组织离你而去。让集成商们参与整个流程、测试新旧版间可能有的冲突，能使他们有动力将可能有麻烦的模块的反馈给你，保住项目细水长流。 改变可以是有益的，有时也是必要的，因为要保证走在最前。导致了分歧和灾难的不是改变或改变本身，而是集成商们没有被告知这会怎样影响到他们的使用习惯。 不通知集成商们就引入激进的样式主题或管理方式是死路一条。他们是根据日常使用情况与用户打交道的，也是基于此日常使用情况觉得怎样好看怎样管理合适。集成商们会弃你而去，你甚至不会知道你这个大改进已经使项目陷入泥潭。 沉默并不是总是一件好的事情。假如你想转移到一种新的方式做一些事情，例如项目模块如何被打包，资产管理方式等等。可以试着介绍他们的时候慢一些并且留下一些原来的方式作为用户适应过程中的可选项。包括集成商在做重大的决策时，他们会奖励你通过更多的采纳和强大的用户群。 关于作者： Donna M Snow 是一位硅谷移民，当前住在拉斯维加斯。是一位有着超过15年同开源打交道的集成商和设计者。并且有着同管理和开发团队打交道的第一手经验。她从事的技术包括Zope,Plone,Django,Drupal,ModX,Pimcore,WebGUI和WordPress.当她没有被一个新项目缠身的话，她便狂热的在本周视频游戏中练一些toon。 英文原文：Improve Your Open Source Project Adoption by Catering to Integrators |
