怎样维护成功的开源项目

开源可不仅仅是将代码扔到网上就万事大吉了，将开源项目变成能让自己引以为豪的东西才算成功。那么，你需要注意哪些方面呢？

写好指导性文字

每一个开源项目有三样东西是少不了的：项目目标和方法的简要说明、如何参与和授权许可。最好把它们预先放在一个README文件里。

我还喜欢加入一个名为“组织和理念”的部分，概括项目如何构成，各个东西都在哪儿，代码是怎样写的，需要哪些类型的测试，性能与简洁性怎么平衡。（详见案例unstdlib.py）

接下来是“贡献”部分，要说清楚开发者怎样开始参与项目，以及将代码成功合并进项目的所有步骤。urllib3的贡献部分，已经被其他好几个项目采用了。

查看还没有解决的问题，或者新开一个问题来讨论某个功能设想或bug。
把urllib3库添加到Github上开始进行更改。
编写测试来显示这个bug是固定的或者它的功能是否正如预料的那样运行。
发送一个pull请求，干扰保持器，直到它被合并到一起并发布。

最后，每一个开源项目需要有一个授权许可，如果没有许可，那就意味着版权属于开发者，其他人需要明确的许可才能使用。

态度

对待用户和贡献者有好的态度是至关重要的，偶尔会有类库用户误闯到你的问题跟踪器里，并且很愚蠢的在文档编制里写了命令。那该怎么办？

1.你可能会斥责用户，因为他们的鲁莽行为浪费了你很多时间。

2.你也可以耐心的向用户解释他们所误解的，一旦他们进一步理解问题，那么邀请他们发送一个pull请求为其他用户改善文件编制。

有些团队可能因为某些原因选择第一种态度，也许是因为他们觉得维护人员做的是一件吃力不讨好的工作，还要承担丢失贡献者的责任。不过先来检查一下这两种态度所带来的效果。

当你责怪用户的时候，毫无疑问会丢失用户，还意味着丢失了他成为你的贡献者的可能性，说不定这种影响会传播到其他人那里，一传十十传百，别人可能真的认为你的文件编制里有问题。这无异于搬石头砸自己的脚。

但只要你有足够的耐性，礼貌待人，鼓励他们为项目出力，他们就会很有斗志。说不定他们就能在项目上做出重大影响，彻底改变现状。

在工作中保持良好的态度可能是比较难的一部分，因为每个维护人员的情况是不一样的，但是，礼貌、积极和进步是至关重要的。不仅仅是对于你和项目，还有整个团队。

营销

也许你能写出最有用最完美的代码并实现代码运行，但是你对技术社区的贡献会因为你允许人们重复使用你的代码而无限放大。

找到你的项目，站在SEO的位置思考整个项目，为项目选取一个带有重要关键词的相关名称。README里的项目描述和第一段应该是项目的简单总结，里面所有的重要关键词都是之前人们所搜索的。

urllib3——带有线程安全连接池的Python HTTP类库，支持文件公布，智能友好等等。

Python，HTTP类库，线程安全，连接池，文件公布，这些都是当人们遇到要使用Python的标准HTTP类库（urllib、urllib2、httplib）的时候所需要的。

一旦准备好了README，就要确保能够生成一些文档。发布在Read the Docs将是一个很好的选择。包括一些代码样本和便于采纳的详细菜单。

为你的受众提供技术支持，建立一些StackOverflow警报过滤器，甚至可以过滤掉谷歌的奇怪论坛警报。如果你推自己的软件，这个警报会帮助你添加一个你就是开发者的免责声明。

考虑合作关系，为框架编写一个可以使用你自己工具的插件，并观察这些工具能否将框架连接到README。两年前，我和Kenneth Reitz在不同的场合进行交谈之后，我们决定合作。虽然urllib3已经是非常流行的Requests类库的核心，但远远落后于当时的httplib2。当我和Kenneth Reitz合作之后，我们两个团队的成果远超出了我们的想象。此时，在我们的合作之间建立明确的规则和界线是非常重要的，这个规则后来也帮我们在合作当中建立了深厚的友谊和相互尊重打下了基础。

充足的时间，我的一个比较受欢迎的项目花了至少一年的时间。这在营销人员看来是懒散的表现，但如果你按照文章里说的那样去做，正确的完成每一件事，那么营销人员会不请自来。

技术社区

想要一个人做完所有的事是很难的，特别是很多人都期待着你能拿出好的作品。

抓住任何一个机会寻找pull请求。集思广益的力量是无穷大的，所以无论何时何地我都会向技术社区的成员寻求意见，他们常常说的RFC我从来没听过，甚至有的时候他们会主动研究前端主题。

大胆寻求帮助，我本打算花数小时致力于开源工作，但有时候日程安排忽略了或是我忘记了关于pull需求。我鼓励人们参与并在我需要更多的人参与的时候提醒我。在更复杂的分支,它有助于要求志愿者代替维护人员来处理这个问题,直到它准备好合并。

尽可能的自动化，去年，我们为urllib3设置了100%的测试覆盖规则，这使得我们的项目维护更加简单。任何功能都必须经过测试，否则它可以在没有通知的情况下被删除。这意味着每一个pull请求必须在合并之前完全测试。