管理自己的开源项目PencilBlue，我最喜欢的部分是能够与来自世界各地的参与者互动。在项目的初始阶段，开发团队只有两名成员，但随着时间的推移，我们的贡献者人数不断增加。这不禁让我思考如何扮演一个合格的项目维护者，如何保证团队在未来几年能够顺利的引导项目顺利运行。今天，世界上有多少技术人员在为开源软件做出贡献？如果以GitHub用户数作为参考，开源社区整体规模已经超过850万人。这是一个巨大的数字，代表着那些有能力也愿意为开源事业做出贡献的人。顺便说一句，这些数字甚至没有考虑克隆或匿名下载发行版的贡献者社区。既然我们了解开源社区的庞大受众，我们如何让他们对我们的项目感兴趣？要管理好一个开源项目，归根结底需要做好以下三点：开发愿景执行流程项目印象开发愿景开源项目必须要有清晰的开发愿景。我曾经在北卡罗来纳州的FOSS博览会上询问了几位与会者的意见，“在开始或为开源项目做出贡献之前，你会如何做出决定？”答案出奇地一致：“我觉得这很烦人，希望能够解决我面临的问题。”人们试图解决的问题通常也会困扰其他用户。我们常常乐于加入有助于解决我们自己实际问题的开源软件项目。原因很简单，想要使用该软件或考虑为其做出贡献的技术人员希望确保项目团队的开发目标符合他们的想法，而不仅仅是他们眼前的即时需求。实现这个需求最简单的方法就是在readme文档中向大家说明我们的发展愿景。“我目前只完成了既定发展目标的20%，整个过程并不轻松，但这就是我为项目设定的发展目标。”别着急，这样亲民的说法是完全可行的，毕竟每一项工作都有很长的路要走，最重要的是帮助自己和潜在的参与者确定前进的方向。但是，单独公布这样的发展愿景显然过于宽泛。有必要与潜在参与者进行定期对话，并讨论该项目将在未来几个月内达到哪些里程碑——不要太多，不要太多。如果每个人都有清晰的路线图，跟踪和展示项目进度会更容易。构建路线图就在去年，我们构建了一个基本的路线图，指导2014年第四季度应该解决哪些问题。这样做的实际效果非常好，因为这样一来，我们几乎不必再被一个特定的问题所淹没。弹出的功能。但是，我们的路线图中确实有一些具体的目标和实现日期。当用户的反馈进来的时候，他们的要求往往会偏离既定的目标，这就迫使我们重新设置具体的时间点。长期路线图的存在使我们更喜欢瀑布式流程而不是敏捷开发方法，虽然我个人不想对此争论太多，但我会说采用相对时间表对我们的项目来说效果更好结果。比如在roadmap中写明某项媒体服务应该在12月完成效果更好，但在12月的第二周就写明，往往与实际流程有冲突。获取用户反馈以确定项目的未来方向通常是一项艰巨的工作。在起步阶段，大家只需按照自己的想法推进工作即可。然而，随着贡献者和/或用户社区的不断扩大，我们经常发现自己遵循团队的意愿，而不是项目的个人偏好或设置。毕竟我们的项目一定要能够满足用户的需求，而不是仅仅为了取悦自己。这是我在几个月的项目开发之后学到的又一课。我们推出了我们认为是功能齐全的CMS，但用户的反应是“嘿，如果有……就好了”。这样的反馈非常重要，因为这意味着人们确实在使用我们的开发，或者至少在尝试。这可能与我们自己既定的发展愿景有冲突，但如果多次出现这样的要求，请不要轻视。客户永远是对的，我们必须考虑到他们的要求，确保项目朝着与他们利益一致的方向发展。#p#执行过程在保持最初的开发愿景的同时，维持一个好的贡献者群体并不容易。人们有时不得不做出一些与参与者风格完全不同的差异化决定。为了尽可能避免这种情况，最重要的是制定一套实用的pullrequest、问题交流和设计模式强化流程。执行过程通常非常无聊——甚至比向每个用户解释当前项目的既定目标还要无聊。但这是一个“必要之恶”，只有做到这一点，我们的代码才能达到应有的可维护性。你不妨回想一下，你一周有多少次向项目主体而不是特性分支提交贡献？我将是第一个承认自己不太擅长这个的人，而且每周至少有几次我会反对这种思路。一般情况下，此类问题一般出现在插件层面，而不是平台核心层面。这是一个需要避免的大问题，相信大家一定听说过那些所谓的流氓程序员。他们提出的进展令人印象深刻，但让他们参与项目通常意味着为项目的其余部分付出代价。最好的解决方案是为每个贡献者和/或用户实施一套具有相应责任的标准。下面列出的看似很小的事情实际上可以帮助我们减轻流程程序员的负面影响：为我们构建的每个功能或特性建立一个分支计划。每组分支的名称应包含序号。确保所有单元测试分别针对主版本和分支版本运行。尽量不要向其中添加您自己的拉取请求。如果测试覆盖率很好，小团队可以直接通过。将我们自己的拉取请求视为一种学习经验。想想你为什么以某种方式完成某项任务。不管别人怎么想，每个论点写三行评论，绝对能做好。这意味着每个人都可以完成复杂的任务，同时避免“我当时到底在想什么？”的困境。将来。这些小事看似微不足道，但实际上可以帮助贡献者承担起自己的责任，从而保证项目的每一位成员都能与项目的发展愿景保持同步和一致。#p#ProjectImpressions现在假设我们要在两个非常相似的项目之间进行选择，那么您如何选择一个值得我们投入所有时间和精力的成功者呢？当我评估包括PencilBlue在内的众多项目时，这个问题一直困扰着我。我预计会发现项目之间的显着差异，但现实是许多代码库可以实现相同的效果，因此要脱颖而出，您通常需要提出一些不同的功能。老实说，这涉及印象的概念。我们的网站、文档和README都需要给人留下良好的第一印象，所以请不要忽视这一点。作为一名开发人员，我个人经常忽视视觉效果的重要性。我想当然地认为我的代码质量如此出色，可以决定一切，但是在这300,000行代码中，我们如何向他人证明我们的结论？事实上，参与者的持续贡献使项目以动态和平衡的方式具有稳定的发展节奏。而且这种节奏越顺畅，项目的生命周期就越乐观。每个项目经理都需要就一件事达成一致：以透明的方式问责。开源项目可以从上游和下游公司中受益匪浅。这些公司大多可以提供工具，以某种方式帮助我们更好地进行项目开发。TravisCI：实施持续集成Coveralls：实施代码覆盖率CodeClimate：实施代码分析David：实施依赖分析每个企业都可以在一定程度上为开源项目提供服务解决方案。他们还通过提供供考虑的指标来支持对透明度的需求。通过这些指标，我们可以更加明确不同角色对项目质量的影响和划分。作为一个简单的加法，只要我们的代码能够真正帮助别人解决问题，用户对项目的信心自然会增加。人们会在下方给予反馈，并乐于加入，以实现项目的共同发展目标。我曾经读过一篇博文，上面说我们每个人都可以单独编写一个轻量级的GTKMP3播放器，但如果我们一起组合，我们可以产生一些具有遗留价值的非常棒的结果。如果我们能向别人展示我们项目的进展，告诉我们如何参与，向他们证明我们的技术实力，那么这些众智资源就会被项目所利用，最终推动项目朝着既定目标稳步推进.原文链接：http://opensource.com/business/15/5/what-i-learned-managing-open-source-cms-project原文标题：WhatIlearnedmanaginganopensourceCMSproject
