mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
90 lines
10 KiB
Markdown
90 lines
10 KiB
Markdown
|
何为开源?
|
|||
|
|
======
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
简单来说，开源项目就是书写一些大家可以随意取用、修改的代码。但你肯定听过关于Go语言的那个笑话，说 Go 语言简单到看一眼就可以明白规则，但需要一辈子去学会运用它。其实写开源代码也是这样的。往 GitHub, Bitbucket, SourceForge 等网站或者是你自己的博客，网站上丢几行代码不是难事，但想要有效地操作，还需要个人的努力付出，和高瞻远瞩。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
### 我们对开源项目的误解
|
|||
|
|
|
|||
|
|
首先我要说清楚一点：把你的代码写在 GitHub 的公开资源库中并不意味着把你的代码开源化了。在几乎全世界，根本不用创作者做什么，只要作品形成，版权就随之而生了。在创作者进行授权之前，只有作者可以行使版权相关的权力。未经创作者授权的代码，不论有多少人在使用，都是一颗定时炸弹，只有愚蠢的人才会去用它。
|
|||
|
|
|
|||
|
|
有些创作者很善良，认为“很明显我的代码是免费提供给大家使用的。”，他也并不想起诉那些用了他的代码的人，但这并不意味着这些代码可以放心使用。不论在你眼中创作者们多么善良，他们都是有权力起诉任何使用、修改代码，或未经明确授权就将代码嵌入的人。
|
|||
|
|
|
|||
|
|
很明显，你不应该在没有指定开源许可证的情况下将你的源代码发布到网上然后期望别人使用它并为其做出贡献，我建议你也尽量避免使用这种代码，甚至疑似未授权的也不要使用。如果你开发了一个函数和实现，它和之前一个疑似未授权代码很像，源代码作者就可以对你就侵权提起诉讼。
|
|||
|
|
|
|||
|
|
举个例子， Jill Schmill 写了 AwesomeLib 然后未明确授权就把它放到了 GitHub 上，就算 Jill Schmill 不起诉任何人，只要她把 AwesomeLib 的完整版权都卖给 EvilCorp，EvilCorp 就会起诉之前违规使用这段代码的人。这种行为就好像是埋下了计算机安全隐患，总有一天会为人所用。
|
|||
|
|
|
|||
|
|
没有许可证的代码的危险的，以上。
|
|||
|
|
|
|||
|
|
### 选择恰当的开源许可证
|
|||
|
|
|
|||
|
|
假设你证要写一个新程序，而且打算把它放在开源平台上，你需要选择最贴合你需求的[许可证][1]。和宣传中说的一样，你可以从 [GitHub-curated][2] 上得到你想要的信息。这个网站设置得像个小问卷，特别方便快捷，点几下就能找到合适的许可证。
|
|||
|
|
|
|||
|
|
没有许可证的代码的危险的，切记。
|
|||
|
|
|
|||
|
|
在选择许可证时不要过于自负，如果你选的是 [Apache License][3] 或者 [GPLv3][4] 这种广为使用的许可证，人们很容易理解其对于权利的规划，你也不需要请律师来排查其中的漏洞。你选择的许可证使用的人越少，带来的麻烦越多。
|
|||
|
|
|
|||
|
|
最重要的一点是：千万不要试图自己编造许可证！自己编造许可证会给大家带来更多的困惑和困扰，不要这样做。如果在现有的许可证中确实找不到你需要的程式，你可以在现有的许可证中附加上你的要求，并且重点标注出来，提醒使用者们注意。
|
|||
|
|
|
|||
|
|
我知道有些人会说：“我才懒得管什么许可证，我已经把代码发到公共域了。”但问题是，公共域的法律效力并不是受全世界认可的。在不同的国家，公共域的效力和表现形式不同。有些国家的政府管控下，你甚至不可以把自己的源代码发到公共域中。万幸，[Unlicense][5] 可以弥补这些漏洞，它语言简洁，但其效力为全世界认可。
|
|||
|
|
|
|||
|
|
### 怎样引入许可证
|
|||
|
|
|
|||
|
|
确定使用哪个许可证之后，你需要明文指定它。如果你是在 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, or BitBucket 上免费注册账号来管理你的项目。注册之后，创建知识库，建立 README 文件，分配一个许可证，一步步写入代码。这样可以帮你建立好习惯，让你之后和现实中的团队一起工作时，也能目的清晰地朝着目标稳妥地进行工作。这样你做得越久，就越有兴趣。
|
|||
|
|
|
|||
|
|
用户们会开始对你产生兴趣，这会让你开心也会让你不爽，但你应该亲切礼貌地对待他们，就算他们很多人根本不知道你的项目做的是什么，你可以把文件给他们看，让他们了解你在干什么。有些还在犹豫的用户可以给你提个醒，告诉你最开始设计的用户范围中落下了哪些人。
|
|||
|
|
|
|||
|
|
如果你的项目很受用户青睐，总会有开发者出现，并表示出兴趣。这也许是好事，也可能激怒你。最开始你可能只会做简单的错误修正，但总有一天你会收到拉请求，有可能是特殊利基案例，它可能改变你项目的作用域，甚至改变你项目的初衷。你需要学会分辨哪个有贡献，根据这个决定合并哪个，婉拒哪个。
|
|||
|
|
|
|||
|
|
### 我们为什么要开源？
|
|||
|
|
|
|||
|
|
开源听起来任务繁重，它也确实是这样。但它对你也有很多好处。它可以在无形之中磨练你，让你写出纯净持久的代码，也教会你与人沟通，团队协作。对于一位志向远大的专业开发者来说，它是最好的简历书写者。你的未来雇主很有可能点开你的知识库，了解你的能力范围；而你的开发者也有可能想带你进全球信息网络工作。
|
|||
|
|
|
|||
|
|
最后，为开源工作，意味着个人的提升，因为你在做的事不是为了你一个人，这比养活自己重要得多。
|
|||
|
|
|
|||
|
|
--------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
via: https://opensource.com/article/18/3/what-open-source-programming
|
|||
|
|
|
|||
|
|
作者：[Jim Salter][a]
|
|||
|
|
译者：[Valoniakim](https://github.com/Valoniakim)
|
|||
|
|
校对：[校对者ID](https://github.com/校对者ID)
|
|||
|
|
|
|||
|
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|||
|
|
|
|||
|
|
[a]:https://opensource.com/users/jim-salter
|
|||
|
|
[1]:https://opensource.com/tags/licensing
|
|||
|
|
[2]:https://choosealicense.com/
|
|||
|
|
[3]:https://choosealicense.com/licenses/apache-2.0/
|
|||
|
|
[4]:https://choosealicense.com/licenses/gpl-3.0/
|
|||
|
|
[5]:https://choosealicense.com/licenses/unlicense/
|