何谓开源编程？
译自：https://opensource.com/article/18/3/what-open-source-programming
作者： Jim Salter
原创：LCTT https://linux.cn/article-10045-1.html
译者： Valonia Kim
开源就是丢一些代码到 GitHub 上。了解一下它是什么，以及不是什么？
最简单的来说，开源编程就是编写一些大家可以随意取用、修改的代码。但你肯定听过关于 Go 语言的那个老笑话，说 Go 语言“简单到看一眼就可以明白规则，但需要一辈子去学会运用它”。其实写开源代码也是这样的。往 GitHub、Bitbucket、SourceForge 等网站或者是你自己的博客或网站上丢几行代码不是难事，但想要卓有成效，还需要个人的努力付出和高瞻远瞩。
我们对开源编程的误解
首先我要说清楚一点：把你的代码放在 GitHub 的公开仓库中并不意味着把你的代码开源了。在几乎全世界，根本不用创作者做什么，只要作品形成，版权就随之而生了。在创作者进行授权之前，只有作者可以行使版权相关的权力。未经创作者授权的代码，不论有多少人在使用，都是一颗定时炸弹，只有愚蠢的人才会去用它。
有些创作者很善良，认为“很明显我的代码是免费提供给大家使用的。”，他也并不想起诉那些用了他的代码的人，但这并不意味着这些代码可以放心使用。不论在你眼中创作者们多么善良，他们都 有权力 起诉任何使用、修改代码，或未经明确授权就将代码嵌入的人。
很明显，你不应该在没有指定开源许可证的情况下将你的源代码发布到网上然后期望别人使用它并为其做出贡献。我建议你也尽量避免使用这种代码，甚至疑似未授权的也不要使用。如果你开发了一个函数和例程，它和之前一个疑似未授权代码很像，源代码作者就可以对你就侵权提起诉讼。
举个例子，Jill Schmill 写了 AwesomeLib 然后未明确授权就把它放到了 GitHub 上，就算 Jill Schmill 不起诉任何人，只要她把 AwesomeLib 的完整版权都卖给 EvilCorp，EvilCorp 就会起诉之前违规使用这段代码的人。这种行为就好像是埋下了计算机安全隐患，总有一天会为人所用。
没有许可证的代码的危险的，切记。
选择恰当的开源许可证
假设你正要写一个新程序，而且打算让人们以开源的方式使用它，你需要做的就是选择最贴合你需求的许可证。和宣传中说的一样，你可以从 GitHub 所支持的 choosealicense.com 开始。这个网站设计得像个简单的问卷，特别方便快捷，点几下就能找到合适的许可证。
警示：在选择许可证时不要过于自负，如果你选的是 Apache 许可证或者 GPLv3 这种广为使用的许可证，人们很容易理解他们和你都有什么权利，你也不需要请律师来排查其中的漏洞。你选择的许可证使用的人越少，带来的麻烦就越多。
最重要的一点是： 千万不要试图自己制造许可证！ 自己制造许可证会给大家带来更多的困惑和困扰，不要这样做。如果在现有的许可证中确实找不到你需要的条款，你可以在现有的许可证中附加上你的要求，并且重点标注出来，提醒使用者们注意。
我知道有些人会站出来说：“我才懒得管什么许可证，我已经把代码发到公开领域了。”但问题是，公开领域的法律效力并不是受全世界认可的。在不同的国家，公开领域的效力和表现形式不同。在有些国家的政府管控下，你甚至不可以把自己的源代码发到公开领域。万幸，Unlicense 可以弥补这些漏洞，它语言简洁，使用几个词清楚地描述了“就把它放到公开领域”，但其效力为全世界认可。
怎样引入许可证
确定使用哪个许可证之后，你需要清晰而无疑义地指定它。如果你是在 GitHub、GitLab 或 BitBucket 这几个网站发布，你需要构建很多个文件夹，在根文件夹中，你应把许可证创建为一个以 LICENSE.txt 命名的明文文件。
创建 LICENSE.txt 这个文件之后还有其它事要做。你需要在每个重要文件的头部添加注释块来申明许可证。如果你使用的是一个现有的许可证，这一步对你来说十分简便。一个 # 项目名 (c)2018 作者名，GPLv3 许可证，详情见 https://www.gnu.org/licenses/gpl-3.0.en.html 这样的注释块比隐约指代的许可证的效力要强得多。
如果你是要发布在自己的网站上，步骤也差不多。先创建 LICENSE.txt 文件，放入许可证，再表明许可证出处。
开源代码的不同之处
开源代码和专有代码的一个主要区别是开源代码写出来就是为了给别人看的。我是个 40 多岁的系统管理员，已经写过许许多多的代码。最开始我写代码是为了工作，为了解决公司的问题，所以其中大部分代码都是专有代码。这种代码的目的很简单，只要能在特定场合通过特定方式发挥作用就行。
开源代码则大不相同。在写开源代码时，你知道它可能会被用于各种各样的环境中。也许你的用例的环境条件很局限，但你仍旧希望它能在各种环境下发挥理想的效果。不同的人使用这些代码时会出现各种用例，你会看到各类冲突，还有你没有考虑过的思路。虽然代码不一定要满足所有人，但至少应该得体地处理他们遇到的问题，就算解决不了，也可以转换回常见的逻辑，不会给使用者添麻烦。（例如“第 583 行出现零除错误”就不能作为错误地提供命令行参数的响应结果）
你的源代码也可能逼疯你，尤其是在你一遍又一遍地修改错误的函数或是子过程后，终于出现了你希望的结果，这时你不会叹口气就继续下一个任务，你会把过程清理干净，因为你不会愿意别人看出你一遍遍尝试的痕迹。比如你会把 $variable、$lol 全都换成有意义的 $iterationcounter 和 $modelname。这意味着你要认真专业地进行注释（尽管对于你所处的背景知识热度来说它并不难懂），因为你期望有更多的人可以使用你的代码。
这个过程难免有些痛苦沮丧，毕竟这不是你常做的事，会有些不习惯。但它会使你成为一位更好的程序员，也会让你的代码升华。即使你的项目只有你一位贡献者，清理代码也会节约你后期的很多工作，相信我一年后你再看你的 app 代码时，你会庆幸自己写下的是 $modelname，还有清晰的注释，而不是什么不知名的数列，甚至连 $lol 也不是。
你并不是为你一人而写
开源的真正核心并不是那些代码，而是社区。更大的社区的项目维持时间更长，也更容易为人们所接受。因此不仅要加入社区，还要多多为社区发展贡献思路，让自己的项目能够为社区所用。
蝙蝠侠为了完成目标暗中独自花了很大功夫，你用不着这样，你可以登录 Twitter、Reddit，或者给你项目的相关人士发邮件，发布你正在筹备新项目的消息，仔细聊聊项目的设计初衷和你的计划，让大家一起帮忙，向大家征集数据输入，类似的使用案例，把这些信息整合起来，用在你的代码里。你不用接受所有的建议和请求，但你要对它有个大概把握，这样在你之后完善时可以躲过一些陷阱。
发布了首次通告这个过程还不算完整。如果你希望大家能够接受你的作品并且使用它，你就要以此为初衷来设计。公众说不定可以帮到你，你不必对公开这件事如临大敌。所以不要闭门造车，既然你是为大家而写，那就开设一个真实、公开的项目，想象你在社区的帮助和监督下，认真地一步步完成它。
建立项目的方式
你可以在 GitHub、GitLab 或 BitBucket 上免费注册账号来管理你的项目。注册之后，创建知识库，建立 README 文件，分配一个许可证，一步步写入代码。这样可以帮你建立好习惯，让你之后和现实中的团队一起工作时，也能目的清晰地朝着目标稳妥地开展工作。这样你做得越久，就越有兴趣 —— 通常会有用户先对你的项目产生兴趣。
用户会开始提一些问题，这会让你开心也会让你不爽，你应该亲切礼貌地对待他们，就算他们很多人对项目有很多误解甚至根本不知道你的项目做的是什么，你也应该礼貌专业地对待。一方面，你可以引导他们，让他们了解你在干什么。另一方面，他们也会慢慢地将你带入更大的社区。
如果你的项目很受用户青睐，总会有高级开发者出现，并表示出兴趣。这也许是好事，也可能激怒你。最开始你可能只会做简单的问题修复，但总有一天你会收到拉取请求，有可能是硬编码或特殊用例（可能会让项目变得难以维护），它可能改变你项目的作用域，甚至改变你项目的初衷。你需要学会分辨哪个有贡献，根据这个决定合并哪个，婉拒哪个。
我们为什么要开源？
开源听起来任务繁重，它也确实是这样。但它对你也有很多好处。它可以在无形之中磨练你，让你写出纯净持久的代码，也教会你与人沟通，团队协作。对于一个志向远大的专业开发者来说，它是最好的简历素材。你的未来雇主很有可能点开你的仓库，了解你的能力范围；而社区项目的开发者也有可能给你带来工作。
最后，为开源工作，意味着个人的提升，因为你在做的事不是为了你一个人，这比养活自己重要得多。
via: https://opensource.com/article/18/3/what-open-source-programming
作者：Jim Salter 译者：Valoniakim 校对：wxy、pityonline