运作开源项目的一些经验

英文原文:Thoughts on Running an Open Source Project,编译:oschina

上周我在 PHPUK 上面讲了一些关于开源项目的内容。我想把它们整理一下都记录下来,以免忘记。也许我不太适合来给出一些这方面的建议,但这些都是我运营 joind.in 的一些真实、重要的总结。

社区(Community)

你喜欢一个项目,分享了它的代码,并且公布了它,这就算是开源项目吗?在我看来这不是,开源项目必须有一个社区。作为兴趣,你这么做可以,但是你想要其他人也参与这个项目,事情就大不同了。

为了让别人参与贡献,你必须建立一些基础设施,可以让别人能够顺利沟通,看到项目的进展。作为项目的负责人,你需要管理这些基础设置。Joind.in 使用 google groups 的邮件列表,问题跟踪系统(atlassian 为开源项目提供免费的授权)以及 IRC 频道。我们也有一个博客,以及 twitter 账户来发表公开的声明。我们使用了多个邮件列表,外联、功能、开发。这样就可以让不同的人选择自己感兴趣的信息,而不会被其他信息淹没。

如果你的项目还不是很有名,你需要通过博客,twitter,stack overflow 等各种渠道来让人们知道它。

运作开源项目的一点经验

 

说明文件(README)

在项目能获得其他人的贡献之前,你首先要保证其他人能顺利的配置你的项目。你最好在网页,wiki,博客,以及项目中都有 README 信息,因为你不知道人们习惯从哪里看这些信息。

项目规划(Roadmap)

有一个清晰的项目规划是非常有用的。当用户给你提出一些新功能的时候,你可以说“it’s on the roadmap”,或者让他们去邮件列表讨论。人们也知道你们正在干什么。

贡献代码(Code Contributions)

这一点有点复杂。大部分的开源贡献者只对他们感兴趣的东西感兴趣,其他的功能或者系统的其他部分很难引起他们的兴趣。但是恰恰其他部分是系统的关键部分。还有,作为项目负责人,你需要及时审核,测试,合并,部署这些贡献的代码。当某些贡献不能被采纳的时候,你需要告诉别人为什么,以及如何改进。

以我的经验来看,区分真正有用的贡献,以及一般般、没用的贡献是比较困难的。有可能那个贡献者提交了代码以后就消失了,剩下你来维护这个代码。这个问题似乎只能靠直觉去解决。你能做的就是诚恳的对待贡献者,说出你心里真实的想法。

透明化(Transparency)

对我来说,这是运营开源项目最重要的一点!人们能看到代码,能看到问题列表,邮件列表,甚至持续集成服务器。我可以向人们求助,指出哪段代码不工作。有时候,在我还没有意识到问题的时候,就会有人跳出来指出我的错误。

对于和我一起工作的人来说,他们可以看到哪些“pull request”是开放的,谁评论了什么,哪些代码在什么时候被采纳了。我会提交我参与的所有分支到 githut。所以当有人问我一个功能的进度的时候,我往往直接告诉他们最新的版本号。

把项目的所有东西都拿出来给人看有点像是在熨烫一件脏衣服,让人有点不适。但是这样做的好处是你可以听到各种各样的建议。好几次我在 twitter 上贴出了一个 bug 链接寻求帮助,有不少人去留言,给建议,也有人直接去测试代码。

 

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部