问准备以开放源代码的形式发布代码

EN

选择您的牌照

如果您的代码到目前为止都是封闭源代码，那么首先要做的就是决定使用哪个开源许可证(GPL <=2，GPL 3、LGPL、BSD、月食等)。你想用。

每个代码都有正反两类，所以请阅读它们对代码的限制，并决定您希望谁能够使用它。警告，无论你选择谁，都会抱怨--这是神圣的战争领土，超出了这个问题的范围。

• 一个很好的资源，以确定哪一个许可是正确的，您是非常全面的，交互式的许可证微分器，来自牛津大学开放源码软件观察。

清理您的存储库

如果您的存储库中的代码还没有将您选择的许可证应用到它，那么到目前为止，我将检查您的整个修订历史并追溯应用它(这可能需要在引入新源文件的每个点重新建立一个基础)。然而，这将产生一个很好的干净的存储库，当您向公众发布它时，在您选择的许可证不生效的地方没有任何修改。

另一种选择是在第一个版本的时候启动您的公共存储库，在此之前，至少要有或没有历史记录。

这有一个缺点，那就是人们不能回顾你的历史，找出你是如何回到今天的位置，但它的优点是人们不能回顾你的历史，找出你如何到达今天的位置。*8')

当我工作的公司让我开发的软件开源时，我们一开始只是在发布点生成工作目录的快照。当我们转向使用公共github存储库时，我们启动了每个git回购，即插件被移出svn (或一组插件)，很少包括任何历史记录。

考虑双重许可

如果您认为在使用您的软件时可能有商业兴趣，但对GPL 3这样的限制性重复使用许可证有意识形态上的偏好，请考虑提供双重许可。为公众下载提供GPL 3许可证，收费提供商业许可证，这两个世界都是最好的。

与以后开始提供商业许可证相比，从一开始就这么做可能会带来更少的摩擦。如果你的社区变得很受欢迎，人们可能会指责你出卖了你，如果你以后对商业开发的可能性没有直截了当的话。

考虑贡献者协议

如果您计划使用双重许可，或者只想保留您的代码库，那么您需要重新实现已贡献的修补程序，或者让贡献者将其贡献的权限分配给您。否则，您会发现他们的贡献阻止您在其他许可证下发布代码库。

梅森惠勒对问题开源许可我的代码以后会限制我吗？的回答提供了关于这个问题的一些很好的信息，以及libsdl项目用来处理这个问题的方法。

但是，请注意，正如您选择许可可能会限制使用和贡献您的项目的人员和组织一样，您也会选择是否有一个贡献者协议。有些人不愿意为一个要求他们签署出资人协议的项目做出贡献。

双许可证贡献者协议

甲骨文贡献者协议 (链接很难在页面上看到)是贡献者协议的一个很好的模板。它也是许可(CC)的方式，你可以修改和重复使用它。

马克·布斯的回答很好，但是只讨论许可/版本控制，所以我想在一个更技术性的领域上添加几点，这是我在发布开源代码时的第一步(或者不是第一步)。

1. 加强风格和可读性。没有人愿意为一个他们需要花上几个月时间来理解基本知识的项目做出贡献。没有人愿意像这样阅读和使用代码。如果您希望其他人为项目做出贡献，那么最好指定要使用的样式标准是什么。
2. 清理一下。Mark解释了为什么让任何人访问每个版本并查看项目是如何从一开始就完成的可能是很烦人的。同样，在发布之前，您必须清除大量的注释代码(在所有情况下这都是错误的做法)，或者删除说明修改是什么、什么时候完成等的注释(这是一个更糟糕的实践)。
3. 确保您的源代码有足够的测试。在这种情况下，它特别重要，因为人们会在不知道您的应用程序是如何完成的以及什么是警告的情况下来的，并且会尝试修改它，最终破坏代码。
4. 描述你的项目。代码可能很棒。如果我不知道什么是应用程序，我几乎没有机会为这个项目做出贡献。
5. 描述贡献者可以做什么。一些开源项目非常接近，只有在经过严格的测试和审查之后，并且只有当他们认为自己需要相关的贡献时，才会接受这些贡献。另一方面，在其他项目中，欢迎作出贡献。在开始对项目做出贡献之前，了解项目中的情况总是很好的。
6. 把它呈现出来。看，jQuery网站做得很好，有专业的设计，高质量的内容等，这让你很想参与这个项目。另一方面，如果你有一个缓慢，丑陋的网站，内容太烂，人们宁愿去为其他开源项目作出贡献。
7. 添加支持工具。例如，bug跟踪不是商业项目的一个选项。为什么它是一个开源的呢？它也可能有助于了解哪些要点需要作出贡献。如果我使用您的开源产品，找到一个bug，转到bug跟踪网站，并发现bug在列表中的第一位，我将更有动力不仅解决它，而且提交我的更改。

建造它，他们就会来。

如果需要你的工具，人们会发现它通过搜索引擎和文字论坛。在与你的工具所在的领域相关的特殊兴趣论坛上发表几篇文章，这一点也不伤人。如果有的话，可以和有类似兴趣的人一起跳上IRC频道，让他们知道。关于它的博客(如果你有一个个人博客)。本质上，你做的广告越多越好。话虽如此，如果没有必要，人们就是不会使用它。

所以简而言之，是的，把它推到GitHub上。启用问题特性，以便人们可以记录bug和Wiki，如果您的工具足够复杂，足以证明它的存在。不要气馁，如果你得不到即时的打击。有时，OS工具可能需要一些时间来收集蒸汽(虽然其中一些工具也是一出大门)。

祝你好运:)