摘要
如果你想发布一个开源库，请确保它有以下特点：
缺少任何一项都会造成一些用户的愤怒和沮丧，当然同时也浪费了时间。 怎样让你的开源项目更棒每年，越来越多的人发布了自己开发的库并且它们开源。这里我们分享一些我们经验，以便你的用户对你的库满意。 这里有一个经验法则： 不要让你的用户生气！ 也可以理解为： 不要让你的用户有想要砸电脑的冲动 现在让我们通过一些努力来实现这个目标。 创建一个实用的README即使你的项目有一个很棒的网站，潜在的用户第一次接触这个项目很可能就是通过阅读README文件。我们需要确保它很棒并且包含了有用的信息。 提供依赖信息那么说你会发布你的开源项目。这说明你很聪明，真有你的！不幸的是，不是所有人都像你那样，而且有一些人对这门语言或者你在做的系统完全不了解。这意味着对你来说很显然的事情对他们来说就一点也不显然了。 其中一件就是缺少依赖说明或者安装说明 我到底怎么安装这个东西，难道不能说得清楚一些吗? 这很快就能让用户生气。在源代码里找你的包或者构件的名字是很烦人的，有些项目对构件使用一些特别有才的名字，完全不符合仓库的名字。 让你的用户从这些糟糕的事情中脱离出来吧。问题是怎样添加依赖性，理想状况下可以通过复制粘贴一小段代码。 如果需要例子的话可以点击 Welle。 清楚的说明项目的成熟度你在生产中使用这个项目有几个月了吗？你是否觉得它还是不完整的？你是否希望API在下一个版本会彻底地修改？你的项目是否在要求最多并且很老的项目中也能稳定安全的使用？ 要把这些说得清楚。下次你就不会因为做了一个错误的介绍，但是没有的提供任何项目成熟度的信息而项目浪费一周的时间了。你会意识到几句短短的话就能产生很大的影响。 运行时、语言、工具版本的文档支持 当考虑到向后兼容时，Clojure有一个很好的跟踪记录。它好的几乎让人难以置信。包括 然而，不会一直都是这样。在某些情况下，未来版本的Clojure会打破兼容性。我们怎么让我们的用户不愤怒？通过在README中清楚的说明哪些版本是支持的。 这只需要写一行文字。这样，在你发布的那一周就少了抱怨，同时也减少了初学者的很多麻烦。 如果你需要一个例子，有一个来自 Welle的例子。 说明你使用了什么许可证你可能并不太关心许可证，但是那些在大公司中想用你的库的人很关心。他们必须知道！当他们想用Clojure/Node.js/Scala/Go等等的时候，可能不能使用。 因此清楚的说明你的许可证。也请你使用一些对商业友好的协议，除非你有自己的理由。（ Apache Public License 2.0和Eclipse Public License）是不错的选择。注意到一些许可证(比如MIT)的确很友好、流行，但是不提供任何专利保护，在当前的法律环境下也不应该忽视。 最后，记得你可以使用双许可证，如果你真的是许可证中立的话可以使用，比如APL2/GPLv2。那个你的用户就可以选择最适合他们的许可证了。 疑惑的时候，可以参考摘要：合法、开源许可证用白话概括（但是别把它当作合法的建议） |
