在管理自己的开源项目PencilBlue的过程中，我最喜爱的部分就是能够与来自世界各地的参与者们 交流互动。在项目刚刚启动初始阶段，开发团队只有两位成员，但几个月的时间过去之后、我们的贡献者数量开始出现持续增长。这不禁让我开始思考如何才能扮演 一位合格的项目维护人员，又该怎样保证团队顺利引导项目在未来的几年当中始终平稳运行。
时至今日，全世界到底有多少技术人员在为开源软件作出贡献？如果GitHub的用户数量可以作为参考的 话，那么开源社区的整体规模已经超过了850万人。这是个巨大的数字，代表着那些有能力而且有意愿为开源事业提供助力的参与者。顺带一提，这些数字甚至还 没有算上那些面向克隆版本或者匿名下载发行版的贡献群体。如今，我们已经了解到开源社区的可观受众，那么如何才能让他们对自己的项目感兴趣呢？
要管理好一个开源项目，归根结底需要做好以下三件事：
- 发展愿景
- 执行流程
- 项目印象
发展愿景
开源项目必须拥有一套明确的发展愿景。我曾经在北卡罗来纳州召开的FOSS Fair大会上向几位与会者征求过意见，询问他们：“在开始或者参与到某个开源项目的贡献之前，您会如何做出决 定？”他们给出的答案出奇地一致：“我觉得很烦，而且希望能够解决目前面临的问题。”大家正在试图解决的问题通常也会给其他用户带来困扰。我们往往乐于加 入到那些有助于解决自身实际问题的开源软件项目当中。理由很简单，因为希望使用这款软件或者考虑为其作出贡献的技术人员希望能确保项目团队的发展目标能够 与他们的思路保持一致，而不仅仅是单纯满足他们当下的迫切需要。实现这项要求的最简单方式，就是在自述文档当中向大家解释我们的发展愿景。“我目前只达到 了既定发展目标的20%，而且整个过程并不轻松，但这是我为项目定下的发展目标。”不用担心，这样的亲民表述完全可行，毕竟每项工作都有很长的发展道路要 走，最重要的是帮助自己以及潜在参与者确定前进方向。
不过单单公布这样的发展愿景显然还太过粗放。我们接下来有必要与潜在参与者们定期进行对话，并探讨接下来的几个月项目将冲击哪些阶段性目标——不用太多，少点也可以。如果大家制定出了明确的路线图，那么追踪并展示项目进度将变得更为轻松。
构建一套路线图
就在去年，我们构建起一套基础性路线图、用于指导在2014年第四季度内应该解决哪些问题。其实际效果 非常理想，因为这样一来、我们几乎用不着再为突如其来的特定功能而忙得不可开交了。不过，我们也确实在自己的路线图当中建立了一些特殊的目标及实现日期。 当用户们的反馈纷至沓来时，其要求往往与既定目标间存在偏差，这就迫使我们重新设定具体时间点。长期路线图的存在使我们更倾向于选择瀑布式流程而非敏捷开 发思路，而且虽然我个人并不想就此过多作出争论，但我得说采取相对时间进程规划在我们的项目当中取得了更理想的收效。举例而言，在路线图中规定某项媒体服 务应该在十二月完成效果更好，但将其具体规定在十二月的第二周则往往会与实际过程产生冲突。
获取用户反馈
决定项目的未来走向往往是件困难的工作。在起步阶段，大家只需要遵循自己的思路推进工作即可。然而随着 贡献者以及/或者用户群体的不断扩大，我们往往会发现自己遵循的是群体意志、而非个人对于项目的喜好或者设定。毕竟我们的项目必须能够满足用户的需求，而 不单单是为了取悦自己。这又是我在项目发展的几个月后学到的另一项经验。我们推出了一套自以为已经算是功能齐全的CMS，但用户却在反馈中提到“嘿，如果 其中还能……那肯定很酷”。这样的反馈非常重要，因为这意味着人们在真正使用我们的开发成果，或者至少进行了尝试。这可能会与我们自己的既定发展愿景产生 冲突，但如果这样的要求多次出现，请各位千万不要轻易忽视。客户永远是对的，而我们则必须将对方的要求纳入考量范围，从而确保项目的发展方向与他们的利益 保持一致。
#p#
执行流程
在保持原有发展愿景的同时维护好贡献者群体并不是件容易的事。大家有时候不得不作出一些与参与者风格完 全不同的差异性决策。为了尽可能避免这类状况的出现，最重要的是制定一套切实可行的pull request、问题交流以及设计模式强化流程。执行流程往往非常枯燥——其枯燥程度甚至超过了向每一位用户解释当前项目的既定目标。但这属于“必要之 恶”，只有实现了这一点、我们的代码才能具备应有的可维护性。
大家不妨回想一下，自己在一周当中有多少次是在为项目主干提交贡献、而非功能分支？我自己得首先承认，我在这方面做得不好、每周至少会出现几次有违这一思路的状况。在通常情况下，这类问题一般出现在插件等层面而非平台核心。
这是一大需要努力规避的问题，而且相信大家也一定听说过那些所谓流氓程序员的家伙。他们拿出的开发成果 确实令人印象深刻，但要将其纳入项目、却往往意味着项目中的其他成员需要为此付出代价。解决的***办法就是实行一套标准，为每位贡献者及/或用户设定对应 职责。以下列出的虽然看似小事，但却能够切实帮助我们缓和流程程序员带来的负面影响：
- 为我们打造出的每项功能或者特性建立一套分支方案。
- 每套分支的名称都应包含顺序编号。
- 确保所有单元性测试都针对主版本以及分支版本分别运行。
- 尽量不要将自己的pull request加入其中。如果测试覆盖率较为理想，那么小型团队可以直接通过。
- 将我们自己的pull request视为一种学习经验。思考自己为什么要以特定方式完成某项任务。不管其他人怎么看，为每个争议点写下三行注释绝对能够起到良好的效果。这意味着大家既能够完成复杂的任务，同时也可以在未来规避“那时候我到底在想什么？”之类的窘境。
这些小事看似无关紧要，但却能够切实帮助贡献者承担起各自责任，从而保证项目中的每位成员都能与项目的发展愿景保持同步及一致。
#p#
项目印象
现在让我们假设自己正在两个非常相似的项目之间进行选择，那么各位如何选出那个值得我们接下来为其付出 大量时间与精力的胜出者呢？我在评估包括PencilBlue在内的众多项目时，这个问题始终困扰着我。我希望从不同项目之间找到显著差异，但事实上很多 代码库都能实现同样的效果，因此要想脱颖而出、大家往往需要拿出一点与众不同的特性。老实讲，这涉及到印象概念。我们的网站、文件以及自述文档都要给人留 下很好的***印象，请各位千万别忽略这一点。
作为一位开发者，我个人常常忽视视觉效果的重要性。我想当然地认为自己的代码质量已经突出到能够决定一 切，但在这全部30万行代码中，我们要如何向他人证明自己的结论呢？事实上，参与者们的不断贡献使项目以动态平衡的方式拥有稳定的发展节奏。而这种节奏越 是平稳，项目的生命周期就越是乐观。
每一位项目管理者都需要认同一点：以透明化方式进行问责。
开源项目能够从上游以及下游企业身上得到极大助益。其中大多数企业都能够提供工具，从而在某种程度上帮助我们更好地进行项目开发。
- Travis CI:实现持续集成
- Coveralls:实现代码覆盖率
- Code Climate:实现代码分析
- David:实现相关性分析
每一家企业都能在一定程度上为开源项目提供服务方案。它们同时也以提供考量指标的方式支持透明化需求。 利用这些指标，我们能够更加明确不同角色对于项目质量的影响以及划分。作为一项简单的加法，只要我们的代码能够切实帮助他人解决问题、那么用户对项目的信 心自然会获得提升。人们会给出下面的反馈，并乐于加入进来以共同完成项目的共同发展目标。
我曾经读到一篇博文，其中提到我们每个人都能够单独编写出一套轻量级GTK MP3播放器，但如果大家能够聚焦在一起、则可以搞出一些真正拥有传世价值的出色成果。如果我们能够向其他人展示自身项目的发展方向、告诉我们如何才能参 与进来并向他们证明自己的技术实力，那么这些群体智慧资源将为项目所用、并最终推动项目向着既定目标稳步前行。
原文链接：http://opensource.com/business/15/5/what-i-learned-managing-open-source-cms-project
原文标题：What I learned managing an open source CMS project
