From 8e6afa9a40059b151b1ee9d56983e727450975b9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=89=9B=E4=BA=94=E6=96=B9?= Date: Wed, 28 Oct 2020 16:42:17 +0800 Subject: [PATCH] =?UTF-8?q?update=20=E7=AC=AC=E5=9B=9B=E9=83=A8=E5=88=86?= =?UTF-8?q?=E2=80=94=E2=80=94=E5=90=AF=E5=8A=A8=E8=87=AA=E5=B7=B1=E7=9A=84?= =?UTF-8?q?=E5=BC=80=E6=BA=90=E9=A1=B9=E7=9B=AE/=E6=9C=89=E4=BA=86?= =?UTF-8?q?=E5=BC=80=E6=BA=90=E7=9A=84=E6=83=B3=E6=B3=95=E5=90=8E=E4=BB=8E?= =?UTF-8?q?=E4=BD=95=E5=BC=80=E5=A7=8B.md.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...16\344\275\225\345\274\200\345\247\213.md" | 107 +++++++++++++++++- 1 file changed, 106 insertions(+), 1 deletion(-) diff --git "a/\347\254\254\345\233\233\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" "b/\347\254\254\345\233\233\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" index 18cb860..f1ea1e8 100644 --- "a/\347\254\254\345\233\233\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" +++ "b/\347\254\254\345\233\233\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" @@ -1 +1,106 @@ -> 先有项目后开源，还是从零开始做开源？两种方式分别需要做些什么？不同的方式有什么利弊吗？ \ No newline at end of file +> 先有项目后开源，还是从零开始做开源？两种方式分别需要做些什么？不同的方式有什么利弊吗？ + + **选择开源许可证** + +在发布你的代码之前，最重要的一个事情就是选择一个开源许可证。选择不同的开源许可证会影响你项目的参与者。所有的开源许可证都会保留你个人作为代码创建者的版权。虽然许可证的授权概念有点复杂，但一些常用的许可证和基本的东西还是要了解的。（如果你的开源项目属于公司性质，在选择许可证之前先咨询一下公司的法律顾问） + + **GPL** + +GNU公共协议是为GNU项目而创建，并且随着linux作为一种可变的操作系统已被大家所接受，GPL许可要求任何使用基于GPL授权的组件也必须要在GPL下可用。简单而言之，任何使用基于GPL授权的组件在任何方式下都必须在GPL许可下开源。GPL授权的程序没有在使用上限制，这个限制仅仅和派生作品的修改和发布有关 + +GNU宽通用公共许可证是一种GPL更加宽松的版本。基于LGPL授权的组件可能关联到程序，但是程序本身并不必开源或者基于GPL或LGPL授权，换句话说，LGPL和GPL相似，因此任何派生作品也必须开源。 + + **MIT** + +亦被称为X11协议。该协议相对宽松，对于使用该协议的项目，协议的遵循者必须自动放弃对该项目代码发布权以及使用权的私有，而赋予公众相应权利。因此，遵循MIT协议的代码或许被会被引用在一些没有声明遵循某项协议的特定代码中。此外，MIT协议与GPL协议兼容，所以你完全可以用MIT协议下的代码来开发GPL协议的应用。 + + **BSD3** + +协议有点松，有点松……该协议相对宽松，对于使用该协议的项目，协议的遵循者必须自动放弃对该项目代码发布权以及使用权的私有，而赋予公众相应权利。此外，项目中任何以二进制形式发布的代码（译者注：貌似.bin文件之类的），也需要在许可文档中声明该协议。那么，该协议与MIT协议的区别在哪里呢？当该协议的标的物（译者注：一般，这里的“标的物”是声明使用该协议的代码，为了保证严谨性，在此进行注释）被其他人使用时，他们不可以用该标的物的所有权人的名字进行商业宣传。例如，如果我写了一段遵循该协议的代码，而你把他用着自己的应用里面，你是不可以用哥哥我的名字去做宣传的，除非经过我的同意。最后，BSD3协议也是和GPL兼容的。 + +好吧，其实还有很多开源协议本文没有介绍，但是以上协议应该是最受大家关注的。 + + **open-source** + +需要注意的一点是 Creative Commons许可证并非设计来于软件的. 所有的 Creative Commons许可证都是为"创造性工作"制定的, 例如音频, 图像, 视频和文字. 制定 Creative Commons 的组织他们自己也不推荐将 Creative Commons许可证用于软件, 应该在软件中使用专门为软件制定的许可证, 通常也就是上文讨论的四种. 因此, 你应该选择哪个许可证呢? 这点大部分由你想别人怎么使用你的代码决定. 因为LGPL, MIT 和 BSD3都和GPL完全兼容, 这还不是最需要关注的. 如果你想所有你软件的修改版本都只被用于开源软件, 那么你应该选择GPL. 如果你的代码是设计成一个不需要修改而可以直接引入别人的项目使用的组件, 那么你可能会考虑LGPL. 否则, MIT和BSD3许可证时比较通常的选择. 个人比较趋向于喜好MIT许可证, 而商业上可能更加的偏向于喜好BSD3许可证以保证他们的公司名称不会被未授权的使用. +为了帮助你做决定, 看一下这些流行的开源软件项目都使用了些什么协议: + +- jQuery: MIT license +- YUI: BSD3 license +- Dojo Toolkit: dual-licenced under BSD3 and Academic Free License +- Backbone: MIT license + +另外一个选择就是直接把你的代码发布为 public domain(公有领域), 在 public domain中的代码没有版权拥有者, 这些代码可以完全随意使用. 如果你没有打算保持你对代码的控制全 或者 你只是想向世界分享你的代码而不打算持续开发它, 那就可以考虑一下把代码发布到 public domain. 想进一步了解许可证与它们相关的法律问题以及这些许可证如何工作, 请阅读 David Bushell的 Understanding Copyright and Licenses. +代码组织 + +决定在你的开源项目中使用何种许可证以后, 这几乎是时候把你的代码放出来了. 但是在这之前, 你得先看看代码是怎么组织的. 不是所有代码都会得到大家的贡献. 如果一个潜在的贡献者无法通读你的代码, 那么他非常可能也没法做出任何贡献. 在你分享你的代码给公众之前, 你组织代码的方式, 包括文件目录结构, 代码风格都是需要认真考虑的因素. 别随意把你胡乱写的代码扔出来. 多花点时间考虑别人可能会怎么阅读你的代码以及他们在这过程中可能会遇到什么问题. + +很多对开源项目的抱怨是由于缺乏文档。写文档往往没有写程序来得有趣，但对于开源项目成功却至关重要。如果你不想要别人使用你的软件，不想要人们贡献代码，那么只要不提供文档就行了。 + +文档应该很容易被更新，而且不需要push代码就可以更新，必须能根据用户的反馈快速地修改。也就是说，不要把文档与代码放在一个仓库里。如果你把代码放在GitHub上，那么可以用GitHub内置的wiki来放文档。 +最终用户文档 + +无论你写的是命令行程序、应用框架、工具库还是其它什么东东，都要把最终用户深深地放在脑海里。最终用户并不是修改你代码的人，而是使用你代码的人。对你的代码满意的最终用户们最后会成为贡献者，因为他们看到了蕴含在代码中的价值。 + + **开发者指南** + +即时你的代码布局合理，文档丰富，也无法保证一定会有贡献者出现。你需要一份开发者指南，让那些贡献者们快速融入进来。一份好的开发者指南应该有下面这些内容： + +1. 如何获取源代码：你当然希望贡献者们都知道怎么check out代码，但世事无绝对。一份友好的介绍总是受人欢迎的。 +1. 代码是如何组织的：即使你的代码和目录结构很清晰，完全能自我说明，也最好写下来，总有用处的。 +1. 如何设置构建系统：如果你用了某种构建系统，那么应该提供一份怎么设置这个系统的说明。如果构建时的一些依赖项没有包含在你的仓库中，那么这份说明中还应该包括怎么获取这些依赖项的信息。 +1. 如何构建：如何进行构建以及单元测试的步骤。 +1. 如何贡献：详细列出贡献的规则。如果你需要人进行单元测试，那么写上去。如果你需要人编写文档，那么也写上去。给出一个检查表，这样大家在提交贡献之前可以先逐项检查一下。 +1. 在与贡献者们的交流基础上，同时也参考了其它人问的一些问题。我认为，开发者指南与其它文档一样，应当是一个活跃的文档，它应当随着项目的成长而不断成长。 +1. 邮件列表的使 +用 + +所有优秀的开源项目都会给出一个地方，让大家提问。最简单的方法是设置一个邮件列表。 + + **使用版本号** + +开放源代码项目的一个常见的错误是忽视使用版本号。版本号对项目的长期稳定和维护时相当重要的。 + +将每个发布的版本用官方的版本号来标记，当有人提交bug时，你可以询问他们使用的版本并检查bug是否已经修补。这大大缩短了我花在报告bug 上的时间因为我可以马上知道用户是否在使用最新版本。 +除非你的项目以前有过使用并已经通过审核， 否则以0.1.0位启动版本号并递增每个后续发布的版本。 + +不要误解。这里并没有什么规则来规定在一个项目中如何增加版本号，尽管这里有些值得参考的东西 Apache APR Versioning and Semantic Versioning. 我只是挑出来一些并遵循罢了。 + +除了对项目跟踪的帮助，版本号当然还可以为你的项目做一些其他的事情。 + + **源码控制中的标记版本** + +当你决定要发布一个新版本时，应用源码控制标记来标注此版本的代码状态。 + +要让标记和版本号的绑定关系更明确，就把版本号直接包含在标记名称中。 + + **变更日志** + +版本管理还有一个好处就是能够生成变更日志。不管是对最终用户和贡献者，变更日志都是沟通版本差异时的重要依据。版本标记和源码控制有一个附加好处，你能基于这些标记自动生成变更日志。 + + **可用宣告** + +每当项目发布一个新版本时，都应该在某处发布宣告。不论是在你的博客或邮件列表或是在两者上都发布，正式宣告项目新版本已经可用是非常重要的。这份宣告应该包括项目代码的主要改动及其贡献者。对贡献者工作的认同是对他们的最大鼓励，能从贡献代码中获得更多的认同感他们就更有动力做更多的贡献。所以给予那些耗费无数精力在你的项目中的开发者以最大的赞扬吧。 + + **管理代码贡献** + +万事俱备，下一步就是解决如何接受代码贡献。 你的贡献模型是非常规范还是很随意，取决于你的喜好和目标。对应个人项目，可能不需要什么规范的贡献流程。开发者指南应该说明合并代码到仓库的必要条件，一个提交先要满足这些条件才会被接受。对于更大的项目，应该要有更多规范的策略。 + +首先要考虑的是是否需要一个贡献者许可协议（CLA）。CLA在很多大型开源项目中使用以保护项目的合法权利。每位提交代码的开发者都需要同意CLA，以承诺任何贡献的代码都是原创的同时将代码的版权移交给项目所有。CLA也赋予项目所有者将贡献的代码作为项目一部分的授权，而且要求贡献者保证不会故意将他人具有版权、专利或其他权利的代码包含在自己的代码中进行提交。 + + **贡献者** + +任何对项目做过代码贡献的人都可以算作贡献者。贡献者不能直接访问代码仓库，但是提交的补丁可以被接受。 + + **提交者** + +提交者有权限直接访问代码仓库。他们经常对项目做特性添加和bug修正，也能够直接提交代码到代码仓库。 + + **审查者** + +审查者是更高一级的贡献者，是能够对项目产生直接影响的指挥官。他们的职责就是审查贡献者和提交者提交的代码，批准或者否决补丁，任命或者撤销提交者称号，总的来说就是运作这个项目。 + +如果你打算采用刚才所说的权限层次，那么接下来就需要起草一份文档来描述每种类型的贡献者的角色和贡献者角色如何通过排名来进行提升。 + +[引用1](https://www.oschina.net/translate/starting-open-source-project?print) +[引用2](https://blog.csdn.net/duxinshuxiaobian/article/details/108186657) \ No newline at end of file -- Gitee