在最简单的层面上，开源编程仅仅是编写可以被其他人自由使用和修改的代码。但是你听说过关于下围棋的老生常谈，对吧？“如此简单，只需一分钟即可学会规则，但如此复杂，需要一生才能掌握。” 编写开源代码是一种非常相似的体验。很容易将一些代码扔到 GitHub、Bitbucket、SourceForge 或你自己的博客或网站上。但是 *正确地* 做这件事需要一些个人的投入、努力和远见。
opensource.com
开源编程 *不是* 什么
让我们在一开始就明确一点：仅仅因为你的代码在 GitHub 的公共仓库中，并不意味着你的代码就是开源的。几乎所有国家/地区的版权都会在作品固定在介质中时自动生效，而无需作者采取任何行动。对于任何未经作者许可的代码，只有作者才能行使与版权所有权相关的权利。未经许可的代码——无论多么公开访问——对于任何不明智地使用它的人来说，都是一颗定时炸弹。
一个善意的作者可能会认为，“很明显这是可以免费使用的”，并且没有计划起诉任何人，但这并不意味着该代码可以安全使用。无论你认为某人会做什么，该作者都有 *权利* 起诉任何人在未经明确授权许可的情况下使用、修改或嵌入该代码到任何其他地方的人。
显然，你不应该在没有许可证的情况下将你自己的代码公开，并期望其他人使用它或为其做出贡献。我还建议你避免使用（甚至 *查看*）此类代码。如果你创建了一个与你过去某个时候检查过的未经许可的作品高度相似的函数或例程，你可能会让你自己或你的雇主面临侵权诉讼。
假设 Jill Schmill 编写了 AwesomeLib 并将其放在 GitHub 上，但没有许可证。即使 Jill 从不控告任何人，她最终也可能会将 AwesomeLib 的所有权利出售给 EvilCorp，后者会的。（把它想象成一个潜伏的漏洞，等待被利用。）
未经许可的代码是不安全的代码，句号。
选择正确的许可证
好的，你已经决定要编写一个新程序，并且你希望人们拥有使用它的开源权利。下一步是弄清楚哪个许可证最适合你的需求。你可以从 GitHub 整理的 choosealicense.com 开始，它正如其名称所示。该网站的布局有点像一个简单的测验，大多数人最多点击一两次就可以找到适合其项目的许可证。
提醒一句：不要过于花哨或自以为是。如果你选择一个常用的、广为人知的许可证，例如 Apache 许可证 或 GPLv3，人们很容易理解他们的权利是什么以及你的权利是什么，而无需律师团队寻找陷阱和问题。但是，你离既定路线越远，你和他人面临的问题就越多。最重要的是，*不要编写你自己的许可证！* 创建你自己的许可证会给每个人带来不必要的困惑。 不要这样做。如果你绝对 *必须* 拥有在任何现有许可证中都找不到的特殊条款，请将它们作为对现有良好理解的许可证的附录来编写……并保持主许可证和你的附录清楚地分开 以便每个参与者都知道他们必须对哪些部分格外小心。
我知道有些人固执地说，“我不在乎许可证，也不想考虑它们；它是公共领域。” 问题在于，“公共领域”在法律意义上不是一个普遍理解的术语。它在不同的国家/地区意味着不同的事情，并附带不同的权利和条款。在某些国家/地区，你甚至不能将 *你自己的* 作品置于公共领域，因为政府保留对此的控制权。幸运的是，Unlicense 涵盖了你。 Unlicense 使用尽可能少的文字来清楚地描述“只需将其设为公共领域！”在清晰且普遍可执行的方式中的含义。
如何应用许可证
选择许可证后，你需要明确且明确地应用它。如果你在 GitHub 或 GitLab 或 BitBucket 之类的地方发布，你将拥有一个用于项目文件的文件夹结构。在项目根文件夹中，你应该有一个名为 LICENSE.txt 的纯文本文件，其中包含你选择的许可证的文本。
将 LICENSE.txt 放在项目的根文件夹中还不是最后一步——你还需要一个注释块，在项目中每个重要文件的头部声明许可证。这是使用成熟许可证的好处之一。一个注释说：# this work (c)2018 myname, licensed GPLv3—see https://gnu.ac.cn/licenses/gpl-3.0.en.html 比仅仅对完全自定义的许可证进行神秘引用的注释块要强大得多，也更有用得多。
如果你在自己的网站上自行发布代码，你将需要遵循基本相同的过程。有一个 LICENSE.txt，将许可证的完整副本放入其中，并在每个重要文件的头部用缩写注释块链接到你的许可证。
开源代码是不同的
专有代码和开源代码之间的一个很大的区别是，开源代码旨在被看到。作为一名 40 多岁的系统管理员，我编写了很多代码。其中大部分实际上是专有的——我开始编写代码是为了让自己更容易工作，并解决我和/或我公司的问题。此类代码的目标很简单：它所要做的就是在其创建者计划的精确方式和精确情况下工作。只要你期望在调用程序时发生的事情发生的频率高于不发生，它就是成功的。
开源代码非常不同。当你编写开源代码时，你知道它不仅必须工作，而且必须在你从未梦想过且可能没有计划过的情况下工作。也许 *你* 只有一种非常狭窄的代码用例，并且每次都以完全相同的方式调用它。但是，与你分享它的人……他们会暴露出你从未考虑过的用例、参数组合以及纯粹奇怪的思维过程。你的代码不一定必须满足所有这些要求——但至少需要优雅地处理他们的请求，并且在无法服务时以可预测和逻辑的方式失败。（例如：“第 583 行除以零”不是未能提供命令行参数的可接受响应。）你的开源代码还必须避免让你过于尴尬。这意味着在你努力挣扎以使一个不听话的函数或子例程最终产生你期望的输出之后，你不会只是叹口气并继续做下一件事——你 *清理它*，因为你不希望世界上的其他人看到你明显的纸牌屋。这意味着你停止用像 $variable 和 $lol 这样的变量来污染你的代码，并将它们替换为有意义的名称，例如 $iterationcounter 或 $modelname。这意味着专业地注释事情（即使它们在你最紧张的时候对你来说很明显），因为你希望其他人以后能够理解你的代码。
起初这可能有点痛苦和令人沮丧——这是你不习惯做的工作。但是，它会让你成为一名更好的程序员，并且也会让你的代码变得更好。同样重要的是：即使你是你的项目拥有的唯一贡献者，从长远来看，它也可以节省你的工作。相信我，一年后，当你不得不重新审视你的应用程序时，你会非常高兴 $modelname 不再被称为 $lol，它在被放到某个数组中的某个地方之前被几个非常不透明的正则表达式解析。
你不仅仅为自己写作
开源的真正核心根本不是代码：而是社区。拥有强大社区的项目比没有强大社区的项目生存时间更长，采用率也更高。考虑到这一点，最好不仅要拥抱，还要积极地为你希望围绕你的项目构建的社区进行规划。
蝙蝠侠可能会花费数百小时在隐居中疯狂地秘密构建一个项目，但你不必这样做。 在 Twitter、Reddit 或与你的项目范围相关的邮件列表中，宣布你正在考虑创建一个新项目。 谈谈你的设计目标以及你计划如何实现它们。 请求输入，倾听相似（但可能不完全相同）的用例，并在编写代码时将这些信息构建到你的流程中。 你不必接受每一个建议或请求——但如果你提前知道它们，你可以避免以后需要进行艰苦的重大修改的陷阱。
这个过程并非始于最初的公告。如果你希望你的项目被其他人采纳和使用，你需要以这种方式开发它。 这不是一个入门的障碍；这只是一种可供使用的模式。 所以不要只是在自己的机器上用文本编辑器私下埋头苦干——在一个大型的开源平台上启动一个真正的、可公开访问的项目，并把它当成社区已经存在并正在关注那样对待。
构建真正的公共项目的方法
你可以在 GitHub、GitLab 或 BitBucket 上免费为开源项目开设帐户。 一旦你开设了帐户并为你的项目创建了一个存储库，就使用它——创建一个 README 文件，分配一个 LICENSE 许可证，并在你开发时逐步推送代码。 这将培养你与真正的团队合作所需的习惯，因为你将习惯于以可衡量的、有文档记录的提交和明确的目标来编写代码。 你走得越远，你就越有可能开始引起兴趣——通常首先以最终用户的形式出现。
用户会开始提交 issue (问题)，这会让你感到既高兴又烦恼。 你应该认真对待这些 issue，并礼貌地对待提交者。 他们中的一些可能基于对你的项目是什么以及什么是或什么不是其范围的巨大误解——也要礼貌而专业地对待这些。 在某些情况下，你会引导这些用户进入你正在做的事情的范围。 然而，在其他情况下，即使他们犹豫不决，他们也会引导你意识到你可能应该在一开始就计划的更大——或略有不同中心——的范围。
如果你在用户方面做得很好，最终会有其他开发人员出现并产生兴趣。 这也会让你感到既高兴又烦恼。 起初，你可能只会得到一些琐碎的 bug 修复。 最终，你将开始收到 pull requests (拉取请求)，这些请求要么会将非常非常小众的特殊用例硬编码到你的项目中（这将是一场维护的噩梦），要么会显着改变你项目的范围甚至焦点。 你需要学会如何识别哪些贡献是哪些，并决定哪些贡献是你想要接受的，哪些贡献是你应该礼貌地拒绝的。
为什么要费心做这些？
如果所有这些听起来像是大量的工作，那是有充分理由的：它确实是。 但这是一项有回报的工作，你可以通过很多方式从中获利。 开源工作以你从未意识到已经迟钝的方式磨练你的技能——从编写更清晰、更易于维护的代码到学习如何良好沟通和团队合作。 这也是一个有工作或有抱负的专业开发人员的最佳简历构建器；潜在的雇主可以访问你的存储库并查看你的能力，并且与你在社区项目中合作过的开发人员可能希望邀请你参与付费项目。
最终，从事开源项目——你自己的或其他人的——意味着个人成长，因为你正在做一些比你自己更大的事情。
1 条评论