运作开源项目的一点经验
openkk 13年前
<p> 英文原文：<a href="/misc/goto?guid=4958331740504616993" target="_blank">Thoughts on Running an Open Source Project</a></p> <p> 上周我在 PHPUK 上面讲了一些关于开源项目的内容。我想把它们整理一下都记录下来，以免忘记。也许我不太适合来给出一些这方面的建议，但这些都是我运营 <a href="/misc/goto?guid=4958331741482884145" target="_blank">joind.in</a> 的一些真实、重要的总结。</p> <p style="text-align:center;"><img alt="运作开源项目的一点经验" src="https://simg.open-open.com/show/0045a03e7e40a417a7da1f7f42374561.gif" width="399" height="246" /></p> <p> <strong>社区（Community）</strong></p> <p> 你喜欢一个项目，分享了它的代码，并且公布了它，这就算是开源项目吗？在我看来这不是，开源项目必须有一个社区。作为兴趣，你这么做可以，但是你想要其他人也参与这个项目，事情就大不同了。</p> <p> 为了让别人参与贡献，你必须建立一些基础设施，可以让别人能够顺利沟通，看到项目的进展。作为项目的负责人，你需要管理这些基础设置。 Joind.in 使用 google groups 的邮件列表，问题跟踪系统（atlassian 为开源项目提供免费的授权）以及 IRC 频道。我们也有一个博客，以及 推ter 账户来发表公开的声明。我们使用了多个邮件列表，外联、功能、开发。这样就可以让不同的人选择自己感兴趣的信息，而不会被其他信息淹没。</p> <p> 如果你的项目还不是很有名，你需要通过博客，推ter，stack overflow 等各种渠道来让人们知道它。</p> <p> <strong>说明文件（README）</strong></p> <p> 在项目能获得其他人的贡献之前，你首先要保证其他人能顺利的配置你的项目。你最好在网页，wiki，博客，以及项目中都有 README 信息，因为你不知道人们习惯从哪里看这些信息。</p> <p> <strong>项目规划（Roadmap）</strong></p> <p> 有一个清晰的项目规划是非常有用的。当用户给你提出一些新功能的时候，你可以说“it's on the roadmap”，或者让他们去邮件列表讨论。人们也知道你们正在干什么。</p> <p> <strong>贡献代码（Code Contributions）</strong></p> <p> 这一点有点复杂。大部分的开源贡献者只对他们感兴趣的东西感兴趣，其他的功能或者系统的其他部分很难引起他们的兴趣。但是恰恰其他部分是系统的 关键部分。还有，作为项目负责人，你需要及时审核，测试，合并，部署这些贡献的代码。当某些贡献不能被采纳的时候，你需要告诉别人为什么，以及如何改进。</p> <p> 以我的经验来看，区分真正有用的贡献，以及一般般、没用的贡献是比较困难的。有可能那个贡献者提交了代码以后就消失了，剩下你来维护这个代码。这个问题似乎只能靠直觉去解决。你能做的就是诚恳的对待贡献者，说出你心里真实的想法。</p> <p> <strong>透明化（Transparency）</strong></p> <p> 对我来说，这是运营开源项目最重要的一点！人们能看到代码，能看到问题列表，邮件列表，甚至持续集成服务器。我可以向人们求助，指出哪段代码不工作。有时候，在我还没有意识到问题的时候，就会有人跳出来指出我的错误。</p> <p> 对于和我一起工作的人来说，他们可以看到哪些“pull request”是开放的，谁评论了什么，哪些代码在什么时候被采纳了。我会提交我参与的所有分支到 githut。所以当有人问我一个功能的进度的时候，我往往直接告诉他们最新的版本号。</p> <p> 把项目的所有东西都拿出来给人看有点像是在熨烫一件脏衣服，让人有点不适。但是这样做的好处是你可以听到各种各样的建议。好几次我在 推ter 上贴出了一个 bug 链接寻求帮助，有不少人去留言，给建议，也有人直接去测试代码。</p> <div></div>