Merge pull request #9718 from Valoniakim/master

[Translated] 20180308 What is open source programming.md

sources/talk/20180308 What is open source programming.md

@@ -1,97 +0,0 @@
-Translating by Valoniakim
-
-What is open source programming?
-======
-
-![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/code_computer_development_programming.png?itok=4OM29-82)
-
-At the simplest level, open source programming is merely writing code that other people can freely use and modify. But you've heard the old chestnut about playing Go, right? "So simple it only takes a minute to learn the rules, but so complex it requires a lifetime to master." Writing open source code is a pretty similar experience. It's easy to chuck a few lines of code up on GitHub, Bitbucket, SourceForge, or your own blog or site. But doing it right requires some personal investment, effort, and forethought.
-
-![](https://opensource.com/sites/default/files/styles/panopoly_image_original/public/u128651/floorgoban.jpeg?itok=r8gA5jOk)
-
-### What open source programming isn't
-
-Let's be clear up front about something: Just being on GitHub in a public repo does not make your code open source. Copyright in nearly all countries attaches automatically when a work is fixed in a medium, without need for any action by the author. For any code that has not been licensed by the author, it is only the author who can exercise the rights associated with copyright ownership. Unlicensed code—no matter how publicly accessible—is a ticking time bomb for anyone who is unwise enough to use it.
-
-A well-meaning author may think, "well, it's obvious this is free to use," and have no plans ever to sue anyone, but that doesn't mean the code is safe to use. No matter what you think someone will do, that author has the right to sue anyone who uses, modifies, or embeds that code anywhere else without an expressly granted license.
-
-Clearly, you shouldn't put your own code out in public without a license and expect others to use or contribute to it. I would also recommend you avoid using (or even looking at) such code yourself. If you create a highly similar function or routine to a piece of unlicensed work you inspected at some point in the past, you could open yourself or your employer to infringement lawsuits.
-
-Let's say that Jill Schmill writes AwesomeLib and puts it on GitHub without a license. Even if Jill never sues anybody, she might eventually sell all the rights to AwesomeLib to EvilCorp, who will. (Think of it as a lurking vulnerability, just waiting to be exploited.)
-
-Unlicensed code is unsafe code, period.
-
-### Choosing the right license
-
-OK, you've decided you want to write a new program, and you want people to have open source rights to use it. The next step is figuring out which [license][1] best fits your needs. You can get started with the GitHub-curated [choosealicense.com][2], which is just what it says on the tin. The site is laid out a bit like a simple quiz, and most people should be one or two clicks at most from finding the right license for their project.
-
-Unlicensed code is unsafe code, period.
-
-A word of caution: Don't get overly fancy or self-important. If you choose a commonly used and well-known license like the
-
-A word of caution: Don't get overly fancy or self-important. If you choose a commonly used and well-known license like the [Apache License][3] or the [GPLv3][4] , it's easy for people to understand what their rights are and what your rights are without needing a team of lawyers to look for pitfalls and problems. The further you stray from the beaten path, though, the more problems you open yourself and others up to.
-
-Most importantly, do not write your own license! Making up your own license is an unnecessary source of confusion for everyone. Don't do it. If you absolutely must have your own special terms that you can't find in any existing license, write them as an addendum to an otherwise well-understood license... and keep the main license and your addendum clearly separated so everyone involved knows which parts they've got to be extra careful about.
-
-I know some people stubborn up and say, "I don't care about licenses and don't want to think about them; it's public domain." The problem with that is that "public domain" isn't a universally understood term in a legal sense. It means different things from one country to the next, with different rights and terms attached. In some countries, you can't even place your own works in the public domain, because the government reserves control over that. Luckily, the [Unlicense][5] has you covered. The Unlicense uses as few words as possible to clearly describe what "just make it public domain!" means in a clear and universally enforceable way.
-
-### How to apply the license
-
-Once you've chosen a license, you need to clearly and unambiguously apply it. If you're publishing somewhere like GitHub or GitLab or BitBucket, you'll have what amounts to a folder structure for your project's files. In the root folder of your project, you should have a plaintext file called LICENSE.txt that contains the text of the license you selected.
-
-Putting LICENSE.txt in the root folder of your project isn't quite the last step—you also need a comment block declaring the license at the header of each significant file in your project. This is one of those times where it comes in handy to be using a well-established license. A comment that says: `# this work (c)2018 myname, licensed GPLv3—see https://www.gnu.org/licenses/gpl-3.0.en.html` is much, much stronger and more useful than a comment block that merely makes a cryptic reference to a completely custom license.
-
-If you're self-publishing your code on your own site, you'll want to follow basically the same process. Have a LICENSE.txt, put the full copy of your license in it, and link to your license in an abbreviated comment block at the head of each significant file.
-
-### Open source code is different
-
-A big difference between proprietary and open source code is that open source code is meant to be seen. As a 40-something sysadmin, I've written a lot of code. Most of it has been effectively proprietary—I started out writing code for myself to make my own jobs easier and scratch my own and/or my company's itches. The goal of such code is simple: All it has to do is work, in the exact way and under the exact circumstance its creator planned. As long as the thing you expected to happen when you invoked the program happens more frequently than not, it's a success.
-
-A big difference between proprietary and open source code is that open source code is meant to be seen.
-
-Open source code is very different. When you write open source code, you know that it not only has to work, it has to work in situations you never dreamed of and may not have planned for. Maybe you only had one very narrow use case for your code and invoked it in exactly the same way every time. The people you share it with, though... they'll expose use cases, mixtures of arguments, and just plain strange thought processes you never considered. Your code doesn't necessarily have to satisfy all of them—but it at least needs to handle their requests gracefully, and fail in predictable and logical ways when it can't service them. (For example: "Division by zero on line 583" is not an acceptable response to a failure to supply a command-line argument.)
-
-Open source code is very different. When you write open source code, you know that it not only has to work, it has to work in situations you never dreamed of and may not have planned for. Maybe you only had one very narrow use case for your code and invoked it in exactly the same way every time. The people you share it with, though... they'll expose use cases, mixtures of arguments, and just plain strange thought processes you never considered. Your code doesn't necessarily have to satisfy all of them—but it at least needs to handle their requests gracefully, and fail in predictable and logical ways when it can't service them. (For example: "Division by zero on line 583" is not an acceptable response to a failure to supply a command-line argument.)
-
-Your open source code also has to avoid unduly embarrassing you. That means that after you struggle and struggle to get a balky function or sub to finally produce the output you expected, you don't just sigh and move on to the next thing—you clean it up, because you don't want the rest of the world seeing your obvious house of cards. It means that you stop littering your code with variables like `$variable` and `$lol` and replace them with meaningful names like `$iterationcounter` or `$modelname`. And it means commenting things professionally (even if they're obvious to you in the heat of the moment) since you expect other people to be able to follow your code later.
-
-This can be a little painful and frustrating at first—it's work you're not accustomed to doing. It makes you a better programmer, though, and it makes your code better as well. Just as important: Even if you're the only contributor your project ever has, it saves you work in the long run. Trust me, a year from now when you have to revisit your app, you're going to be very glad that `$modelname`, which gets parsed by several stunningly opaque regular expressions before getting socked into some other array somewhere, isn't named `$lol` anymore.
-
-### You're not writing just for yourself
-
-The true heart of open source isn't the code at all: it's the community. Projects with a strong community survive longer and are adopted much more heavily than those that don't. With that in mind, it's a good idea not only to embrace but actively plan for the community you hope to build around your project.
-
-Batman might spend hundreds of hours in seclusion furiously building a project in secrecy, but you don't have to. Take to Twitter, Reddit, or mailing lists relevant to your project's scope, and announce that you're thinking of creating a new project. Talk about your design goals and how you plan to achieve them. Request input, listen to similar (but maybe not identical) use cases, and build that information into your process as you write code. You don't have to accept every suggestion or request—but if you know about them ahead of time, you can avoid pitfalls that require arduous major overhauls later.
-
-This process doesn't end with the initial announcement. If you want your project to be adopted and used by other people, you need to develop it that way too. This isn't a barrier to entry; it's just a pattern to use. So don't just hunker down privately on your own machine with a text editor—start a real, publicly accessible project at one of the big foundries, and treat it as though the community was already there and watching.
-
-### Ways to build a real public project
-
-You can open accounts for open source projects at GitHub, GitLab, or BitBucket for free. Once you've opened your account and created a repository for your project, use it—create a README, assign a LICENSE, and push code incrementally as you develop it. This will build the habits you'll need to work with a real team later as you get accustomed to writing your code in measurable, documented commits with clear goals. The further you go, the more likely you'll start generating interest—usually in the form of end users first.
-
-The users will start opening tickets, which will both delight and annoy you. You should take those tickets seriously and treat their owners courteously. Some of them will be based on tremendous misunderstandings of what your project is and what is or isn't within its scope—treat those courteously and professionally, also. In some cases, you'll guide those users into the fold of what you're doing. In others, however haltingly, they'll guide you into realizing the larger—or slightly differently centered—scope you probably should have planned for in the first place.
-
-If you do a good job with the users, eventually fellow developers will show up and take an interest. This will also both delight and annoy you. At first, you'll probably just get trivial bugfixes. Eventually, you'll start to get pull requests that would either hardcode really, really niche special use-cases into your project (which would be a nightmare to maintain) or significantly alter the scope or even the focus of your project. You'll need to learn how to recognize which contributions are which and decide which ones you want to embrace and which you should politely reject.
-
-### Why bother with all of this?
-
-If all of this sounds like a lot of work, there's a good reason: it is. But it's rewarding work that you can cash in on in plenty of ways. Open source work sharpens your skills in ways you never realized were dull—from writing cleaner, more maintainable code to learning how to communicate well and work as a team. It's also the best possible resume builder for a working or aspiring professional developer; potential employers can hit your repository and see what you're capable of, and developers you've worked with on community projects may want to bring you in on paying gigs.
-
-Ultimately, working on open source projects—yours or others'—means personal growth, because you're working on something larger than yourself.
-
---------------------------------------------------------------------------------
-
-via: https://opensource.com/article/18/3/what-open-source-programming
-
-作者：[Jim Salter][a]
-译者：[译者ID](https://github.com/译者ID)
-校对：[校对者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/

translated/talk/20180308 What is open source programming.md

@@ -0,0 +1,89 @@
+何为开源?
+======
+
+![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/code_computer_development_programming.png?itok=4OM29-82)
+
+简单来说，开源项目就是书写一些大家可以随意取用、修改的代码。但你肯定听过关于Go语言的那个笑话，说 Go 语言简单到看一眼就可以明白规则，但需要一辈子去学会运用它。其实写开源代码也是这样的。往 GitHub, Bitbucket, SourceForge 等网站或者是你自己的博客，网站上丢几行代码不是难事，但想要有效地操作，还需要个人的努力付出，和高瞻远瞩。
+
+![](https://opensource.com/sites/default/files/styles/panopoly_image_original/public/u128651/floorgoban.jpeg?itok=r8gA5jOk)
+
+### 我们对开源项目的误解
+
+首先我要说清楚一点：把你的代码写在 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/