将一个项目的代码开源出来很容易，但是将它长久维护下去，并吸引更多人参与，这就比较难了。开发者Jim Cowart结合自身的开源项目维护经验，给出了本文这些建议，希望能为你的开源之路带来一些帮助。
1. 坚持遵循Wheaton法则
Wheaton法则的中心思想是“Don’t be a dick”，意思是不要成为一个不顾别人感受的人。在这里，我想说的是，你要耐心对待你的开源项目的用户。
我以前是一个音乐家，但是后来开始喜欢编写软件。我常常认为我的知识和同事相比就如同瑞士奶酪（千疮百孔），但是很快我发现，每个人与其他人相比在某些方面都存在一些优势和差距。因此，对于那些在某些知识领域不如你的人，要有耐心。
每个开源项目，无论大小，都会产生一个与它相关的文化。当你创造了这样一个文化，也意味着你已经创造了一个空间，供各知识水平的人来交流学习。要知道，能够成为其他人学习新事物路上的一个向导，将是一种荣誉。
2. 选择一个开源许可证
我选择的许可证是MIT。如果必要的话，你可以使用双许可证。你可以参考http://choosealicense.com/网站，或者阅读opensource.org中具体的许可证规范。
3. 不要急于发布1.0版本
你需要一些空间来对项目进行迭代、改进、重构和更改。
如果有人使用了你的v0.2.3版本，那么说明他们认为你的项目中存在的风险是可以接受的，即使项目还在起步阶段。你可以在README或者其他文件中提醒用户该项目还处于实验阶段，并可能随时会更改。
虽然我们都知道标上“1.0”标签在某些时候并不意味着完全可用于生产环境，但是大部分开发者都会有这种感觉。因此，不要急于将项目标记为1.0状态，这将有助于项目后续的改进。
4. 不要害怕重建API（但要负责任地做）
在早期维护postal.js这个项目时，我犯了一个大的错误——没有以我希望的方式重建API，现在回想起来，这样做似乎使得项目开发工作滞后了几个版本。
但我最终更改了API，我觉得这个项目有了新的生命，按我的想法进行扩展变得更加容易。
5. 不要害怕说“不”、“请提交测试”，“请修复{X}”等
有时你会收到一个有可怕想法的pull请求。但有时它也可能是一个伟大的想法，但不应该属于代码基本功能（也许应该作为一个插件）。
有时你会得到一个没有经过测试的pull请求。这些情况下，你需要以某种方式说“不”。当你这样做的时候，请参照第1条，应该礼貌地说明你的理由，而不应该只有一个“不”字。
如果你因为他们没有进行测试而说“不”，那么你***也应该先对自己的代码进行测试。此外，如果你有一个特定的代码风格（制表符、空格等），请在你的README中说明。
6. 明智地选择合作伙伴
如果你的项目已经增长到需要合作伙伴的地步，那么可以考虑让其他开发者来作为项目共同所有者或维护者。前提是，你要明智地选择这些人。
要知道，没有人的想法会和你完全一样（这是很好的事情），但是你要确保你们的想法大部分能够重叠，以便项目能够朝着一个方向发展。无论一个人有多么博学或受欢迎，如果他是一个dick（见第1条），那么就不能让他成为项目所有者。如果在开源项目中出现派别争斗，那么项目离结束就不远了。
一些好的做法是，给予贡献者和所有者不同的权限。如果一个初级开发者想参与修复问题，不要给他所有者的权限。
7. 不要吝啬赞美和鼓励，给予贡献者应得的荣誉
作为一个开源项目所有者，如果有人为你的项目贡献了一条非常好的建议，一定要在公开场合经常表扬他。这样可以鼓励更多的人贡献更多的想法或代码。
我现在和一些人一起工作，如果他不能给我一些应得的荣誉的话，我想我在大多数事情上会对他产生不信任——不只是在开发工作上。
8. 不要害怕放弃
我之前开发过几个项目，当时我认为这些项目的想法很伟大，但是现在我已经放弃了这些项目。如果还有人发现你的项目有用并正在使用它们时，你很难放弃。但如果你因为学到了一些更好的方法，使得你放弃这个项目，你需要解释一下原因，有可能这会促成一个新的开源项目，并可以更好地帮助这些用户解决问题。如果你因为没有时间而放弃，你可以问问其他人是否愿意接管这个项目。
如果你放弃了一个有人在使用的项目，用户可能会沮丧。不幸的是，这就是现实。你要从长远来看。比如，我之前写了很多工具，但现在看来，这些工具充斥着各种糟糕的代码，似乎放弃这些是一个明智的决定。
总结
开源是美丽而危险的。美丽是因为可以让很多人为了一个目标而努力，危险是因为你需要有持之以恒、乐于分享的精神。
现在的一些光辉夺目的开源项目并不能代表所有，每天都会有大量的开源项目被创造，也有大量的开源项目死亡。你会发现一些对你有很大帮助的项目有可能在不久的将来会消失，除非该项目获得了足够多的贡献。这就是为什么持之以恒的精神和创造力对于一个开发者和开源项目来说比其他方面更重要。
