如何建立开源 区

为什么启动开源项目/h3>

　　事实上，启动开源项目与启动其他类型的软件项目并没有什么不同。开源项目的启动，或者是因为某人想开发某个软件，或者是在产品开发中，某人想满足别人的未来需求。在前一种情况下，开发者可能永远不会考虑共享最终成果，而在后一种情况下，开发者会出于某种目的而共享软件。

什么是 区什么开源项目要建立 区/h3>

　　 区就是有共同兴趣的一群人。开源项目和闭源项目都有用户 区，大部分用户不会积极地与 区其他成员互动。而另一方面，无论是开源 区还是闭源 区，都会有 成员愿意更积极地参与，例如， 告 bug、帮助其他用户、撰写文档或进行推广。最活跃的 区成员甚至可以得到回 。例如，微软通过最有价值专家 (MVP) 项目奖励帮助人们充分利用微软技术的用户 区成员。在开源 区中，活跃的成员往往会获得额外的项目访问权和管理权。

　　虽然闭源项 目也有奖励，但通过奖励 区成员而取得项目贡献毕竟有明确限制。由于不能公开验证代码，因此用户无法真正深入项目、解决问题或开发新功能，或者贡献代码。 相反，在开源 区中，信息（代码和文档）可以从任何 区成员流入 区中心，尽管管理者会加以调整。更重要的是，一旦出现任何问题， 区中会有很多“眼球” 盯着它，以便集思广益、群策群力。在闭源项目中，解决某个问题的最多人数总是由受雇的开发者人数决定的。

开源 区的典型发展路线

　　 区创建之初可能非常小，可能只有一两个开发者，几乎没有用户。根据项目的类型，这种情况可能会持续一段时间，甚至几年，在此“孵化期”，初始团队会努力工 作打下基础。Eric Raymond 在《大教堂与集市》中指出，成功的一个必要条件是，开发出可运行、可测试的东西，让游戏继续下去。注意，“可运行”并不意味着完美，甚至可以不完整。“早 发布，多发布”是一条众所周知的开源开发准则，主要是因为这样做可以获得宝贵的早期反馈，帮助项目团队建立自信。因此， 区不应对早期发布存在顾虑或迟 疑；只要能够明确、如实地管理期望值，早期发布将使项目受益良多。

　　软件要最终吸引用户，软件的演示和品牌推广必须让潜在用户相信，该软件与 竞争性产品相比有显著优势。引起用户的兴趣后，必须要降低进入的门槛：例如，安装等简单操作必须非常顺畅。用户注册并不是故事的结尾；从长远来看，还需要 更多开发者的参与，他们至少可以完成少量工作，如果仅依赖个别开发者，他很可能被这些琐碎的工作压垮。开发者可能直接从用户中产生，但也可能来自其他地 方，如为了挑战技术难题、为了声誉，或为提高或展示自己的编程水平而参与到项目中。

　　贤明君主的技术水平不必最强，但 Fogel 认为，他们应该“有辨别好的设计的能力”。但 Fogel 进而指出，他们的主要职责是确保参与者始终相信“团队合作胜过单打独斗”。团队领袖必须有足够的凝聚力，让开发者愿意持续参与项目，只有这样，开发者才会 留下来。这意味着，应适当回 努力工作的人，如给予适当的肯定，或根据开发者的意愿赋予更重要的工作职责。人们已将开源项目管理描述为一项活跃、灵活而低 调的工作。

规避陷阱

　　 区领导者的责任是，确保环境条件始终有利于充分发挥开源的潜力。这样的条件不会自动形成，而需要悉心管理。

　　在 项目早期阶段，最重要的问题可能是如何应对不可避免的支持负担。如果处理不善，至少将导致用户流失，而最坏的可能是创始者放弃项目。要取得成功，领导者最 终必须找到能完成工作的人。雇佣人员是一种选择；另一选择是鼓励用户通过撰写文档和修复 bug 来相互帮助。然而，要做到这一点，首先基础设施必须到位，这样参与者才能在此基础上为项目作出贡献。项目领导者必须积极鼓励参与者作出贡献，同时应确保贡 献是有帮助、高质量的。

　　项目启动后应持续满足成员的需求，这一点很重要。如果项目不再能满足成员的需求，那么那些认为自己的利益未被满足的 成员可能拿走代码库，转而自行开发。这一过程称为分化（“fork”）。需要注意的是，分化不一定是坏事，它可能只是因为 区的部分成员有一些特殊需求， 他们认为自己的需求无法与更广泛 区的需求达到平衡。另一种可能的情况是，已确立的治理模式不再符合项目的最大利益，因此 区决定以新的治理结构进行新项 目的开发。然而，应避免因个人冲突或简单分歧造成的分化，因为此类分化会导致 区分裂，令用户感到困惑。为避免此类分化，项目领导者应努力确保所有贡献者 感觉到他们可以自由参与决策过程，即使最终他们的意见未被采纳。

此分化非彼分化/h3>

　　随着分布式版本控制系统，特别是 GitHub 等托管 站的兴起，“分化”这一术语有了新的含义，表示个人开发者获取己发布代码库的副本，进行更改以满足自己的需求，并往往将更改交回原始代码（称为拉 ‘pull’或合并‘merge’）。这种意义上的分化与前述分化大不相同，前述分化指围绕项目的 区被分割，而不仅仅是代码的分割。

放手

　　为保持 区的健康发展， 开源 区必须能够超越创始人原有的个人兴趣而可持续发展。如果 区在很大程度上依赖于“君主”，那么当领导人离开或退休时， 区也将面临分裂或瓦解的风险。

　　在 大多数 区，甚至是贤明君主模式的 区，创始人以外的其他参与者将在关键决策过程中发挥越来越重要的作用。其必然结果是， 区转向以共识为基础的民主治 理。这种新的模式并不意味着所有决定，甚至是小决定，都由委员会作出。大多数时候，提议是根据“懒惰共识”来决定的，即“沉默表示同意”。对于未能达成共 识的提议，大多数 区坚持采用某种投票形式来决定。

　　这些惯例和程序越复杂，它们在指导新加入者如何参与项目、如何在决策中取得发言权方面就 越重要。新 区可以依赖于逐渐积累、并以邮件列表形式获取的知识体系，但这种知识体系并不总能帮到新加入者，甚至会让他们感到困惑。我们需要的是书面形式 的治理模型，以便将已取得的共识以简明文档的形式呈现。规范化有助于确保 区有自己的生命——独立于任何个人的生命——只要对项目产出的真实的、持续的需 求存在， 区即可延续下去并不断发展壮大。

综述

　　围绕开源软件建立 区可能是一项缓慢而艰巨的工作，其成功取决于很多因 素。然而，没有 区也就没有项目。 区不会自动建立， 区的建立需要悉心管理。所有 区都始于被软件的包装、品牌推广或口碑推荐所吸引用户。一旦有了用 户，不辜负用户的高期望又成为新的挑战。一个繁荣的开发者 区能够满足并超越这些期望，但前提是他的领导者具有凝聚力，能确保参与者不偏离轨道。从长远来 看， 区需要落实开放开发机制，以确保包括创始人在内的关键贡献者离开时，他们的角色可由他合适的人选填补。

相关资源：软件标书范本(技术部分)_软件技术标书-项目管理文档类资源-CSDN文库