当一个项目被开源,这意味着任何人都可以出于任何目的查看,使用,修改和分发你的项目。 这些权限通过开源许可强制实施。
开源是强大的,因为它降低了事物被采纳的障碍,允许想法迅速传播。
个人或组织为何想要开源一个项目,有各种各样的的原因,例如:
协作: 开源项目可以接受世界各地人们的修改。 例如 Exercism 就是一个拥有350多个贡献者的练习平台。
采用和重组: 任何人几乎可以出于任何目的使用开源项目。人们甚至可以使用它来构建其他东西。例如,WordPress 就是派生自一个名为 b2 的现有项目。
透明度: 任何人都可以检查开源项目是否有错误或不一致。 透明度对保加利亚 或美国等政府,银行或医疗保健等受监管行业以及 Let’s Encrypt 等安全软件都很重要。
开源并不仅仅限于软件。您可以开源任何事物,从数据集到书本。查看 GitHub Explore 找找有什么是你可以开源的。
开源是指”免费”吗?
开源最大的吸引之一是它不花钱。 但是,”免费”只是开源的总体价值的一个副产品。因为开源许可证要求任何人可以几乎出于任何目的使用,修改和共享您的项目。因此,大多数开源项目是免费的,但”免费”不是开源定义的一部分。 有些方法可以通过双重许可或有限功能间接地为开源项目收费,同时仍然遵守开源的官方定义。
发起自己的开源项目
一般来说,如果你乐意于他人对你工作进行查看和反馈,你便可以选择开源你的项目。每个项目都应包括以下文档:
作为维护者,这些组件将帮助你交流你的期望,管理贡献并保护每个人的合法权益(也包括您自己的)。他们能够大大增加你积极体验的机会。
如果您的项目在 GitHub 上,则将这些文件放在您的根目录中,并使用推荐的文件名将有助于 GitHub 识别并自动将其显示给读者。
自述文件、仓库许可证、参与指南和行为准则一起,帮助您,沟通项目要求以及管理对项目的参与。
选择一个许可证 (license)
开源许可证保证其他人可以使用,复制,修改和贡献给您的项目,而不会产生不良后果。 它也可以保护您免受繁琐的法律影响。启动开源项目时,请务必包含许可证。
法律工作是非常无趣的。但好消息是,您可以将现有许可证复制并粘贴到存储库中。只需要花这么一点时间,就能保护你的辛苦工作。
MIT, Apache 2.0, 和 GPLv3 都是非常流行的开源许可证, 但你可以选择其他选项.
当你在GitHub上创建新项目时,你可以选择许可证。包括开源许可证将使你的GitHub项目成为开源。
如果您在管理开放源码项目的法律方面有其他问题或疑虑,我们已经在这里介绍了。也开源参考:如何为你的代码选择一个开源协议
撰写 README
自述文件(README.md
)不仅仅是用于说明如何使用你的项目。他们还可以解释你的项目为什么重要,以及它可以为你的用户做什么。
在您的自述文件中,尝试回答以下问题:
- What:这个项目做什么?
- Why:为什么这个项目有用?
- How:如何开始?
- Help:如果需要,我可以在哪里获得更多的帮助?
- Who:谁维护和参与项目?
您可以使用自己的 README 回答其他问题,例如处理贡献,项目的目标以及许可证和归属信息。 如果您不想接受他人的贡献,或者您的项目尚未准备好作为产品提供使用,请将这些信息写下来。
想要获得更多灵感,请尝试使用 @18F 的 “让 README 可读” 或者 @PurpleBooth 的 README 模板 (需要梯子)来撰写一个完整的 README。
当你在根目录中包含一个 README 文件时,GitHub 会自动将其显示在存储库的主页上。
如果将自述文件放在仓库的根目录 docs
或隐藏的目录 .github
中,GitHub 将会识别您的自述文件并自动向仓库访问者显示。
编写贡献者指南
贡献文件 (CONTRIBUTING file) 告诉你的受众如何参与你的项目。例如,你可以包括以下信息:
- 如何提交错误报告(尝试使用 issue 和 pull request 模板)
- 如何建议一个新功能
- 如何配置你的环境和运行测试
除了技术细节, 贡献文件也是一个供你传达对贡献期待的机会, 例如:
- 你在寻求的贡献类型
- 你项目的路线图或者版本
- 贡献者应该(或者不应该)如何与你取得联系
- 创建良好议题或拉取请求的步骤。
- 指向外部文档、邮件列表或行为准则的链接。
- 社区和行为预期。
使用热情友好的语气并提供具体的贡献建议(例如编写文档或者搭建网站)可以大大提高新人的参与度。
例如,Active Admin 以这样的方式开始它的贡献指南:
首先, 非常感谢你考虑为 Active Admin 贡献帮助。正是你这样的人使 Active Admin 成为一个很棒的工具。
在你项目开始的初期,你的贡献文件可以很简单。你应该经常解释如何提交错误和文件问题,以及关于如何作出贡献的技术问题(例如测试)。
随着时间的推移,你可以将其他常见问题添加到贡献文件中去。写下这些信息意味着问你相同问题的人会越来越少。
想要获得更多有关编写贡献文件的方式,请查阅 @nayafia 的 贡献指南模板 或者 @mozilla 的 “如何构建 CONTRIBUTION.md”。
在你的 README 中链接你的 CONTRIBUTING,这样更多人就能看到他。如果你在你的项目中放入了 CONTRIBUTING 文件,当一个贡献者创建 issue 或者开启一个 pull request 时,GitHub 会自动链接你的文件。
建立行为规范
行为准则有助于为项目参与者的行为设定基本规则。这在你为社区或者项目推出一个开源项目的时候尤为有价值。一份行为帮助你促进健康,有建设性的社区行为,这也会减轻你作为维护者的压力。
更多信息,请参见 行为规范指导。
除了传达你期待参与者如何行动,行为规范也倾向于描述这些期待针对谁,适用于何时,以及对于违规行为的处理方法。
就像开源许可证一样,有现成的行为规范,所以你不必自己编写。贡献者公约是一个行之有效的行为规范,已经被用在超过4000个开源项目,包括 Kubernetes,Rails,以及 Swift。无论你使用哪一种,你都应该准备好在必要时执行行为规范。
将文本直接粘贴到项目存储库中的 CODE_OF_CONDUCT 文件中。将文件保存在项目的根目录中,以便轻松找到,并从 README 中链接到它。
你的项目的命名与品牌
品牌不仅是一个华丽的 logo 或者易记的项目名。它还关于你如何谈论你的项目,以及你想把信息传递给谁。
选择恰当的名字
选择一个容易记住,有创意,能表达项目用意的名字。例如:
如果你的项目是基于一个已存在的项目创建,那么使用他们的名字作为你项目名的前缀会帮助你阐述你项目的用途。 (例如 node-fetch将window.fetch
添加到了 Node.js)。
考虑阐明所有。押韵虽然有趣,但是记住玩笑不可能转变成其它的文化,或者他人与你有不同的经历。你的一些潜在用户可能是公司员工,你不能让他们在工作中很难解释你的项目!
避免名字的冲突
查看是否有同名的开源项目,尤其是你分享的是同样的语言或者生态系统。如果你的名字与一个已存在的知名的项目有冲突,你会让你的粉丝感到困惑。
如果你想要一个网站,Twitter 账号或者其他特性来展示你的项目,先确保你能得到你想要的名字。理想情况下,为了美好的未来现在保留这些名字,即使你现在不想用他们。
确保你的项目名没有侵权。如果有侵权,可能会有公司要求你的项目下架,或者对你采取法律措施。这样得不偿失。
你可以查阅WIPO全球品牌数据库避免商标冲突。如果你是在公司工作,法律团队会帮你做这件事。
最后,去谷歌搜索你的项目名。大家会很容易地找到你的项目吗?在搜索结果里是否有你不想让大家看到的东西?
你的写作(和代码)如何影响你的品牌
在项目的整个生命周期中,你需要做很多文字工作:READMEs,教程,社区文档,回复 issues,甚至肯能要处理很多来信和邮件。
是否是官方文档或者一封普通的邮件,你的书写风格都是你项目品牌的一部分。考虑你可能会拥有粉丝,以及这是你想传达的声音。
使用热情,通俗易懂的语言(如”他们”,即使是指一个人)能够让新来的贡献者感觉项目非常欢迎他们。使用简单的语言,因为你的读者可能英语不是很好。
除了书写风格外,你的编码风格也是你项目品牌的一部分。 Angular 和 jQuery是两个项目代码风格严谨的示例和指南。
当你的项目才开始时,没有必要为项目编写一份风格指南。你可能会发现你喜欢将不同的编码风格融入到项目。但是你应该想到你的书写和编码风格会吸引或者拒绝不同类型的人。项目的早期是你建立你希望看见的先例的机会。
Your pre-launch checklist
准备好开源你的项目了吗?有一份帮助检查清单。检查所有内容?你准备开始吧! 点击 “publish” 以及拍下自己的后背。
文档
需要为项目指定一个开源协议
项目要有基础文档 (README, CONTRIBUTING, CODE_OF_CONDUCT)
易记的项目名,指出项目是做什么的,不能和已存在的项目冲突或者商标侵权
最新的 issue 队列,组织和标记清除的issues
代码项目使用一致的代码风格和明确的功能/方法/可用的名字
注释清晰的代码,记录意图和边缘案例
在修改历史,issues或者 pull requests 中没有敏感的信息 (例如 密码或者其他不能公开的信息)
人
如果你是代表个人:
- 你已经告诉了你的法律部门,以及/或者理解了你公司(如果你是某一家公司的员工)的开源政策和 IP
如果你有一家公司或者组织:
你已经告诉了你的法律部门
你有一个宣布和促进项目的营销计划
一些人被允许管理社区互动(回复issues,检查和合并pull requests)
至少有两人管理访问项目