2011年在 Nicole Sullivan举办的 Velocity大会上我介绍了第一个CSS代码质量工具 CSS Lint， 我们花费之前的两周疯狂的编码， 尝试着构建一个终用户有用并且易于修改的应用. 我们所有人都没有启动这样一个开源项目的经验， 因此我们也在这过程中学到了很多.
初期经过一段时间的试错， 项目后进入正轨， 现在也时常获得CSS Lint用户和CSS Lint贡献者们的赞许. 其实在你经过思考确定目标之后创建一个成功的开源项目并没有想象的困难.
你的目标是什么?
这一段时间， 好像很多人写了一代代码加上一段开源软件协议， 再把它发布到GitHub， 然后说: "我把它开源了". 创建一个开源项目并不仅仅是让你的代码可以自由的被访问获取. 所以， 在向世界宣称你开源了那么些除了你自己在空闲时间使用而还没有其他人使用的东西之前， 停下来问一下你自己， 对于这个项目， 你的目标是什么?
首要的目标通常是: 创建点有用的东西. 对于CSS Lint， 我们的目标是为提升CSS 代码质量，创建一个易适应各开发者开发流程且易扩展的工具. 而不论这开发流程是否是自动化的. 另外， 通过找寻做类似项目的人， 并且想清楚你面向的用户基数有多大来确保你所提供的东西是有用的.
在那之后， 应该被放在第一位的是 决定为什么你要开源这个项目. 仅仅是因为你想分享你完成的东西? 你有打算持续开发这些代码还是仅仅只是把他们扔到外界再也不管? 如果你没有打算持续开发这些代码， 那么这篇文章剩下的部分不适合你. 确保在你代码库中的readme文件里面清晰的声明了你会持续开发这一点以避免找到这个项目的人对此感到困惑.
如果你准备持续开发你的代码， 你考虑过接受别人的贡献吗? 如果答案否定， 再一次， 这篇文章不适合你. 如果答案肯定， 接下来你有些工作要做了. 创建一个接受外界贡献的开源项目的工作量比它表面上看起来需要做的多. 你不得不创建一个环境， 这个环境可以让那些不熟悉这个项目的人都能很快上手并应用此项目迅速提高他们的开发速度和生产能力， 要做到这点需要一些计划.
这篇文章是让你了解如何开始一个开源项目并达到下面这些目的：
创造一个对他人有帮助的东东
制订项目计划并不断完善你所创造的项目
接受其它人贡献的代码(也许会有money)
选择开源许可证
在发布你的代码之前，重要的一个事情是选择一个开源许可证。选择不同的开源许可证会影响你项目的参与者。所有的开源许可证都会保留你个人作为代码创建者的版权。虽然许可证的授权概念有点复杂，但一些常用的许可证和基本的东西还是要了解的。(如果你的开源项目属于公司性质，在选择许可证之前先咨询一下公司的法律顾问)
GPL
GNU公共协议是为GNU项目而创建，并且随着linux作为一种可变的操作系统已被大家所接受，GPL许可要求任何使用基于GPL授权的组件也必须要在GPL下可用。简单而言之，任何使用基于GPL授权的组件在任何方式下都必须在GPL许可下开源。GPL授权的程序没有在使用上限制，这个限制仅仅和派生作品的修改和发布有关
GNU宽通用公共许可证是一种GPL更加宽松的版本。基于LGPL授权的组件可能关联到程序，但是程序本身并不必开源或者基于GPL或LGPL授权，换句话说，LGPL和GPL相似，因此任何派生作品也必须开源。
MIT
亦被称为X11协议。该协议相对宽松，对于使用该协议的项目，协议的遵循者必须自动放弃对该项目代码发布权以及使用权的私有，而赋予公众相应权利。因此，遵循MIT协议的代码或许被会被引用在一些没有声明遵循某项协议的特定代码中。此外，MIT协议与GPL协议兼容，所以你完全可以用MIT协议下的代码来开发GPL协议的应用。
BSD3
协议有点松，有点松……该协议相对宽松，对于使用该协议的项目，协议的遵循者必须自动放弃对该项目代码发布权以及使用权的私有，而赋予公众相应权利。此外，项目中任何以二进制形式发布的代码(译者注：貌似.bin文件之类的)，也需要在许可文档中声明该协议。那么，该协议与MIT协议的区别在哪里呢?当该协议的标的物(译者注：一般，这里的“标的物”是声明使用该协议的代码，为了保证严谨性，在此进行注释)被其他人使用时，他们不可以用该标的物的所有权人的名字进行商业宣传。例如，如果我写了一段遵循该协议的代码，而你把他用着自己的应用里面，你是不可以用哥哥我的名字去做宣传的，除非经过我的同意。后，BSD3协议也是和GPL兼容的。
好吧，其实还有很多开源协议本文没有介绍，但是以上协议应该是受大家关注的。
需要注意的一点是 Creative Commons许可证并非设计来于软件的. 所有的 Creative Commons许可证都是为"创造性工作"制定的， 例如音频， 图像， 视频和文字. 制定 Creative Commons 的组织他们自己也不推荐将 Creative Commons许可证用于软件， 应该在软件中使用专门为软件制定的许可证， 通常也是上文讨论的四种.
因此， 你应该选择哪个许可证呢? 这点大部分由你想别人怎么使用你的代码决定. 因为LGPL， MIT 和 BSD3都和GPL完全兼容， 这还不是需要关注的. 如果你想所有你软件的修改版本都只被用于开源软件， 那么你应该选择GPL. 如果你的代码是设计成一个不需要修改而可以直接引入别人的项目使用的组件， 那么你可能会考虑LGPL. 否则， MIT和BSD3许可证时比较通常的选择. 个人比较趋向于喜好MIT许可证， 而商业上可能更加的偏向于喜好BSD3许可证以保证他们的公司名称不会被未授权的使用.
为了帮助你做决定， 看一下这些流行的开源软件项目都使用了些什么协议:
jQuery: MIT license
YUI: BSD3 license
Dojo Toolkit: dual-licenced under BSD3 and Academic Free License
Backbone: MIT license
另外一个选择是直接把你的代码发布为 public domain(公有领域)， 在 public domain中的代码没有版权拥有者， 这些代码可以完全随意使用. 如果你没有打算保持你对代码的控制全 或者 你只是想向世界分享你的代码而不打算持续开发它， 那可以考虑一下把代码发布到 public domain.
想进一步了解许可证与它们相关的法律问题以及这些许可证如何工作， 请阅读 David Bushell的 Understanding Copyright and Licenses.
代码组织
决定在你的开源项目中使用何种许可证以后， 这几乎是时候把你的代码放出来了. 但是在这之前， 你得先看看代码是怎么组织的. 不是所有代码都会得到大家的贡献. 如果一个潜在的贡献者无法通读你的代码， 那么他非常可能也没法做出任何贡献. 在你分享你的代码给公众之前， 你组织代码的方式， 包括文件目录结构， 代码风格都是需要认真考虑的因素. 别随意把你胡乱写的代码扔出来. 多花点时间考虑别人可能会怎么阅读你的代码以及他们在这过程中可能会遇到什么问题.
对于CSS Lint， 我们选用了一个基本的 顶层目录结构: src 用于主源代码， lib 用于外部依赖， test 用于测试代码。 src目录进一步分为子目录， 分类相关的文件。 所有的CSS Lint规则都在 rules 子目录; 所有的输出格式化都在 formatters 目录等等。 test目录划分子目录与src目录相同， 这样可以标示测试代码和主代码的关系。 随着时间过去， 我们因为需要已经添加了顶层目录， 但基本结构和开始做的是一样的。
文档
很多对开源项目的抱怨是由于缺乏文档。写文档往往没有写程序来得有趣，但对于开源项目成功却至关重要。如果你不想要别人使用你的软件，不想要人们贡献代码，那么只要不提供文档行了。我们的CSS Lint一开始犯了这个错误。项目刚启动时，我们没有提供文档，结果大家都不知道怎么用这个东西。不要重蹈我们的覆辙，在启动项目之前，一定要做好文档的工作。
文档应该很容易被更新，而且不需要push代码可以更新，必须能根据用户的反馈快速地修改。也是说，不要把文档与代码放在一个仓库里。如果你把代码放在GitHub上，那么可以用GitHub内置的wiki来放文档。我们的CSS Lint是把文档放在wiki上。如果你的代码不是放在GitHub上，那么可以用自己的wiki或其它类似的系统来放文档，以便实时地更新它们。好的文档系统应该是很容易更新的，否则你可能永远都不会去更新它们。
终用户文档
无论你写的是命令行程序、应用框架、工具库还是其它什么东东，都要把终用户深深地放在脑海里。终用户并不是修改你代码的人，而是使用你代码的人。拿我们的CSS Lint来说，大家一开始不知道怎么用，因为我们没有给出终用户文档。争取不到终用户，也争取不到贡献者。对你的代码满意的终用户们后会成为贡献者，因为他们看到了蕴含在代码中的价值。
开发者指南
即时你的代码布局合理，文档丰富，也无法保证一定会有贡献者出现。你需要一份开发者指南，让那些贡献者们快速融入进来。一份好的开发者指南应该有下面这些内容：
如何获取源代码：你当然希望贡献者们都知道怎么check out代码，但世事无。一份友好的介绍总是受人欢迎的。
代码是如何组织的：即使你的代码和目录结构很清晰，完全能自我说明，也好写下来，总有用处的。
如何设置构建系统：如果你用了某种构建系统，那么应该提供一份怎么设置这个系统的说明。如果构建时的一些依赖项没有包含在你的仓库中，那么这份说明中还应该包括怎么获取这些依赖项的信息。
如何构建：如何进行构建以及单元测试的步骤。
