diff --git a/.gitignore b/.gitignore index 4870b98cea7d60d4487b0ea44cc74101fc2c99b5..fb787d6d6a85fcddbfb36efe72293f879668ad70 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ /*.ipr /*.iws /*.iml +/.idea diff --git "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\344\274\201\344\270\232\350\247\206\350\247\222\347\234\213\345\276\205\345\274\200\346\272\220.md" "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\344\274\201\344\270\232\350\247\206\350\247\222\347\234\213\345\276\205\345\274\200\346\272\220.md" index 35b130283697983ebdf429fd4c75ae1fec3dd50d..760a2595f896c22c96397e50f78ffa7818905167 100644 --- "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\344\274\201\344\270\232\350\247\206\350\247\222\347\234\213\345\276\205\345\274\200\346\272\220.md" +++ "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\344\274\201\344\270\232\350\247\206\350\247\222\347\234\213\345\276\205\345\274\200\346\272\220.md" @@ -72,13 +72,13 @@ ## 企业为什么会主动贡献开源 - 1.吸引人才： 当贵司依赖开源软件，那么寻找人才最好的地方莫过于熟悉项目内部本身，而且还是项目社区成员。通过在社区的公开的工作，贵司可以吸引到一些既是做自己喜欢的工作，还能获得一定报酬的人。尤其重要的一点，贵司现有的项目参与的员工，每天都会和他们在一起打交道，自然是非常熟悉的，找到他们也很容易； +1. 吸引人才：当贵司依赖开源软件，那么寻找人才最好的地方莫过于熟悉项目内部本身，而且还是项目社区成员。通过在社区的公开的工作，贵司可以吸引到一些既是做自己喜欢的工作，还能获得一定报酬的人。尤其重要的一点，贵司现有的项目参与的员工，每天都会和他们在一起打交道，自然是非常熟悉的，找到他们也很容易； - 2.降低维护成本： 如果一个企业开始在本地的分支做缺陷修复、增加新的功能，然而却没有将这些代码提交到上游的开源项目中，那么很快维护本地的分支，将成为该公司的一个成本噩梦。将上游作为优先的提交缺陷修复和增加新功能是最为明智的做法，因为这样的维护成本最低； +2. 降低维护成本：如果一个企业开始在本地的分支做缺陷修复、增加新的功能，然而却没有将这些代码提交到上游的开源项目中，那么很快维护本地的分支，将成为该公司的一个成本噩梦。将上游作为优先的提交缺陷修复和增加新功能是最为明智的做法，因为这样的维护成本最低； - 3.项目影响力： 在一个开源的项目中，新的特性或功能来自社区的贡献，那么这些贡献就会影响到项目的走向，如果你认为为项目所贡献的新功能对于贵司非常的重要，那么你应该去安排积极的贡献者对这些功能进行开发和实现。通过贵司的贡献，自然而然就可以影响到项目的走向； +3. 项目影响力：在一个开源的项目中，新的特性或功能来自社区的贡献，那么这些贡献就会影响到项目的走向，如果你认为为项目所贡献的新功能对于贵司非常的重要，那么你应该去安排积极的贡献者对这些功能进行开发和实现。通过贵司的贡献，自然而然就可以影响到项目的走向； - 4.有利可图：商本逐利，无可厚非。一方面，对现有开源项目的贡献可以让企业在降低维护成本的同时促进相关业务的发展，获取利润；另一方面，开源本公司的个别项目吸引全球各地的开发者共同维护，借助开源的优势扩大该项目在本行业的影响力，扩大市场占有率，在保持项目开源继续发展的前提下，通过附加其他手段来获取丰厚的利润回报； +4. 有利可图：商本逐利，无可厚非。一方面，对现有开源项目的贡献可以让企业在降低维护成本的同时促进相关业务的发展，获取利润；另一方面，开源本公司的个别项目吸引全球各地的开发者共同维护，借助开源的优势扩大该项目在本行业的影响力，扩大市场占有率，在保持项目开源继续发展的前提下，通过附加其他手段来获取丰厚的利润回报； ``` 总体上讲，尚属比较初级的阶段，还需要补充和完善很多内容，比如，提出了一些问题，但没有给出适当的解答；对于企业主动贡献开源这块，说的比较少。 diff --git "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\205\263\344\272\216\345\274\200\346\272\220\345\237\272\351\207\221\344\274\232.md" "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\205\263\344\272\216\345\274\200\346\272\220\345\237\272\351\207\221\344\274\232.md" index b8422d4ae807ec1f8a78dd9bfa271cc1ed357939..72af56671ad8f9b1105131ff928bcfa216f79b23 100644 --- "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\205\263\344\272\216\345\274\200\346\272\220\345\237\272\351\207\221\344\274\232.md" +++ "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\205\263\344\272\216\345\274\200\346\272\220\345\237\272\351\207\221\344\274\232.md" @@ -5,8 +5,6 @@ 3. 提供日常的运营和治理支持，如财务和现金服务、会员管理以及项目的沟通和公关相关。 开源项目组织（Open Source Initiative）的委员会主席 Allison Randal 说：「许多公司认为，自己可以通过一家可以信赖的独立的非营利机构，与其他公司一起搞开源项目，这对它们来说特别重要。」她补充说：「彼此竞争的公司通常在合作上面临巨大障碍。能够进入一家中立、不竞争的基金会，大有用处。」软件基金会为开源项目提供了许多服务，包括拥有硬件、与供应商签合同，甚至聘用员工。它们还起到了防火墙的功效，可以保护贡献者，避免合同责任或者法律起诉（比如疏忽）。它们还为项目参与者提供了许可、版权、专利及其他知识产权管理等方面的一个法律框架。Apache 软件基金会和自由软件基金会之类的基金会甚至为监管的项目开发了自己的自由软件许可证（分别是 Apache 许可证和 GPL 许可证），这些许可证还可用于更为一般的用途。大多数基金会还提供了技术服务，比如软件库和代码签名证书，另外还提供了比较普通的商业服务，比如提供银行账户、管理项目成员以及发表声明和新闻稿。但并非所有软件基金会都相同：一些基金会致力于单单一个开源项目，一些充当多个项目的大本营，还有一些不太关注项目，更加关注推广宣传整个开源软件。以下是八家比较重要的开源基金会： - - ### 1. Apache 软件基金会 @@ -16,7 +14,6 @@ Apache 软件基金会（ASF）提供了组织、法律和财务等方面的支 其孵化器项目还为期望加入该基金会的项目（和代码库）提供了一条道路。 - ### 2. Linux 基金会 ![输入图片说明](https://images.gitee.com/uploads/images/2020/1204/190041_d97025e2_5694891.png "屏幕截图.png") @@ -25,14 +22,11 @@ Linux 基金会支持 Linux 内核。这本身很重要，因为 Linux 内核是 Linux 基金会还监管大型的协作项目，包括 Xen 项目、Kinetic 开放存储项目和核心基础设施项目（Core infrastructure Initiative），项目贡献者来自大型商业机构，包括谷歌、IBM、英特尔、思科和惠普。 - ### 3. 开放原子开源基金会 ![输入图片说明](https://images.gitee.com/uploads/images/2020/1204/190225_2ad60ba9_5694891.png "屏幕截图.png") -[开放原子开源基金会](https://www.openatom.org/)不仅是中国首个，也是目前唯一一个以开源为主题的基金会。据公开信息显示，该基金会由中华人民共和国民政部登记注册、工业和信息化部主管，是旨在推动开源公益事业发展的非营利性、公益性法人。 基金会业务范围包括募集资金、专项资助、宣传推广教育培训、学术交流、国际合作、开源生态建设、咨询服务等开源相关的活动,2020 年 6 月 15 日于北京成立登记。开放原子开源基金会与 Apache 基金会、Linux 基金会一样。监管大型的协作项目，包括 XuperChain、OpenHarmony、PIKA、TKEStack 等重量级开源项目。 - - +[开放原子开源基金会](https://www.openatom.org/) 不仅是中国首个，也是目前唯一一个以开源为主题的基金会。据公开信息显示，该基金会由中华人民共和国民政部登记注册、工业和信息化部主管，是旨在推动开源公益事业发展的非营利性、公益性法人。基金会业务范围包括募集资金、专项资助、宣传推广教育培训、学术交流、国际合作、开源生态建设、咨询服务等开源相关的活动，2020 年 6 月 15 日于北京成立登记。开放原子开源基金会与 Apache 基金会、Linux 基金会一样。监管大型的协作项目，包括 XuperChain、OpenHarmony、PIKA、TKEStack 等重量级开源项目。 ### 4. Eclipse 基金会 @@ -41,7 +35,6 @@ Linux 基金会还监管大型的协作项目，包括 Xen 项目、Kinetic 开 Eclipse 基金会成立于 2004 年，旨在支持一个软件开发开源社区，以便构建、部署和管理软件。最知名的项目是 Eclipse 开发环境，但基金会还支持另外大约 200 个处于不同成熟阶段的项目，包括商业智能和报表工具以及物联网等项目。 Eclipse 基金会委员会的代表来自各大科技公司，包括谷歌、IBM、甲骨文和 SAP、爱立信。 - ### 5. 云原生计算基金会（CNCF） ![输入图片说明](https://images.gitee.com/uploads/images/2020/1204/185019_43cb87e5_5406987.png "CNCF.png") @@ -64,7 +57,6 @@ CNCF 是一个开源软件基金会，致力于使云原生计算具有普遍性 OpenStack 基金会的目的是，提供一系列共享资源，扩大 OpenStack 公有云和私有云的普及范围，服务于广大开发人员、用户和整个生态系统，支持看好这个平台的技术厂商，并且帮助开发人员开发云软件。 - ### 8. 软件自由管理委员会 ![输入图片说明](https://images.gitee.com/uploads/images/2020/1204/185728_2a4fd21a_5406987.jpeg "7.jpeg") @@ -74,7 +66,6 @@ OpenStack 基金会的目的是，提供一系列共享资源，扩大 OpenStack 软件自由管理委员会还运作一个 GPL 合规项目，该项目旨在执行 GPL。它目前在帮助出钱出力，支持指控 VMware 涉嫌违反 GPL 的诉讼。 - ### 9. 自由软件基金会 ![输入图片说明](https://images.gitee.com/uploads/images/2020/1204/185744_24f8e47b_5406987.jpeg "8.jpeg") @@ -87,6 +78,6 @@ OpenStack 基金会的目的是，提供一系列共享资源，扩大 OpenStack ![输入图片说明](https://images.gitee.com/uploads/images/2020/1204/185756_8c42cddf_5406987.jpeg "9.jpeg") -开放源码组织（Open Source Initiative）的涉足领域与自由软件基金会一样，原因在于它的初衷是支持整个软件运动，而不是支持任何某一个项目。但是相比自由软件基金会关注的重心是软件“自由”，开放源码组织谈论的却是开源软件，旨在实现下列目标： +开放源码组织（Open Source Initiative）的涉足领域与自由软件基金会一样，原因在于它的初衷是支持整个软件运动，而不是支持任何某一个项目。但是相比自由软件基金会关注的重心是软件「自由」，开放源码组织谈论的却是开源软件，旨在实现下列目标： -用开放源码组织的创始成员 Michael Tiemann 的话来说：「摈弃与『自由软件』有关的说教和对抗的态度，改而在『务实、注重商业理由的基础』上推广宣传开源理念。」开放源码组织积极普及和倡导开源，它是“开源“的定义者强调（Open Source Definition），并负责审批某个许可证是否符合其对“开源”的定义。 \ No newline at end of file +用开放源码组织的创始成员 Michael Tiemann 的话来说：「摈弃与『自由软件』有关的说教和对抗的态度，改而在『务实、注重商业理由的基础』上推广宣传开源理念。」开放源码组织积极普及和倡导开源，它是「开源」的定义者强调（Open Source Definition），并负责审批某个许可证是否符合其对「开源」的定义。 \ No newline at end of file diff --git "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\246\202\344\275\225\345\210\244\346\226\255\344\270\200\344\270\252\351\241\271\347\233\256\346\230\257\345\220\246\346\230\257\345\274\200\346\272\220\347\232\204\357\274\237.md" "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\246\202\344\275\225\345\210\244\346\226\255\344\270\200\344\270\252\351\241\271\347\233\256\346\230\257\345\220\246\346\230\257\345\274\200\346\272\220\347\232\204\357\274\237.md" index d0edfe729ff5ab4211116a0a5424ead612eaa9c2..3830f5ccf6314beb084a30160f6bde015b48eb5c 100644 --- "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\246\202\344\275\225\345\210\244\346\226\255\344\270\200\344\270\252\351\241\271\347\233\256\346\230\257\345\220\246\346\230\257\345\274\200\346\272\220\347\232\204\357\274\237.md" +++ "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\246\202\344\275\225\345\210\244\346\226\255\344\270\200\344\270\252\351\241\271\347\233\256\346\230\257\345\220\246\346\230\257\345\274\200\346\272\220\347\232\204\357\274\237.md" @@ -7,7 +7,6 @@ 关于开源许可的十个条件请看 [什么是开源](./什么是开源.md/#开源软件) 一节。 - ## 什么是闭源 (Closed Source)？ 这太好解释了：源代码不发布，就叫闭源。 @@ -53,5 +52,4 @@ - [使用了 Fair License 的软件](https://fair.io/) - [使用了 Commons Clause 的软件](https://commonsclause.com/) - [使用了 Anti-996 License 的软件](https://github.com/996icu/996.ICU/blob/master/LICENSE_CN) -- …… - +- …… \ No newline at end of file diff --git "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\274\200\346\272\220\344\270\216\344\270\252\344\272\272\346\212\200\346\234\257\346\210\220\351\225\277.md" "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\274\200\346\272\220\344\270\216\344\270\252\344\272\272\346\212\200\346\234\257\346\210\220\351\225\277.md" new file mode 100644 index 0000000000000000000000000000000000000000..b2a637dea629a0b28edfe4d9db1b20f26c6fa5c9 --- /dev/null +++ "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\274\200\346\272\220\344\270\216\344\270\252\344\272\272\346\212\200\346\234\257\346\210\220\351\225\277.md" @@ -0,0 +1,104 @@ +> 本篇内容将会阐释参与开源是怎样对个人技术成长产生影响，以及如何影响的。正如第一节所说的，开源已经成为一种超越软件生产界限的运动和工作方式。那么开源对个人有什么影响呢？在讨论这个事情之前，首先我们得先了解开源社区的概念。 + +## 开源社区 + +开源社区又称开放源代码社区，一般由拥有共同兴趣爱好的人所组成，根据相应的开源软件许可证协议公布软件源代码的网络平台，同时也为网络成员提供一个自由学习交流的空间。由于开放源码软件主要被散布在全世界的编程者所开发，开源社区就成了他们沟通交流的必要途径，因此开源社区在推动开源软件发展的过程中起着巨大的作用。 + +## 程序员素养 + +除了开源社区，我们不得不提一下程序员素养，一个优秀的程序员需要拥有什么素养呢？是不是只需要打代码就可以了？答案当然是否定的。抛开其他素养不谈，我们这里只提以下 5 点。 + +1. 扎实的专业技术、技能 +2. 架构设计能力和模块化思维能力 +3. 团队精神和协作能力 +4. 文档习惯和写作能力 +5. 需求理解能力 + +就开源社区而言，参与开源可以很好的锻炼程序员的以上 5 个素养。 + +## 前言 + +什么是开源，相信前面的章节已经说的非常清楚了。开源作为一种贡献技术的方式，对整个技术界和开源社区的正向回馈是巨大的。近 10 年来，越来越多的项目加入了开源界。其中有许许多多的知名开源项目被人所认可和追捧。 + +- 操作系统 Linux，Android； +- 编辑器 Vim，Atom，VSCode； +- 版本管理 SVN，GIT，Fossil； +- 数据库 Mysql，MongoDB，Redis； +- 大数据平台 Hadoop，ES，Hbase； +- 容器 Apache，Nginx； +- 虚拟化软件 Docker，K8S。 + +这些列出来只是冰山的一个小角而已，还有很多这种耳熟能详的开源软件，他们共同形成了一个完整的开源生态，现在已经渗透到了各行各业。可以这么说，现在你电脑上用的软件，手机里用的 App，你的吃住出行的背后，都有开源项目的支撑。没有了开源项目，这个世界根本不是现在这个样子。 + +随着开源协作这种方式越来越被这个世界所认可，有很多的公司和个人开发者也加入了开源大家庭，他们把自己的技术沉淀，解决方案做成开源项目回馈给开源社区。如今的技术界，正因为有了开源，而变得不再是闭门造车，而是呈现出一种百家争鸣，欣欣向荣的景象。 + +开源社区的每一个人都有自己的角色，一般一个大型的开源社区有以下几种角色： + +- 开源领导者 +- 开源维护提交者 +- 开源贡献者 +- 开源使用者 + +那开源的宗旨是什么，有七个理念，分别是：完全自主，高度开放，自发自治，自下而上，自由竞争，赢在声誉，社区赋能。 +> 此理念引用于《开源的 7 大理念》，由《大教堂与集市》的译者卫剑钒提出。 + +那么每个角色在开源社区内，都能有所收获，下面我们就来聊下，不同的角色会有什么样的收获。 + +## 开源领导者&开源维护提交者 + +之所以把这两个角色放一起来说，是因为有很多开源项目这两个角色是重叠的。毕竟像 Linux 那样拥有一整个开源团队的项目还是少数，很多开源项目的团队就几个人，那么领导者又同时是维护者。 + +领导者这个角色，是对于开源项目的事务有着最终话语权的，这个角色能决定开源项目的发展方向，这个角色得为现有的版本和未来的版本作规划，结合使用者的反馈来决定下一版本该上什么样的特性，这个项目最终能达到的高度和解决什么样的问题。作为这层的角色，你需要去从大局观去考虑，作为项目的领导者，能获得的提升是全方位的，从项目所处的专业领域的发展，到每个特性关联的技术方向，再到怎么在社区内进行推广，怎么持续推进项目的进度。这些实际操作的过程累计的经验，能让你在任何一个项目中都能正确分析和决策，游刃有余。 + +而作为维护提交者，是可以直接提交代码到主干的人。这个角色得了解这个项目的所有技术细节。担任核心的开发工作。如果你作为这个角色，必须要对你项目中所使用技术有较深的理解，同时还要对项目架构有一定的设计能力。成为这个角色你能获得的提升有以下几点： + +1. 对相关技术知识点的全方位掌握和系统化的思考方式。开源项目的用户是开发者，而开发者会把你的项目用于各种场景，这就和公司级项目比较单一化的场景有所不同，所以你必须考虑到更多的层面去设计你的开源项目，也必须更深的掌握相关知识点。 + +2. 自主的学习精神。做开源要面对大量不同的场景，同时也要对你选型的其他开源框架有更深入的了解，自主的学习是每一个开源人的特点。 + +3. 开放的心态，你对其他开源作品会有一个开放性的认识，能客观的了解开源的现状，社区的情况。 + +4. 敢于竞争，开源的理念有一项就是自由竞争，做开源当然是希望自己的项目成为这个赛道里靠前的项目，自然会涉及到竞争，在完全自由化的开源社区，竞争也是一种良性的循环。 + +5. 获得声誉，有更多的人来用你的项目，你自然会获得声誉，这是包装自己比较好的一种方式。 + +## 开源贡献者 + +贡献者不光是写代码，如果你参与了某个开源项目，除了可以成为 Committer 之外，你还可以帮助用户解答问题，贡献文档，在邮件列表中参与讨论。 + +成为这个角色获得的提升有这些： + +1. 通过了解代码细节获得相关知识，成功的开源项目一定是能帮助开发者解决一块领域的问题的，了解作者如何做到这点的细节会对你有帮助。 + +2. 通过贡献文档来获得写文档的能力，代码写得好不代表你文档就能写得很好，写代码反映的是你用技术解决问题的能力，而写文档反映的是你书面叙述解决方案的能力。 + +3. 交流能力，开源项目面对的用户是其他开发者，开源项目的迭代一定是要使用者参与的。正确的处理使用者的反馈，通过交流听取使用者的建议，会使开源项目处于一个正向的循环中。 + +4. 技术影响力：通过贡献代码/文档到开源项目，是非常有效的一种证明自身技术能力的方式，所以能够很直接地提升自己的技术影响力；如果你在贡献代码的同时，还擅长通过技术写作、技术演讲等形式来推广该项目，那么这种技术影响力就会被进一步放大；另外，参与知名开源项目本身就可以为贡献者带来背书和技术影响力，而且这种结局是双赢的。 + +## 开源使用者 + +这个角色作为社区成员，他们最有价值的部分是提出需求、报告缺陷、提出建议。 + +作为使用者，获得的提升有这些： + +1. 能关注到开源社区新的技术方向，使用者肯定是认可开源这种协作方式的。长期关注开源社区，能让使用者长期紧跟社区最新的技术方向，这也能让你在选型企业级系统中间件的时候有很多选择。 + +2. 通过使用开源项目，获得技术的提升。 + +3. 通过提出需求，报告缺陷让你企业级项目里的碰到的问题得到快速解决，也能促进开源项目的迭代，等于是贡献了社区。 + +## 总结 + +总的来说，个人参与开源项目对职业发展和个人成长都有很大帮助。 + +1. **更好的职业生涯** + - 职位需求增多 + - 自身技能提升 + - 行业视角扩大 + - 人际关系拓展 + - 个人品牌打造 + - 拥有离开公司生存的能力 +2. **享受乐趣** + - 成长的乐趣 + - 成就感 \ No newline at end of file diff --git "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\274\200\346\272\220\345\217\221\345\261\225\350\266\213\345\212\277.md" "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\274\200\346\272\220\345\217\221\345\261\225\350\266\213\345\212\277.md" index e2ab5544adce7fe4968a2816edb104aed219ab10..e014a36d96d6d89fb78a39b2d599d31035f99ebd 100644 --- "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\274\200\346\272\220\345\217\221\345\261\225\350\266\213\345\212\277.md" +++ "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\345\274\200\346\272\220\345\217\221\345\261\225\350\266\213\345\212\277.md" @@ -4,29 +4,29 @@ 首先，我们通过 Erin 在 [浅谈开源软件的发展（一）：开源软件简史](https://zhuanlan.zhihu.com/p/150963217) 中对开源软件简史的一段描述，理解开源软件诞生的原因，以及开源软件的核心思想。 -> ​ 上个世纪五六十年代的时候，绝大部分的软件都是由学术界和企业的研究人员合作写出来的，这些软件以公有领域软件（Public-Domain Software）的形式被分享出来，即今天我们所谓的开源软件。这些软件的分享秉持着学术界一向的公开、合作的原则，并没有被商品化。 +> ​上个世纪五六十年代的时候，绝大部分的软件都是由学术界和企业的研究人员合作写出来的，这些软件以公有领域软件（Public-Domain Software）的形式被分享出来，即今天我们所谓的开源软件。这些软件的分享秉持着学术界一向的公开、合作的原则，并没有被商品化。 正如这段话描述的一样，开源软件是为了促进技术交流和行业进步而诞生的。开源的核心精神就在于公开、合作，通过频繁的公开交流和紧密合作，为未来的发展提供更多的可能性。 ## 开源现状 -随着计算机技术的发展，尤其是互联网技术和相关企业的兴起，开源软件在操作系统、编译工具链、数据库、WEB服务器、移动操作系统等各个方面已经成 为主流。而且许多企业利用开源软件形成了独特的商业模式。比如谷歌的 Android 操作系统，从 2007 年开源发布第一个版本起，到今天已经发展到 4.1 版本，占据了智能手机操作系统一半以上的市场份额，谷歌也通过 Android 操作系统在移动互联网这一新兴行业中占据了领先和主导地位。再比如在服务器端广泛使用的关系型数据库 MySQL，在以开源软件和商业许可并行的模式下，得到了快速发展，并在 2008 年作价 10 亿美金由 Sun 收购（后者又在 2009 年被 Oracle 公司以 74 亿美金的高价收购）。相反，以前一直和开源软件做斗争的微软公司，却因为无法快速推出适应市场的 Windows Phone 操作系统，在移动互联网竞争中处于下风。为顺应潮流，微软也开始拥抱开源，比如向Samba项目贡献代码，放弃自己研发多年的大数据项目而选择 Hadoop 为其大数据的核心等。 +随着计算机技术的发展，尤其是互联网技术和相关企业的兴起，开源软件在操作系统、编译工具链、数据库、WEB 服务器、移动操作系统等各个方面已经成为主流。而且许多企业利用开源软件形成了独特的商业模式。比如谷歌的 Android 操作系统，从 2007 年开源发布第一个版本起，到今天已经发展到 4.1 版本，占据了智能手机操作系统一半以上的市场份额，谷歌也通过 Android 操作系统在移动互联网这一新兴行业中占据了领先和主导地位。再比如在服务器端广泛使用的关系型数据库 MySQL，在以开源软件和商业许可并行的模式下，得到了快速发展，并在 2008 年作价 10 亿美金由 Sun 收购（后者又在 2009 年被 Oracle 公司以 74 亿美金的高价收购）。相反，以前一直和开源软件做斗争的微软公司，却因为无法快速推出适应市场的 Windows Phone 操作系统，在移动互联网竞争中处于下风。为顺应潮流，微软也开始拥抱开源，比如向 Samba 项目贡献代码，放弃自己研发多年的大数据项目而选择 Hadoop 为其大数据的核心等。 -显然，纵观 IT 行业这些年的发展，开源软件从黑客的理想之国，已经形成了一股推进计算机及相关行业不停进步的巨大力量。很多人可能尚未意识到，我们使用的电脑中运行有开源软件，手机中运行有开源软件，家里的电视也运行有开源软件，甚至小小的数码产品（如电子相框）中也运行有开源软件，尤其是互联网服务器端软件，几乎 全部是开源软件。毫不夸张地说，开源软件已经渗透到了我们日常生活的方方面面。 +显然，纵观 IT 行业这些年的发展，开源软件从黑客的理想之国，已经形成了一股推进计算机及相关行业不停进步的巨大力量。很多人可能尚未意识到，我们使用的电脑中运行有开源软件，手机中运行有开源软件，家里的电视也运行有开源软件，甚至小小的数码产品（如电子相框）中也运行有开源软件，尤其是互联网服务器端软件，几乎全部是开源软件。毫不夸张地说，开源软件已经渗透到了我们日常生活的方方面面。 -那么，开源软件尤其是国内的开源软件及社区的现状如何， 发展面临哪些困难和问题？ +那么，开源软件尤其是国内的开源软件及社区的现状如何，发展面临哪些困难和问题？ ### 发展现状 **政策支持** -开源的发展离不开政策的支持，在鼓励“万众创新”的时代大背景下，开源的蓬勃发展显得恰如其分。2019年，华经情报网在《2018年中国开源软件行业发展现状，开源软件整体发展形势向好》文章中，对国内开源政策做了详细说明，以下是部分段落的节选。 +开源的发展离不开政策的支持，在鼓励「万众创新」的时代大背景下，开源的蓬勃发展显得恰如其分。2019 年，华经情报网在《2018年中国开源软件行业发展现状，开源软件整体发展形势向好》文章中，对国内开源政策做了详细说明，以下是部分段落的节选。 -> 2017年，我国政府对开源的认识进一步提升，对开源软件发展的政策支持力度在不断加强。《信息产业发展指南》明确提出："支持企业联合高校、科研机构等建设重点领域产学研用联盟，积极参与和组建开源社区"，"支持开源、开放的开发模式"，重点推进云操作系统等基础软件产品的研发和应用。 +> 2017 年，我国政府对开源的认识进一步提升，对开源软件发展的政策支持力度在不断加强。《信息产业发展指南》明确提出：「支持企业联合高校、科研机构等建设重点领域产学研用联盟，积极参与和组建开源社区」，「支持开源、开放的开发模式」，重点推进云操作系统等基础软件产品的研发和应用。 > -> 《软件和信息技术服务业发展规划（2016－2020年）》中提到："发挥开源社区对创新的支撑促进作用，强化开源技术成果在创新中的应用，构建有利于创新的开放式、协作化、国际化开源生态"，"支持建设创客空间、开源社区等新型众创空间"，要实施软件"铸魂"工程，重点"构筑开源开放的技术产品创新和应用生态"。这些表述充分说明，开源软件是未来我国软件和信息技术服务业的持续快速发展的重点，也是不断提升我国信息技术创新水平的一个重要基础。 +> 《软件和信息技术服务业发展规划（2016－2020年）》中提到：「发挥开源社区对创新的支撑促进作用，强化开源技术成果在创新中的应用，构建有利于创新的开放式、协作化、国际化开源生态」，「支持建设创客空间、开源社区等新型众创空间」，要实施软件「铸魂」工程，重点「构筑开源开放的技术产品创新和应用生态」。这些表述充分说明，开源软件是未来我国软件和信息技术服务业的持续快速发展的重点，也是不断提升我国信息技术创新水平的一个重要基础。 > -> 根据统计，2017年我国最大的开源代码托管平台码云的活跃用户数已经超过200万，增速超过100％。集聚的各类开源项目接近300万个，增速超过170％，企业用户数从2017年的初的403家增加到了年末的2万余家，付费月均增长达到33％。近三年托管在开源中国的我国开源软件数量呈现逐年上升趋势，截至2018年2月，开源中国共收录了9055个我国本土开源软件。 +> 根据统计，2017 年我国最大的开源代码托管平台码云的活跃用户数已经超过 200 万，增速超过 100％。集聚的各类开源项目接近 300 万个，增速超过 170％，企业用户数从 2017 年的初的 403 家增加到了年末的 2 万余家，付费月均增长达到 33％。近三年托管在开源中国的我国开源软件数量呈现逐年上升趋势，截至 2018 年 2 月，开源中国共收录了 9055 个我国本土开源软件。 **开源平台** @@ -34,7 +34,7 @@ 开源镜像站又称开源镜像仓库，是指提供开源镜像下载源的站点，又分为高效站点与企业站点，比如：清华源、阿里云镜像站等。 -开源仓库是指提供开源代码管理仓库的站点，常用的开源仓库有GitHub、GitLab、Gitee等站点。 +开源仓库是指提供开源代码管理仓库的站点，常用的开源仓库有 GitHub、GitLab、Gitee 等站点。 开源博客是指提供开源博客管理的技术分享站点，开源博客非常繁多，比如：开源中国、CSDN、博客园等站点。 @@ -64,34 +64,33 @@ 其二，开源项目获取关注度的方式有限，一个项目从孵化到使用，经历的时间往往会比较长，在从零到一的过程中，开源者大多需要经历孤军奋战、无人问津的局面，再加上工作生活上的压力，项目可能会因此戛然而止。 -其三，开源项目回报率太低，项目优秀与否，更多的是在技术上得到的认可，但物质方面却一直“歉收”，因此，项目可能因为资金问题而折戟。 +其三，开源项目回报率太低，项目优秀与否，更多的是在技术上得到的认可，但物质方面却一直「歉收」，因此，项目可能因为资金问题而折戟。 -其四，开源项目没有明确规划，开源者对项目的前瞻性不够，或者开源组织对项目的信心不足，都会导致项目的遗憾中断。比如大名鼎鼎的Dubbo就曾经一度停摆，直到2017年才重启回归。 +其四，开源项目没有明确规划，开源者对项目的前瞻性不够，或者开源组织对项目的信心不足，都会导致项目的遗憾中断。比如大名鼎鼎的 Dubbo 就曾经一度停摆，直到 2017 年才重启回归。 -但是，我们要坚信“方法总比困难多”！开源的问题用开源的方式解决。精力不足，就聚集更多人的力量，共同发展；关注度不够，在互相鼓励的同时，多参加业内活动，提高曝光度；资金困难，就想办法通过多种渠道获取资金支持；缺少规划，多去沟通发现志同道合的朋友，共同出谋划策！ +但是，我们要坚信「方法总比困难多」！开源的问题用开源的方式解决。精力不足，就聚集更多人的力量，共同发展；关注度不够，在互相鼓励的同时，多参加业内活动，提高曝光度；资金困难，就想办法通过多种渠道获取资金支持；缺少规划，多去沟通发现志同道合的朋友，共同出谋划策！ -虽然路途遥远，但要相信“行则将至”！ +虽然路途遥远，但要相信「行则将至」！ ## 开源趋势 ### 开源协议趋势 -2020年，AYALA GOLDSTEIN 通过收集开源软件信息，并对其进行分析，分析结果表明：67%的开放源代码选择了更为宽松的开源协议。这意味着开源者在创建开源项目时，会选择相对自由的方式去分享，心态上显得更加开放。下面附上原文链接： +2020 年，AYALA GOLDSTEIN 通过收集开源软件信息，并对其进行分析，分析结果表明：67% 的开放源代码选择了更为宽松的开源协议。这意味着开源者在创建开源项目时，会选择相对自由的方式去分享，心态上显得更加开放。下面附上原文链接： - [Open Source Licenses: Trends and Predictions](https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-trends-and-predictions) ### 开源生态 -2020年10月，中国信息通信研究院发布了《开源生态白皮书（2020年）》。其中指出，开源技术在目前云计算、大数据、人工智能领域发展迅猛，已经成为技术主流。随着开源规模的扩大，国内开源数量增长的同时，也覆盖了全栈技术领域，而开源企业数量也在不断增长，开源已经遍布各个行业，成为企业商业布局的重要手段。当然，随着开源数量的爆发式增长，也带来了众多挑战。开源的发展伴随着开源风险，开源基金会对开源技术提供了强有力的帮助，但仍需构建完整的开源治理体系。其中就指出了常见的开源技术中存在的许可证风险，以及安全漏洞风险。此外，白皮书中还分析了开源生态发展趋势，提出了三点发展建议，并在文末附录了风险扫描方法及实际案例。更多开源生态信息，请阅读原文进行了解。 +2020 年 10 月，中国信息通信研究院发布了《开源生态白皮书（2020年）》。其中指出，开源技术在目前云计算、大数据、人工智能领域发展迅猛，已经成为技术主流。随着开源规模的扩大，国内开源数量增长的同时，也覆盖了全栈技术领域，而开源企业数量也在不断增长，开源已经遍布各个行业，成为企业商业布局的重要手段。当然，随着开源数量的爆发式增长，也带来了众多挑战。开源的发展伴随着开源风险，开源基金会对开源技术提供了强有力的帮助，但仍需构建完整的开源治理体系。其中就指出了常见的开源技术中存在的许可证风险，以及安全漏洞风险。此外，白皮书中还分析了开源生态发展趋势，提出了三点发展建议，并在文末附录了风险扫描方法及实际案例。更多开源生态信息，请阅读原文进行了解。 > 来源：中国信息通信研究院 -### “开源+”时代 +### 「开源+」时代 -“开源+”时代是指，依托开源项目基础，组建自己的服务、业务、团队等（在开源许可认证内），减少了很多维护成本。 +「开源+」时代是指，依托开源项目基础，组建自己的服务、业务、团队等（在开源许可认证内），减少了很多维护成本。 - -- 开源+ IT 服务提供商：在每种情况下，都应对软件需求进行单独评估–使用开源软件有很多充分的理由。使用闭源软件时可能产生的优势，例如通常仅适用于专有软件的进一步开发或支持，可以通过与有能力的 IT 服务提供商合作，为开源带来巨大优势。拥有合适的软件和出色的 IT 资源的公司处于创造最佳数字未来的理想位置。 IT 服务提供商或内部 IT 团队可以接管各个定制，开发和支持，而不仅限于一种软件。在选择 IT 合作伙伴时，建议不仅要注意技术能力，还要考虑项目管理和实施的方法，变更管理质量以及 IT 服务提供商的文化和思维方式。 +- 开源+ IT 服务提供商：在每种情况下，都应对软件需求进行单独评估–使用开源软件有很多充分的理由。使用闭源软件时可能产生的优势，例如通常仅适用于专有软件的进一步开发或支持，可以通过与有能力的 IT 服务提供商合作，为开源带来巨大优势。拥有合适的软件和出色的 IT 资源的公司处于创造最佳数字未来的理想位置。IT 服务提供商或内部 IT 团队可以接管各个定制，开发和支持，而不仅限于一种软件。在选择 IT 合作伙伴时，建议不仅要注意技术能力，还要考虑项目管理和实施的方法，变更管理质量以及 IT 服务提供商的文化和思维方式。 开源软件代表了一种新的技术产生方式。顶尖的高校研究成果很多都是以开源形式发布的，顶尖公司（如谷歌）的技术架构中，每套系统基本都有其对应的开源项目。 @@ -101,13 +100,13 @@ ## 开源与商业化 -如果你已经了解了各种开源协议，相信你已经成功摆脱了“开源=免费”的错误理解。就像“开源=免费”这类常见误区一样，大家可能会想当然地认为开源与商业化毫无关系，或者认为开源与商业化是互斥的。用一个不知是否恰当的比喻：当今的开源盛世，像极了14世纪到16世纪的文艺复兴。而随着知识付费时代的到来，对于开源发展而言，此时推动开源的商业化是最好时间节点。开源的商业化探索，不仅是对开源贡献者的回馈，更是促进开源社区发展的“强心剂”！ +如果你已经了解了各种开源协议，相信你已经成功摆脱了「开源=免费」的错误理解。就像「开源=免费」这类常见误区一样，大家可能会想当然地认为开源与商业化毫无关系，或者认为开源与商业化是互斥的。用一个不知是否恰当的比喻：当今的开源盛世，像极了 14 世纪到 16 世纪的文艺复兴。而随着知识付费时代的到来，对于开源发展而言，此时推动开源的商业化是最好时间节点。开源的商业化探索，不仅是对开源贡献者的回馈，更是促进开源社区发展的「强心剂」！ ### 开源软件与商业软件的对比 -《易传·系辞上传》有云：“易有太极，是生两仪”。开源软件与商用软件的关系就像太极一样，两者并非互相对立、互相矛盾的，而是互相促进、相辅相成的。在这短短几十年中，开源与商用彼此交织，通过制定完善的规定与制度，共同推动着行业发展。 +《易传·系辞上传》有云：「易有太极，是生两仪」。开源软件与商用软件的关系就像太极一样，两者并非互相对立、互相矛盾的，而是互相促进、相辅相成的。在这短短几十年中，开源与商用彼此交织，通过制定完善的规定与制度，共同推动着行业发展。 -随着开源社区的发展，开源软件已经不再是商用软件的简单模仿，而是开始在行业内发出更大的声音，引领着行业发展的方向。从商业角度看，很多开源软件像是商用软件的模仿，例如：从最早的Linux（模仿各类商用 Unix）、Eclipse（模仿 Ⅴisual Studio）、Apache Hadoop（模仿谷歌三篇经典论文成果），到这几年耳熟能详的：Xen/KVM（模仿 VMWare）、OpenStack（模仿 Amazon AWS）等。而在容器技术方面，没有任何一家公司拥有最前沿的技术，也没有公司率先在容器技术上获得足够的回报，所有公司都在一个起跑线上。这也是为什么，在容器技术兴起的 2014 年，开源技术可以不断牵引着整个行业的发展方向。 +随着开源社区的发展，开源软件已经不再是商用软件的简单模仿，而是开始在行业内发出更大的声音，引领着行业发展的方向。从商业角度看，很多开源软件像是商用软件的模仿，例如：从最早的 Linux（模仿各类商用 Unix）、Eclipse（模仿 Ⅴisual Studio）、Apache Hadoop（模仿谷歌三篇经典论文成果），到这几年耳熟能详的：Xen/KVM（模仿 VMWare）、OpenStack（模仿 Amazon AWS）等。而在容器技术方面，没有任何一家公司拥有最前沿的技术，也没有公司率先在容器技术上获得足够的回报，所有公司都在一个起跑线上。这也是为什么，在容器技术兴起的 2014 年，开源技术可以不断牵引着整个行业的发展方向。 而对于商用软件而言，也并非从此不再有用武之地。开源软件的发展较为自由，主要依靠开源贡献者推动，未来发展存在不可确定性，且很难做到商用软件的服务与支持。而商用软件的标准化产品、优质长久的技术服务，使得它仍然是一个非常可靠的选择，依旧可以巍然屹立在行业内。 @@ -121,65 +120,63 @@ **开源软件的优缺点描述** -| | 开源软件 | 描述 | -|---|---|---| -| 优点 | 成本 | 开源最重要的优势是成本。在软件上节省下的开支可以让企业在其他地方进行投资，比如建设更快的网络或更快的存储阵列，又或者向员工支付更高的工资。 | -| | 灵活 | 开源软件灵活性体现在能够定制和修改源代码 | -| | 无要求 | 避免繁琐头疼的许可或激活要求是开源软件另一项值得注意的好处, 它可以让公司从一些潜在的风险中解放出来，比如违反了专有软件使用的授权。 | -| | 自由 | 最后，自由是开源的优势。商业软件可能会纠缠不清，也会使企业依赖供应商，被动接受不需要的功能。此外，一个供应商的退出可能会对使用该专有软件的企业产生负面影响，但是开源软件通常会持续很长时间，因为有一个开发者社区。 | -| 缺点 | 支持差 | 开源软件最大的一个缺点是支持服务不到位 (除了付费支持订阅), 你懂得! | -| | 文档弱 | 很多开源产品缺乏良好的文档记录，或者说就根本就没有文档记录。在许多情况下，你会发现文档已经过时了无用了 | -| | 复杂性 | 开源软件或许很强大，但也很难学习和管理。当出现问题时，试图解决问题是一个挑战，特别是在缺乏支持的情况下。 | -| | 更容易发现漏洞 | 最后，因为开源，任何人都可以看到源代码，这可能会变成一个缺点。如果代码包含了可以被利用的漏洞，恶意者可能会利用这些漏洞。如果没有专门的供应商来发布更新，修补程序可能会比较慢。 | +| | 开源软件 | 描述 | +| --- | --- | --- | +| 优点 | 成本 | 开源最重要的优势是成本。在软件上节省下的开支可以让企业在其他地方进行投资，比如建设更快的网络或更快的存储阵列，又或者向员工支付更高的工资。 | +| | 灵活 | 开源软件灵活性体现在能够定制和修改源代码 | +| | 无要求 | 避免繁琐头疼的许可或激活要求是开源软件另一项值得注意的好处, 它可以让公司从一些潜在的风险中解放出来，比如违反了专有软件使用的授权。 | +| | 自由 | 最后，自由是开源的优势。商业软件可能会纠缠不清，也会使企业依赖供应商，被动接受不需要的功能。此外，一个供应商的退出可能会对使用该专有软件的企业产生负面影响，但是开源软件通常会持续很长时间，因为有一个开发者社区。 | +| 缺点 | 支持差 | 开源软件最大的一个缺点是支持服务不到位 (除了付费支持订阅), 你懂得! | +| | 文档弱 | 很多开源产品缺乏良好的文档记录，或者说就根本就没有文档记录。在许多情况下，你会发现文档已经过时了无用了 | +| | 复杂性 | 开源软件或许很强大，但也很难学习和管理。当出现问题时，试图解决问题是一个挑战，特别是在缺乏支持的情况下。 | +| | 更容易发现漏洞 | 最后，因为开源，任何人都可以看到源代码，这可能会变成一个缺点。如果代码包含了可以被利用的漏洞，恶意者可能会利用这些漏洞。如果没有专门的供应商来发布更新，修补程序可能会比较慢。 | **商用软件的优缺点描述** - -| | 商用软件 | 描述 | -|---|---|---| -|优点 |单一供应商|通常商业软件包括“一站式购物”体验，即单个供应商可以提供你所需的所有应用程序和工具。微软就是一个很好的例子，它销售操作系统、数据库、办公软件等各种应用软件、还有开发工具等等。相比之下，开源软件却比较零碎。| +| | 商用软件 | 描述 | +| --- | --- | --- | +| 优点 | 单一供应商 | 通常商业软件包括「一站式购物」体验，即单个供应商可以提供你所需的所有应用程序和工具。微软就是一个很好的例子，它销售操作系统、数据库、办公软件等各种应用软件、还有开发工具等等。相比之下，开源软件却比较零碎。| | | 企业级产品|商业软件通常是为具有大量特性的大型企业量身定做的。供应商很清楚行业标准和标准公司的需求，并将这些概念包含在他们的编程中，这可以帮助公司保持竞争力。 | -| |专业的接口 |商业软件提供了一个更好的、更标准的接口，它通常适合大多数用户的需求。 | -| |日常更新 |商业软件经常更新，不仅是修补漏洞，也是为了从客户那里获得更多的钱来进行付费升级。 | -| |不需要编程 | 你的企业可能不需要自定义或向软件添加代码，因此开放源码的特殊诱惑对你的业务来说是微不足道的，而商业软件是开箱即用。| -| |集成 |许多商业软件与其他应用程序集成，以便更好地使用和方便。例如，微软的 Lync 即时消息客户端与 Microsoft Outlook 集成，因此在查看电子邮件时，可以看到人们的可用性状态，以及即时消息会话被保存到 Outlook 中。 | -|缺点 |产品臃肿 |商业软件可能包含大量臃肿和不必要的组件或功能。虽然你可以只安装需要的组件，但是对于选项，大部分人其实并不清楚这些组件的作用，只能选择盲目地选择全部安装。 | -| |额外的费用 |除了成本问题，有时候还会包含一些让你意外的额外费用。如月度或年度费用，更新费用的上涨，或其他隐藏的因素。 | -| |供应商锁定 | “一站式购物”导致，你的企业最终可能会过度依赖于供应商，被锁定在一个封闭的系统中。| -| |替换很难 | 害怕浪费钱迫使企业会继续使用那些可能无法完全满足他们利益的产品。切换到竞争或替代软件的困难包括担心必须从头再来，更换一个软件，再培训人员等其他原因。| +| | 专业的接口 | 商业软件提供了一个更好的、更标准的接口，它通常适合大多数用户的需求。 | +| | 日常更新 | 商业软件经常更新，不仅是修补漏洞，也是为了从客户那里获得更多的钱来进行付费升级。 | +| | 不需要编程 | 你的企业可能不需要自定义或向软件添加代码，因此开放源码的特殊诱惑对你的业务来说是微不足道的，而商业软件是开箱即用。| +| | 集成 | 许多商业软件与其他应用程序集成，以便更好地使用和方便。例如，微软的 Lync 即时消息客户端与 Microsoft Outlook 集成，因此在查看电子邮件时，可以看到人们的可用性状态，以及即时消息会话被保存到 Outlook 中。 | +| 缺点 | 产品臃肿 | 商业软件可能包含大量臃肿和不必要的组件或功能。虽然你可以只安装需要的组件，但是对于选项，大部分人其实并不清楚这些组件的作用，只能选择盲目地选择全部安装。 | +| | 额外的费用 | 除了成本问题，有时候还会包含一些让你意外的额外费用。如月度或年度费用，更新费用的上涨，或其他隐藏的因素。 | +| | 供应商锁定 | 「一站式购物」导致，你的企业最终可能会过度依赖于供应商，被锁定在一个封闭的系统中。| +| | 替换很难 | 害怕浪费钱迫使企业会继续使用那些可能无法完全满足他们利益的产品。切换到竞争或替代软件的困难包括担心必须从头再来，更换一个软件，再培训人员等其他原因。| > 参考 [各有利弊，开源和商业软件应该怎么选？](https://blog.csdn.net/belalds/article/details/88026244) ### 开源的商业化 -回首看开源发展的这些年，提供给我们研究的开源项目成功的案例有很多。众多优秀开源项目：GNU/Linux、MySQL、Red Hat、Ubuntu、Apache、OpenJDK、Firefox、Spring 等。现如今，随着开源社区的不断发展，各大企业纷纷拥抱开源，利用开源进行商业布局。因此，我们有充分的理由可以认为“开源是可以进行商业化的”。 +回首看开源发展的这些年，提供给我们研究的开源项目成功的案例有很多。众多优秀开源项目：GNU/Linux、MySQL、Red Hat、Ubuntu、Apache、OpenJDK、Firefox、Spring 等。现如今，随着开源社区的不断发展，各大企业纷纷拥抱开源，利用开源进行商业布局。因此，我们有充分的理由可以认为「开源是可以进行商业化的」。 那么如何进行商业化呢？这个问题并没有一份标注答案，每个成功的开源项目都有着不同的商业化轨迹，但或许能够从它们的共性上找到答案。首先，需要考虑项目是否已经具备商业化的价值，如果项目不够成熟，无法承受住市场的检验，必定是无法商业化的。其次，需要对项目商业化模式有清晰的认识，不同的商业模式有不同的商业化属性。最后，需要做好项目的维护工作，保持团队和社区的活跃，对使用者而言，更能相信该项目是一个稳定的开源项目。 **重大的并购案例** - 1999年 Red Hat 收购 Cygnus Solutions（6.75 亿美元） -- 2003年 Novell 收购SUSE（2.1亿美元） +- 2003年 Novell 收购 SUSE（2.1 亿美元） - 2005年 Oracle 收购 InnoDB - 2006年 Oracle 收购 SleeepyCat -- 2006年 Red Hat 收购 JBoss（3.5亿美元） +- 2006年 Red Hat 收购 JBoss（3.5 亿美元） - 2007年 Apple 收购 CUPS - 2007年 Sourcefire 收购 ClamAV - 2007年 Citrix 收购 XenSource（5 亿美元） - 2008年 Sun 收购 MySQL（10 亿美元） - 2008年 SpringSource 收购 Covalent Technologies -- 2009年 Oracle 收购 Sun（74亿美元） +- 2009年 Oracle 收购 Sun（74 亿美元） - 2009年 VMware 收购 Spring Source（4.2 亿美元） -- 2019年 IBM 收购 Red Hat（340亿美元） +- 2019年 IBM 收购 Red Hat（340 亿美元） - 2020年 Microsoft 收购 GitHub（75 亿美元） ## 小结 -本文讲述了开源的背景，分析目前开源发展的现状以及遇到的困难与问题，通过开源协议、开源生态、“开源+”时代三个小节说明了目前开源发展的趋势，列举了开源软件与商业软件的优势与弊端，借助开源商业化的成功案例，讨论和探索开源商业化的方法。希望通过本篇文章，能够让大家对开源发展趋势有一定的了解和认知，为开源发展做出自己的贡献！ +本文讲述了开源的背景，分析目前开源发展的现状以及遇到的困难与问题，通过开源协议、开源生态、「开源+」时代三个小节说明了目前开源发展的趋势，列举了开源软件与商业软件的优势与弊端，借助开源商业化的成功案例，讨论和探索开源商业化的方法。希望通过本篇文章，能够让大家对开源发展趋势有一定的了解和认知，为开源发展做出自己的贡献！ ## 参考资料 - [浅谈开源软件的发展（一）：开源软件简史](https://zhuanlan.zhihu.com/p/150963217) - [开源软件及国内发展现状](https://www.oschina.net/news/33260/china-opensource-status) -- [2018年中国开源软件行业发展现状，开源软件整体发展形势向好](https://baijiahao.baidu.com/s?id=1628416889848858043&wfr=spider&for=pc) - +- [2018年中国开源软件行业发展现状，开源软件整体发展形势向好](https://baijiahao.baidu.com/s?id=1628416889848858043&wfr=spider&for=pc) \ No newline at end of file diff --git "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 1 \345\260\217\350\212\202\357\274\232\344\273\200\344\271\210\346\230\257\345\274\200\346\272\220.md" "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 1 \345\260\217\350\212\202\357\274\232\344\273\200\344\271\210\346\230\257\345\274\200\346\272\220.md" index 871c9d3f12a306e7b6b48c80591deaf51929f4c3..e0c8177d62a1b9effc082415cbfd57922434272f 100644 --- "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 1 \345\260\217\350\212\202\357\274\232\344\273\200\344\271\210\346\230\257\345\274\200\346\272\220.md" +++ "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 1 \345\260\217\350\212\202\357\274\232\344\273\200\344\271\210\346\230\257\345\274\200\346\272\220.md" @@ -12,22 +12,22 @@ 实际上并不是。按照 [OSI 组织](https://opensource.org/associations)（Open Source Initiative Association）的 [OSD 定义](https://opensource.org/docs/definition.php)，除了公开源代码，开源软件的发行条款还必须符合以下十个条件： -| 序号 | 条款 | 简单说明 | -| ---- | -------------------------------------------- | -------------------------------- | -| 1 | Free Redistribution | 允许自由地再发布软件 | -| 2 | Source Code | 程序必须包含所有源代码 | -| 3 | Derived Works | 可以修改和派生新的软件 | -| 4 | Integrity of The Author's Source Code | 发布时保持软件源代码的完整性 | -| 5 | No Discrimination Against Persons or Groups | 不得歧视任何个人或团体 | -| 6 | No Discrimination Against Fields of Endeavor | 不得歧视任何应用领域（例如商业） | -| 7 | Distribution of License | 许可证的发布具有延续性 | -| 8 | License Must Not Be Specific to a Product | 许可证不能针对于某一个产品 | -| 9 | License Must Not Restrict Other Software | 许可证不能限制其他软件 | -| 10 | License Must Be Technology-Neutral | 许可证必须是技术中立的 | - -你可以通过查阅OSI官方许可证的目录 [Open Source Initiative 认可的开源许可证](https://opensource.org/licenses) ，了解常见的开源许可证。 - -通过了解这些条件约束，我们可以得出开源软件的定义：开源软件是一种**技术和立场中立**的**使用许可证约束**的**开放源代码**的软件。 +| 序号 | 条款 | 简单说明 | +| --- | --- | --- | +| 1 | Free Redistribution | 允许自由地再发布软件 | +| 2 | Source Code | 程序必须包含所有源代码 | +| 3 | Derived Works | 可以修改和派生新的软件 | +| 4 | Integrity of The Author's Source Code | 发布时保持软件源代码的完整性 | +| 5 | No Discrimination Against Persons or Groups | 不得歧视任何个人或团体 | +| 6 | No Discrimination Against Fields of Endeavor | 不得歧视任何应用领域（例如商业） | +| 7 | Distribution of License | 许可证的发布具有延续性 | +| 8 | License Must Not Be Specific to a Product | 许可证不能针对于某一个产品 | +| 9 | License Must Not Restrict Other Software | 许可证不能限制其他软件 | +| 10 | License Must Be Technology-Neutral | 许可证必须是技术中立的 | + +你可以通过查阅 OSI 官方许可证的目录 [Open Source Initiative 认可的开源许可证](https://opensource.org/licenses) ，了解常见的开源许可证。 + +通过了解这些条件约束，我们可以得出开源软件的定义：开源软件是一种 **技术和立场中立** 的 **使用许可证约束** 的 **开放源代码** 的软件。 开源软件需要保持开放的心态，对任何技术和立场都保持客观公正的态度，而且在开放源代码时，还需要遵循开源许可协议，允许任何人使用、拷贝、修改以及重新发布。开源许可协议主要分为宽松许可协议（Apache、BSD、MIT 等）和严格许可协议（GPL、GPL v3、LGPL、Mozilla 等）两大类。除此之外，一个优秀的可持续发展的开源软件，还需要公开发布项目技术文档和其他材料、二进制文件（可选）等，以及拥有一个开放性的社区，接收用户和开发者的反馈，共同探讨开源软件的发展。 @@ -35,17 +35,17 @@ 上面我们简单介绍了一下开源软件，那么什么是开源硬件呢？ -类比开源软件，你可能会误以为开源硬件是可以免费获得、自由修改并再分发的硬件。如果你这么想，你就大错特错了，毕竟硬件是有形的，是看得见摸得着的。我们先来简单看一下[开源硬件协会](https://www.oshwa.org)（Open Source Hardware Association）对开源硬件的描述： +类比开源软件，你可能会误以为开源硬件是可以免费获得、自由修改并再分发的硬件。如果你这么想，你就大错特错了，毕竟硬件是有形的，是看得见摸得着的。我们先来简单看一下 [开源硬件协会](https://www.oshwa.org)（Open Source Hardware Association）对开源硬件的描述： > 开源硬件是可以通过公开渠道获得的硬件设计，任何人可以对已有的设计进行学习，修改，发布，制作和销售。硬件设计的源代码的特定的格式可以为其他人获得，以方便对其进行修改。理想情况下，开源硬件使用随处可得的电子元件和材料，标准的过程，开放的基础架构，无限制的内容和开源的设计工具，以最大化个人利用硬件的便利性。开源硬件提供人们在控制他们的技术自由的同时共享知识并鼓励硬件设计开放交流贸易。 -这里要划重点了，OSHWA 在描述开源硬件时使用的是**硬件设计**而不是硬件本身。开源硬件的定义是在开源软件的基础上进行的，这里不再赘述，感兴趣的读者可以在 OSHWA 官网找到开源硬件的完整[定义](https://www.oshwa.org/definition/)。 +这里要划重点了，OSHWA 在描述开源硬件时使用的是 **硬件设计** 而不是硬件本身。开源硬件的定义是在开源软件的基础上进行的，这里不再赘述，感兴趣的读者可以在 OSHWA 官网找到开源硬件的完整 [定义](https://www.oshwa.org/definition/)。 目前比较有名的开源硬件有 [Arduino](https://www.arduino.cc/)、[树莓派（Raspberry Pi）](https://www.raspberrypi.org/)、[BeagleBone](https://beagleboard.org/bone) 等等。 ### 开源设计 -开源设计是开源项目的另一表现形式，开源设计的定义是**遵循开源许可**的**可以通过公开渠道获得**的**设计类**项目，主要指的是非源代码类型的项目，比如： icon、UI、画稿、图纸等。这些项目也需要遵守开源协议，并且享受协议规章的保护。 +开源设计是开源项目的另一表现形式，开源设计的定义是 **遵循开源许可** 的 **可以通过公开渠道获得** 的 **设计类** 项目，主要指的是非源代码类型的项目，比如：icon、UI、画稿、图纸等。这些项目也需要遵守开源协议，并且享受协议规章的保护。 下面提供一个 icon 的设计，供大家参考。 @@ -53,7 +53,7 @@ ### 开源文档 -开源文档在开源项目中非常常见，开源文档的定义是**遵循开源许可**的**可以通过公开渠道获得**的**文档类**项目，开源文档存在于各种项目中，种类覆盖广泛，像博客、百科、菜谱、冷知识、项目说明文档等都可以作为开源文档进行分享。开源文档常见的开源协议也有很多，比如我们《开源指北》使用的协议：CC-BY-NC-SA 协议。 +开源文档在开源项目中非常常见，开源文档的定义是 **遵循开源许可** 的 **可以通过公开渠道获得** 的 **文档类** 项目，开源文档存在于各种项目中，种类覆盖广泛，像博客、百科、菜谱、冷知识、项目说明文档等都可以作为开源文档进行分享。开源文档常见的开源协议也有很多，比如我们《开源指北》使用的协议：CC-BY-NC-SA 协议。 ## 开源的历史 @@ -65,7 +65,7 @@ ![输入图片说明](https://images.gitee.com/uploads/images/2020/1106/223608_99ebf50e_1998139.jpeg "unix_1969.jpeg") -> 图1.1 Ken Thompson（坐着）和 Dennis Ritchie 在 PDP-11 前工作 +> 图 1.1 Ken Thompson（坐着）和 Dennis Ritchie 在 PDP-11 前工作 回到贝尔实验室后，以肯•汤普森为首的研究人员吸取了 Multics 项目失败的经验教训，将 Multics 庞大而复杂的系统进行简化，实现了一种分时操作系统的雏形，并将其取名为 UNIX。此后十年，UNIX 在学术机构和大型企业中得到了广泛的应用，当时的 UNIX 拥有者 AT&T 公司以低廉甚至免费的许可将 UNIX 源码授权给学术机构做研究或教学之用，许多机构在此源码基础上加以扩充和改进。 @@ -75,11 +75,11 @@ ### GNU -实际上，在 UNIX 变成一个商业项目之前，由于硬件价格的不断下跌，制造商已经开始期望软件能够带来额外的收入。于是，开始出现种种保护软件、对其收费的措施，越来越多的厂商开始单独销售软件，也不再提供软件的源代码，软件工业开始独立出来了。1976 年，比尔·盖茨就曾发表《[致计算机爱好者的公开信](https://en.wikisource.org/wiki/Open_Letter_to_Hobbyists)》，明确提出了软件版权（CopyRight）的理念。 +实际上，在 UNIX 变成一个商业项目之前，由于硬件价格的不断下跌，制造商已经开始期望软件能够带来额外的收入。于是，开始出现种种保护软件、对其收费的措施，越来越多的厂商开始单独销售软件，也不再提供软件的源代码，软件工业开始独立出来了。1976 年，比尔·盖茨就曾发表 [《致计算机爱好者的公开信》](https://en.wikisource.org/wiki/Open_Letter_to_Hobbyists)，明确提出了软件版权（CopyRight）的理念。 ![输入图片说明](https://images.gitee.com/uploads/images/2020/1106/223852_ccf37eaa_1998139.jpeg "GNU_and_Stallman_2012.jpeg") -> 图1.2 Richard Stallman +> 图 1.2 Richard Stallman 1983 年，由于私有软件的增长和对不再能自由使用计算机程序的担忧，MIT 的理查德•斯托曼（Richard Stallman）开始倡导自由软件运动，并发起了 GNU 计划。GNU 是「GNU is NOT UNIX」的无穷递归缩写，其目标是构建一整套完全由自由软件构成的 UNIX OS 体系。GNU 起初进展很顺利，开发出 GLibc、GCC、GDB 等一系列操作系统必备软件。 @@ -87,28 +87,25 @@ ### Linux -1991年，林纳斯·托瓦兹（Linus Torvalds）公开发布了一个类 UNIX 操作系统内核 —— Linux，并接受 CopyLeft 理念。从 Linux 0.12 版本起，Linux 内核开始采用 GPL 许可证的新版权声明。虽然 Linux 内核并不是 GNU 计划的一部分，但由于 HURD 内核进展缓慢，使得 Linux 得到广泛关注并得以快速发展。GNU 与 Linux 的发展，可以说是相辅相成，因此 我们通常把使用 Linux 内核并且大量使用 GNU 组件的操作系统发行版称为 GNU/Linux。 +1991 年，林纳斯·托瓦兹（Linus Torvalds）公开发布了一个类 UNIX 操作系统内核 —— Linux，并接受 CopyLeft 理念。从 Linux 0.12 版本起，Linux 内核开始采用 GPL 许可证的新版权声明。虽然 Linux 内核并不是 GNU 计划的一部分，但由于 HURD 内核进展缓慢，使得 Linux 得到广泛关注并得以快速发展。GNU 与 Linux 的发展，可以说是相辅相成，因此 我们通常把使用 Linux 内核并且大量使用 GNU 组件的操作系统发行版称为 GNU/Linux。 ![输入图片说明](https://images.gitee.com/uploads/images/2020/1106/223937_2408e51a_1998139.jpeg "Linus.jpg") -> 图1.3 Linus Torvalds +> 图 1.3 Linus Torvalds 正是 Linux 的出现，使得自由软件运动有了自己可以与 Microsoft 的 Windows 相抗衡的操作系统。自由软件运动初战告捷。但是，自由软件运动关于自由的追求，毕竟和现实的商业氛围格格不入，带有着过于理想化的色彩。这种反商业的信条，让一些本来也反对私有软件的人士对自由软件敬而远之。正是在这种背景下，一部分原有自由软件运动人士，开始尝试将理想的自由软件与现实的商业氛围进行某种衔接。 ### 自由软件和开源软件 - 1998 年，埃里克·雷蒙德（Eric Raymond）等人成立了一个名为开源促进会（Open Source Initiative，简称 OSI）的组织。为了减少意识形态上的沟壑，以及「自由（Free）」一词造成免费软件的误解。OSI 组织决定从「自由软件」中去掉了「自由」一词，使用「开源软件」（Open Source Software）作为共通名称，并创建了自己的开放源码的定义，以及自己的一套许可证。 - ![输入图片说明](https://images.gitee.com/uploads/images/2020/1106/224104_42883a6d_1998139.jpeg "1998_Open_Source_Summit.jpg") -> 图1.4 1998 年 Open Source Summit +> 图 1.4 1998 年 Open Source Summit 正因如此，自由软件运动和开源软件运动有着密不可分的关系，两者的根本差别在于它们看待世界的方法。开源软件运动的理念更倾向于解决实际问题，既抓住了私有软件的痛点，又实现了与商业的融合。 - -### 开源、Git和代码托管平台 +### 开源、Git 和代码托管平台 前面提到，开源软件是允许自由复制和重新分发的，那么分散的开发者之间是如何协作的呢？尤其是 Linux 这样依靠全世界热心的志愿者参与的项目。其实早年（1991-2002 年间）世界各地的志愿者是通过 diff 的方式把源代码补丁发给 Linus，然后由 Linus 本人通过手工方式合并代码。直到 2002 年，Linux 项目组才开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。 @@ -116,7 +113,7 @@ ![输入图片说明](https://images.gitee.com/uploads/images/2020/1106/224307_aeb3bb91_1998139.jpeg "h320px_github_founders.jpg") -> 图1.5 GitHub 创始人 P.J. Hyett、Tom Preston-Werner 和 Chris Wanstrath +> 图 1.5 GitHub 创始人 P.J. Hyett、Tom Preston-Werner 和 Chris Wanstrath 2008 年，GitHub 网站上线了，它为开源项目免费提供 Git 存储，无数开源项目开始迁移至 GitHub。GitHub 的出现让开源的工作方式变得更简单和有趣了。如今，每天都有无数来自世界各地的开发者在 GitHub 上进行交流，Github 已经成为一个包含问题追踪和版本控制的特殊社交网络。 @@ -136,7 +133,6 @@ 开源与我们息息相关，即便你不写代码，我们也期望大家能够参与开源（**强烈建议**）！愿你在开源领域乘风破浪，所向无前！ - ## 参考资料 - [The Open Source Definition](https://opensource.org/osd) diff --git "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" index 12df087057fbac2b27f4e645a8cc0792f017d785..9fdd2128a7164d1e7dc714dd763a9e671b56709c 100644 --- "a/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" +++ "b/\347\254\2541\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" @@ -1,36 +1,31 @@ # 第 5 小节：有关开源的常见误区 - ``` -本章需补充更多与“开源误区”相关的内容 +本章需补充更多与「开源误区」相关的内容 ``` - > 本篇内容将会为开发者们解释一些有关开源的误区，以下方两个问题为例，欢迎开发者们补充更多内容 ### 开源就意味着完全免费和随意使用吗？ +在使用开源软件时，您需要 **严格遵守** 项目的开源协议。 -在使用开源软件时，您需要**严格遵守**项目的开源协议。 - -GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码，但是**不允许**修改版权信息。 +GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码，但是 **不允许** 修改版权信息。 而部分开源协议则对于商业应用需要购买并支付费用。 还有部分开源协议表明不能将软件用作任何政治相关的用途，特别是政治宣传。 -所以开源**并不意味着**完全免费和随意使用源代码！ +所以开源 **并不意味着** 完全免费和随意使用源代码！ ### 开源就意味着作者没有版权吗？ - **开源项目采用开源许可并不意味作者没有版权/著作权。** 开源项目的源代码版权是归原作者所有，使用者在使用时需要遵守开源软件根目录下的 **LICENSE** 相关规定，如果没有放置 **LICENSE** 则代表保留所有权利。 ### 开源过程中不能转为闭源？ - 认识开源首先的一点是要认识各种开源许可证，不同开源许可对待开源转闭源有不同的规定： * LGPL、GPL、Mozilla 许可（MPL）这类许可证禁止开源软件转为闭源软件。 @@ -39,10 +34,9 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码， > 参考：[如何选择开源许可证？](http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html) -### “半开源”和“伪开源”也是开源吗？ +### 「半开源」和「伪开源」也是开源吗？ -开源不只是开放源代码，根据 OSI 的定义，开源必须满足一系列条款。 -半开源和伪开源都违反了开源的其中某些条款，因此不是开源。 +开源不只是开放源代码，根据 OSI 的定义，开源必须满足一系列条款。半开源和伪开源都违反了开源的其中某些条款，因此不是开源。 ### 只开放源代码算开源项目么？ @@ -50,8 +44,7 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码， ### 开源项目必须用英文命名标识符吗？ - -虽然很多开发者早已知道多数常用编程语言支持中文命名标识符并付诸实践，但仍然常见“如果项目开源的话还是要用英文命名”的说法。2007 年 Python3 决定支持非 ASCII 码标识符的[增强建议书](https://www.python.org/dev/peps/pep-3131/)中指出： +虽然很多开发者早已知道多数常用编程语言支持中文命名标识符并付诸实践，但仍然常见「如果项目开源的话还是要用英文命名」的说法。2007 年 Python3 决定支持非 ASCII 码标识符的 [增强建议书](https://www.python.org/dev/peps/pep-3131/) 中指出： > A developer wishing to make a library widely available needs to make a number of explicit choices (such as publication, licensing, language of documentation, and language of identifiers). It should always be the choice of the author to make these decisions - not the choice of the language designers. > @@ -71,7 +64,7 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码， - 框架限制必须用英文怎么办？ - 比如 JavaBeans 规范通常要求使用 set/get 前缀。即便如此，仍然可以使用中英混合的命名，只要开发者感觉更易读即可，比如 `getCostOutcomeRatioByClientGroup` 相比 `get投入产出比By客户组`。类似地，一些常用的英文术语或简写，如果没想到合适中文对应术语，大可以暂时保留这部分英文命名。 + 比如 JavaBeans 规范通常要求使用 set/get 前缀。即便如此，仍然可以使用中英混合的命名，只要开发者感觉更易读即可，比如 `getCostOutcomeRatioByClientGroup` 相比 `get 投入产出比 By 客户组`。类似地，一些常用的英文术语或简写，如果没想到合适中文对应术语，大可以暂时保留这部分英文命名。 - 中英文混输的效率会低吗？ @@ -89,18 +82,17 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码， 如果需要面向国外用户，首先要对用户界面和使用文档进行国际化。如果是库，用户界面就是 API。技术上，可以开发中英两套 API。如果想更进一步，鼓励国外开发者参与开发项目，当然可以逐步将命名英文化，但也应综合考虑是否值得。 -总之，澄清这个误区的目的，绝不是排斥英文命名，而是让更多开源作者意识到可以视项目性质和自身情况因地制宜、具体情况具体分析，灵活选择何时、何处进行中文命名实践，也希望中文开源社区能以开放宽容的心态看待中文命名标识符这一并不新的“新技术”。 +总之，澄清这个误区的目的，绝不是排斥英文命名，而是让更多开源作者意识到可以视项目性质和自身情况因地制宜、具体情况具体分析，灵活选择何时、何处进行中文命名实践，也希望中文开源社区能以开放宽容的心态看待中文命名标识符这一并不新的「新技术」。 ### 开源不够安全？ -* 第一种误解也引发了另一种说法，即开源中“古老而优秀”的部分并不安全。首先，我们来看一下封闭式平台或专有平台是怎么运作安全补丁的：安全漏洞必须由有权访问源代码的人员识别（通常只是供应商），这首先就要耗费大量时间。随后，他们必须对修复补丁进行编码、测试并交付使用，这就再次延迟了修复时间。 +* 第一种误解也引发了另一种说法，即开源中「古老而优秀」的部分并不安全。首先，我们来看一下封闭式平台或专有平台是怎么运作安全补丁的：安全漏洞必须由有权访问源代码的人员识别（通常只是供应商），这首先就要耗费大量时间。随后，他们必须对修复补丁进行编码、测试并交付使用，这就再次延迟了修复时间。 -* 相反，再看看基于标准且开放的开发模式：它有助于快速识别潜在的安全漏洞。举个栗子，在 2014 年，常用的 OpenSSL 加密软件库发现了 Heartbleed。已经订阅红帽软件的客户都在第一时间收到了红帽安全响应团队的即时回应。随即，该部门进行了后续漏洞测试、打补丁和安全修复等工作，以确保客户始终处在安全的网络环境中。 +* 相反，再看看基于标准且开放的开发模式：它有助于快速识别潜在的安全漏洞。举个栗子，在 2014 年，常用的 OpenSSL 加密软件库发现了 Heartbleed。已经订阅红帽软件的客户都在第一时间收到了红帽安全响应团队的即时回应。随即，该部门进行了后续漏洞测试、打补丁和安全修复等工作，以确保客户始终处在安全的网络环境中。 -* 红帽公司总裁兼 CEO Jim Whitehurst 在一次采访中表示：“在 Heartbleed 发生时，每个人都收到通知，同时红帽在第一时间做出了响应。在红帽，我们有专门的安全响应团队，来迅速、专注处理这类问题。” +* 红帽公司总裁兼 CEO Jim Whitehurst 在一次采访中表示：「在 Heartbleed 发生时，每个人都收到通知，同时红帽在第一时间做出了响应。在红帽，我们有专门的安全响应团队，来迅速、专注处理这类问题。」 ## 参考资料 -- [走出误区 正确认识开源](https://searchvirtual.techtarget.com.cn/10-20427/) - -- [What is open source?](https://opensource.com/resources/what-open-source) \ No newline at end of file +- [走出误区 正确认识开源](https://searchvirtual.techtarget.com.cn/10-20427/) +- [What is open source?](https://opensource.com/resources/what-open-source) diff --git "a/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\246\202\344\275\225\346\211\276\345\210\260\351\200\202\345\220\210\350\207\252\345\267\261\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256.md" "b/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\246\202\344\275\225\346\211\276\345\210\260\351\200\202\345\220\210\350\207\252\345\267\261\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256.md" index 31c00146dbafac4f3678d8a6f939e607b1b67e97..8bea67663a9d2173c9cdd8cc93a4829a65891676 100644 --- "a/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\246\202\344\275\225\346\211\276\345\210\260\351\200\202\345\220\210\350\207\252\345\267\261\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256.md" +++ "b/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\246\202\344\275\225\346\211\276\345\210\260\351\200\202\345\220\210\350\207\252\345\267\261\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256.md" @@ -1,4 +1,3 @@ - ## 关键指标 ### 1. 技术栈 @@ -15,7 +14,7 @@ Star 数量相差不多的情况下，可以看项目作者的影响力。有影 ### 4. README.md -README.md 是关于项目的文档说明，在这个文件中会详细说明 **项目名及简介**，**项目背景**，**项目 LOGO 和使用截图**，**项目的功能点**，**体验地址**，**如何下载这个项目**, **安装项目所需依赖** ， **如何安装** ， **如何部署** ，以及 **Debug 方法** 。通常来说，README.md 的详细程度和美观程度与该项目的靠谱程度成正比。 +README.md 是关于项目的文档说明，在这个文件中会详细说明 **项目名及简介**，**项目背景**，**项目 LOGO 和使用截图**，**项目的功能点**，**体验地址**，**如何下载这个项目**，**安装项目所需依赖**，**如何安装**，**如何部署**，以及 **Debug 方法**。通常来说，README.md 的详细程度和美观程度与该项目的靠谱程度成正比。 ### 5. 项目的最后更新时间 @@ -37,45 +36,43 @@ GPL、LGPL、BSD、Apache Licence Vesion 2.0、MIT。 综合评估的指标下，选择一个相对来说成熟并且适合你自己的就好了。 - - ## 如何搜索 ### 在 GitHub 上搜索信息 当我们知道自己要找的技术栈、编程语言或框架等关键要素之后，我们就可以通过搜索引擎或在代码托管平台上进行搜索。以 GitHub 为例，除了直接搜索关键字，GitHub 还提供了许多条件搜索功能，善用这些功能，可以更加快速有效地找到我们想要的、优质的开源项目。比如： -1. 匹配含有 "cats" 字样、星标超过 1000 个的仓库。 +1. 匹配含有「cats」字样、星标超过 1000 个的仓库。 ``` cats stars:>1000 ``` -2. 匹配含有 "vue" 字样、有 5 个或更多主题的仓库。 +2. 匹配含有「vue」字样、有 5 个或更多主题的仓库。 ``` vue topics:>=5 ``` -3. 匹配含有 "node" 字样，有 10,000 或更多关注者的仓库。 +3. 匹配含有「node」字样，有 10,000 或更多关注者的仓库。 ``` node followers:>=10000 ``` -4. 匹配已归类为 "algorithm" 主题的仓库 +4. 匹配已归类为「algorithm」主题的仓库 ``` topic:algorithm ``` -5. 匹配遵循 Apache License 2.0 授权的仓库 +5. 匹配遵循「Apache License 2.0」授权的仓库 ``` license:apache-2.0 ``` -6. 匹配项目自述文件中提及 "arduino" 的仓库。 +6. 匹配项目自述文件中提及「arduino」的仓库。 ``` arduino in:readme @@ -89,7 +86,6 @@ GPL、LGPL、BSD、Apache Licence Vesion 2.0、MIT。 更多搜索语法相关内容，请查阅 GitHub Docs 文档 [在 GitHub 上搜索信息](https://docs.github.com/cn/free-pro-team@latest/github/searching-for-information-on-github)。 - ### 关注 GitHub 趋势榜 在 [github.com/trending](https://github.com/trending) 页面可以了解每天、每周、每月 GitHub 社区里最激动人心的仓库和作者，经常关注 GitHub 趋势榜，更容易找到适合自己学习和使用的优质项目。 @@ -100,5 +96,4 @@ GPL、LGPL、BSD、Apache Licence Vesion 2.0、MIT。 ### GitHub 中文社区 -对于新手来说，还有一个不错的选择 —— 通过 [GitHub 中文社区](https://www.githubs.cn/) 进行搜索。该站点整合了 GitHub 热门趋势、精选项目、排行榜、分类搜索等功能，同样可以帮助我们更快地找到想要的优质项目。 - +对于新手来说，还有一个不错的选择 —— 通过 [GitHub 中文社区](https://www.githubs.cn/) 进行搜索。该站点整合了 GitHub 热门趋势、精选项目、排行榜、分类搜索等功能，同样可以帮助我们更快地找到想要的优质项目。 \ No newline at end of file diff --git "a/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\344\270\255\347\232\204\350\265\236\350\265\217\346\226\207\345\214\226.md" "b/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\344\270\255\347\232\204\350\265\236\350\265\217\346\226\207\345\214\226.md" index a842640a3cbd56773c409a8dc57e26d0fbc8e897..8155dc8fae3449be9bbf24dc611c645d02721fa7 100644 --- "a/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\344\270\255\347\232\204\350\265\236\350\265\217\346\226\207\345\214\226.md" +++ "b/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\344\270\255\347\232\204\350\265\236\350\265\217\346\226\207\345\214\226.md" @@ -8,8 +8,6 @@ > 可补充赞赏文化的具体现状，如打赏等 - - ### 为什么会产生这种赞赏文化 说到赞赏文化的产生，不禁想起了在早期程序员的社区和群里，大家互相分享软件，共同提高知识水平。正是这种自由的风气给大家带来了欢乐，也带来了进步，当然也推动了开源事业的发展。在这其中赞赏文化就起到了重大的影响。 @@ -18,8 +16,6 @@ 还有就是目前赞赏文化已然收到了了社会上主流文化的认可和科技公司的推崇。赞赏文化是计算机科学领域的一种文化现象，源自对黑客精神的敬仰及对智慧成果的共享的感恩。不过，它的发展也不排除利益驱动。一方面是个人对自己影响力的打造，还有一方面是公司极端对招聘、向市场投放自己产品的需求。还有一个原因那就是其它媒体文化的感染，说到这就可以追溯到早期的 BBS，再到贴吧、知乎，以及后起之秀抖音、快手和 B 站。这是每一个参与者对内容及创作人的鼓励和肯定，累计到一起的行为习惯带动了开源事业更好的发展。 - - ### 赞赏文化的意义 赞赏文化发展到现在，这种能够积极促进程序员交流、项目推进的文化已经受到了广大程序员群体的认可。很多黑客贡献代码的初衷首先就是个人价值。 @@ -32,11 +28,4 @@ 社会化编程的创新，为全球开发者提供了空前的资源，从一个软件 Stars 数量，到更新频率，让技术爱好者们足不出户了解当前最新国际前沿发展趋势。同时用这些数据筛选出活跃在社区里的精英，因为这些精英程序员往往代码代码清晰、优美。只有能做到这些的程序员才可以被赋予维护代码的权限。依靠赞赏文化带来的更多的执行能力权利，这就是大教堂模式。 -赞赏文化在鼓励 Coder 创作的同时，通过了解开源文化，让人们可以获得道德层面的正面暗示，增加分享与合作的意识，减少保守与自私的负面思想。除此之外，赞赏文化对于整个社会的发展，它在启迪民智、促进正面思想产生上可以起到积极作用。开源文化孵化衍生出的赞赏文化，这种思想的诞生提高了软件行业的生产效率、促进了人与人之间生产力发展，传播了积极的文化和思想，是知识传播与社会进步的推动力，这些可以看作是开源代码在更具有深远意义上的探索。 - - - - - - - +赞赏文化在鼓励 Coder 创作的同时，通过了解开源文化，让人们可以获得道德层面的正面暗示，增加分享与合作的意识，减少保守与自私的负面思想。除此之外，赞赏文化对于整个社会的发展，它在启迪民智、促进正面思想产生上可以起到积极作用。开源文化孵化衍生出的赞赏文化，这种思想的诞生提高了软件行业的生产效率、促进了人与人之间生产力发展，传播了积极的文化和思想，是知识传播与社会进步的推动力，这些可以看作是开源代码在更具有深远意义上的探索。 \ No newline at end of file diff --git "a/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\346\272\220\344\273\243\347\240\201\350\257\245\346\200\216\344\271\210\350\257\273.md" "b/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\346\272\220\344\273\243\347\240\201\350\257\245\346\200\216\344\271\210\350\257\273.md" index fe15fdc9bb878e5c3f48cdea014d2bf6fef7af2e..9030c334ebe7e225d612fd9f11e817bf48fea007 100644 --- "a/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\346\272\220\344\273\243\347\240\201\350\257\245\346\200\216\344\271\210\350\257\273.md" +++ "b/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\346\272\220\344\273\243\347\240\201\350\257\245\346\200\216\344\271\210\350\257\273.md" @@ -2,22 +2,22 @@ Gitee 上的项目种类和数量繁多，作为新手的话，要选择适合自己的项目进行学习。 1. 以实际项目为导向，可以是真正的工程项目，也可以是生活中实用的小项目，根据实际项目可以有方向性的选择开源项目； -2. 调查实际项目相关领域的常用开源项目，可以参考项目的活跃度(Gitee 指数)，贡献者数量，star 数等缩小选择范围，学习过程可以获取更加丰富的资料； +2. 调查实际项目相关领域的常用开源项目，可以参考项目的活跃度(Gitee 指数)，贡献者数量，Star 数等缩小选择范围，学习过程可以获取更加丰富的资料； 3. 通过项目的 README.md 了解项目的大体情况，再进行研究和选择。 ### 读源代码之前的准备工作 1. 领域知识储备 -开源项目往往是以领域知识为背景进行开发的，了解领域知识中基本概念、原理、算法，必然会降低阅读理解源码的难度。 + 开源项目往往是以领域知识为背景进行开发的，了解领域知识中基本概念、原理、算法，必然会降低阅读理解源码的难度。 2. 善用学习工具 -方便查找的 IDE 工具使源码阅读过程事半功倍，阅读源码要搞清楚函数之间的调用关系，IDE 拥有代码静态分析功能和便捷的断点调试功能，可以帮助你快速查看源码调用关系，整体了解源码的逻辑关系。类图工具，方便梳理、记录和可视化项目调用的逻辑关系，加快深入学习。 + 方便查找的 IDE 工具使源码阅读过程事半功倍，阅读源码要搞清楚函数之间的调用关系，IDE 拥有代码静态分析功能和便捷的断点调试功能，可以帮助你快速查看源码调用关系，整体了解源码的逻辑关系。类图工具，方便梳理、记录和可视化项目调用的逻辑关系，加快深入学习。 3. 了解开源项目 -查找和阅读该项目的官网、相关博客和资料，对项目的目的、功能、基本使用和代码组织结构进行大概的了解，进一步明确学习内容和目标。 + 查找和阅读该项目的官网、相关博客和资料，对项目的目的、功能、基本使用和代码组织结构进行大概的了解，进一步明确学习内容和目标。 ### 读源代码时应该读些什么 diff --git "a/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\350\256\244\350\257\206\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201.md" "b/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\350\256\244\350\257\206\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201.md" index 683be055f1609209a359c23a6bba494fc3e68af2..635579c28efbf5b1bd86dab92215b4e4ffdcd578 100644 --- "a/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\350\256\244\350\257\206\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201.md" +++ "b/\347\254\2542\351\203\250\345\210\206\342\200\224\342\200\224\345\255\246\344\271\240\345\222\214\344\275\277\347\224\250\345\274\200\346\272\220\351\241\271\347\233\256/\350\256\244\350\257\206\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201.md" @@ -1,14 +1,12 @@ # 认识开源许可证 - ## 一、什么是开源许可证（License） 开源许可证是一种法律许可。通过它，版权拥有人明确允许，用户可以免费地使用、修改、共享版权软件。 当你对你的产品使用开源许可证时，并不意味着你放弃了任何权利，你依然对其拥有原著作权。开源许可证只是授予他们于特定权利来使用你的产品。 -版权法默认禁止共享， **也就是说，没有许可证的软件，就等同于保留版权** 。虽然开源了，但用户只能查看源码，无法使用，否则就会侵犯版权。所以如果选择开源一款软件，必须明确地授予用户开源许可证。 - +版权法默认禁止共享，**也就是说，没有许可证的软件，就等同于保留版权**。虽然开源了，但用户只能查看源码，无法使用，否则就会侵犯版权。所以如果选择开源一款软件，必须明确地授予用户开源许可证。 ## 二、开源许可证的种类 @@ -19,18 +17,17 @@ 根据使用条件的不同，开源许可证分成两大类。 > - 宽松式（permissive）许可证 -> - Copyleft（许可复制权） 许可证 +> - Copyleft（许可复制权）许可证 主流开源许可证如下（版权强度由高到低）： -| **宽松式（permissive）许可证** | **Copyleft（许可复制权） 许可证** | -| :---------------------------------------------------------- | ------------------------------------------------------------ | +| **宽松式（permissive）许可证** | **Copyleft（许可复制权） 许可证** | +| :--- | --- | | BSD (Berkeley Software Distribution)
MIT
Apache 2 | Affero GPL (AGPL)
GPL
Lesser GPL (LGPL)
Mozilla Public License (MPL)
Eclipse Public License (EPL)
Common Development and Distribution License (CDDL) | - ## 三、主流的开源许可证简介 -### 1.宽松式许可证 +### 1. 宽松式许可证 #### 1.1 特点 @@ -62,7 +59,7 @@ BSD License 与其他自由软件 License 相比，如 GPL，限制更少。但是请注意到 BSD License 两种版本之间的差别：New BSD License/Modified BSD License 和 Simplified BSD License/FreeBSD License。它们两者都是与 GPL 兼容的自由软件 License。 -New BSD License(**三条款版**)可以用于任何作为版权声明和保证许可的免责声明的目的，可以通过无限长的再分发来得以维持，也就是说如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的 BSD 协议。它还有一个特殊限制条款：不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 +New BSD License（**三条款版**）可以用于任何作为版权声明和保证许可的免责声明的目的，可以通过无限长的再分发来得以维持，也就是说如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的 BSD 协议。它还有一个特殊限制条款：不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 New BSD License 和 Simplified BSD License 的主要区别是，后者忽略了非认可条款。 @@ -91,7 +88,7 @@ Apache Licence 也是对商业应用友好的许可。使用者也可以在需 商业软件可以使用，也可以修改使用 Apache 协议的代码。 -### 2.Copyleft 许可证 +### 2. Copyleft 许可证 #### 2.1 Copyleft 的含义 @@ -101,9 +98,9 @@ Copyright 直译是「复制权」，这是版权制度的核心，意为不经 但是，它带有前提条件，比宽松式许可证的限制要多。 -> - 如果分发二进制格式，必须提供源码 -> - 修改后的源码，必须与修改前保持许可证一致 -> - 不得在原始许可证以外，附加其他限制 +- 如果分发二进制格式，必须提供源码 +- 修改后的源码，必须与修改前保持许可证一致 +- 不得在原始许可证以外，附加其他限制 上面三个条件的核心就是：修改后的 Copyleft 代码不得闭源。 @@ -161,7 +158,7 @@ CDDL（Common Development and Distribution License，通用开发与销售许可 商业软件可以使用，也可以修改 CDDL 协议的代码。 -### 3.其它的重要许可证 +### 3. 其它的重要许可证 #### 3.1 Creative Commons @@ -169,21 +166,21 @@ Creative Commons（CC）的许可证不太开放源代码授权，它们通常 * **署名** -作者必须是作品的原创者。除此之外，作品可以修改，分发，复制和以其他方式使用。 + 作者必须是作品的原创者。除此之外，作品可以修改，分发，复制和以其他方式使用。 * **相同方式共享** -工作可以修改，分发等等，但必须在一个许可证下。 + 工作可以修改，分发等等，但必须在一个许可证下。 * **非商业** -可以修改，分发等，但不用于商业目的。关于什么是「商业」，说法比较含糊（没有提供明确的定义），因此您可能需要在自己的项目中澄清这一点。 + 可以修改，分发等，但不用于商业目的。关于什么是「商业」，说法比较含糊（没有提供明确的定义），因此您可能需要在自己的项目中澄清这一点。 * **禁止修改** -这意味着您可以复制和分发许可工作，但你不能以任何方式修改，或在原有的基础开发。 + 这意味着您可以复制和分发许可工作，但你不能以任何方式修改，或在原有的基础开发。 -商业软件的使用要遵从 CC 协议的具体规定，最严格的许可证将是「署名，非商业，不能修改」的授权。这意味着你可以自由共享的工作，但不能改变它，你必须把它归功于原创者。 + 商业软件的使用要遵从 CC 协议的具体规定，最严格的许可证将是「署名，非商业，不能修改」的授权。这意味着你可以自由共享的工作，但不能改变它，你必须把它归功于原创者。 #### 3.2 Common Public License 1.0 @@ -205,25 +202,18 @@ Common 许可证有一些细节性的规定值得参考: 木兰宽松许可证是首个来自于中国的开源协议。其 v2 版通过开源促进会（OSI）认证，被批准为国际类别开源许可证，与 Apache 2.0 许可证兼容。 - - ### 四、开源许可证的约束力 > 「许可证相当于开源社区的基本法，发展到今天，已经越来越有约束力了。」 -- 北京大学法学院教授张平 待补充 - - ### 五、开源许可证的法律效力 中国第一个关涉 GPL 协议的诉讼案件宣判（[(2018)京民终471号《二审判决书》](http://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?docId=3c0957c9b82e456eb6ceab0d002c50ba)），认可了 GPL 协议的法律效力，但对 GPL 协议约束的判断规则也存在争议。 待补充 - - - ### 六、怎么选择开源许可证？ 可查看开源指北中[ **启动自己的开源项目/开源许可证的应用** ](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%AC%AC%E5%9B%9B%E9%83%A8%E5%88%86%E2%80%94%E2%80%94%E5%90%AF%E5%8A%A8%E8%87%AA%E5%B7%B1%E7%9A%84%E5%BC%80%E6%BA%90%E9%A1%B9%E7%9B%AE/%E5%BC%80%E6%BA%90%E8%AE%B8%E5%8F%AF%E8%AF%81%E7%9A%84%E5%BA%94%E7%94%A8.md)部分 @@ -231,8 +221,6 @@ Common 许可证有一些细节性的规定值得参考: ![img](https://www.ruanyifeng.com/blogimg/asset/201105/bg2011050101.png) - - --- ### 参考资料 diff --git "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\344\270\252\344\272\272\344\270\272\344\273\200\344\271\210\350\246\201\345\217\202\344\270\216\345\274\200\346\272\220\350\264\241\347\214\256.md" "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\344\270\252\344\272\272\344\270\272\344\273\200\344\271\210\350\246\201\345\217\202\344\270\216\345\274\200\346\272\220\350\264\241\347\214\256.md" index 015e9ad7ba24ebed08367e715a90ec718931eab5..e9c54106983e0b319190200750f4140f5cc44324 100644 --- "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\344\270\252\344\272\272\344\270\272\344\273\200\344\271\210\350\246\201\345\217\202\344\270\216\345\274\200\346\272\220\350\264\241\347\214\256.md" +++ "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\344\270\252\344\272\272\344\270\272\344\273\200\344\271\210\350\246\201\345\217\202\344\270\216\345\274\200\346\272\220\350\264\241\347\214\256.md" @@ -1,4 +1,4 @@ -「开源理念之一就是非常鼓励不同的人一起合作」——Linux 之父 `Linus Torvalds` 2016 年 2 月 TED 演讲《[The mind behind Linux](https://www.bilibili.com/video/BV1Cs411z73j)》[1] +「开源理念之一就是非常鼓励不同的人一起合作」——Linux 之父 `Linus Torvalds` 2016 年 2 月 TED 演讲[《The mind behind Linux》](https://www.bilibili.com/video/BV1Cs411z73j)[1] 一个有生命力的开源软件总是有爱好者不断参加到开发中来，持续完善软件代码，不断提高软件的性能；1998 年 2 月，开放源代码促进会，由 `Bruce Perens` 及 `Eric Steven Raymond` 等人创立；从上个世纪九十年代萌芽，到现在许多企业利用开源软件形成了独特的商业模式；为开源做贡献至少可以明确一个目的：技能得到提升。 diff --git "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\344\274\201\344\270\232\344\270\272\344\273\200\344\271\210\350\246\201\345\217\202\344\270\216\345\274\200\346\272\220.md" "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\344\274\201\344\270\232\344\270\272\344\273\200\344\271\210\350\246\201\345\217\202\344\270\216\345\274\200\346\272\220.md" index d763fd5f22ab003ae1fff685957fa87002ae5eb8..69ba77405e245aed7078fff1b0732341b12e50d8 100644 --- "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\344\274\201\344\270\232\344\270\272\344\273\200\344\271\210\350\246\201\345\217\202\344\270\216\345\274\200\346\272\220.md" +++ "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\344\274\201\344\270\232\344\270\272\344\273\200\344\271\210\350\246\201\345\217\202\344\270\216\345\274\200\346\272\220.md" @@ -8,9 +8,7 @@ ## 企业选择回馈其实是理性选择 -不考虑公益的情况，纯粹从利益角度算一笔账： -最初并不认为使用开源软件有什么成本，但经过两三个版本的迭代以后，成本会急剧上升。一般公司经历了多次实践后才认可这种模型，这是付出了惨痛代价以后才意识到的。如果从一开始就选择与社区合作，就可以与社区一起讨论产品的特性，然后再进行修改。最初的维护成本并不高，研发的成本会很高，但由于所要求的团队能力并不一样，维护成本会逐渐降低。 -基于开源软件修改，社区下一步准备做什么、怎么做，然后就都清楚，与社区有很好的互动沟通。虽然在前期投入了很大的成本，但最终取得了相应的成果。 +不考虑公益的情况，纯粹从利益角度算一笔账：最初并不认为使用开源软件有什么成本，但经过两三个版本的迭代以后，成本会急剧上升。一般公司经历了多次实践后才认可这种模型，这是付出了惨痛代价以后才意识到的。如果从一开始就选择与社区合作，就可以与社区一起讨论产品的特性，然后再进行修改。最初的维护成本并不高，研发的成本会很高，但由于所要求的团队能力并不一样，维护成本会逐渐降低。基于开源软件修改，社区下一步准备做什么、怎么做，然后就都清楚，与社区有很好的互动沟通。虽然在前期投入了很大的成本，但最终取得了相应的成果。 ## 企业参与开源的概念 @@ -24,17 +22,17 @@ 短期回报是指通过开源短期内获取既得利益的行为。企业能够通过开源占领市场份额，获得更大的市场利益，比如：对外发放品牌授权、对外提供咨询和服务费用。此外，企业还可以通过吸引开源项目参与者，集思广益，反哺到自己闭源版本的项目，降低技术升级的成本。 -- 项目质量提升、加快项目进度: 谷歌首席科学家杰夫·迪恩（JeffDean）指出，传统的软件研发实在是太慢了，通常是一个程序员花上几个月写完代码，然后上会讨论，再根据其他人的意见进行相应的修改。相比之下，如果采用开源的协作开发形式，谷歌开发人员能够实时与科学界进行协作，谷歌之外的人才也能够参与TensorFlow源代码的编写，而机器学习技术的共享能够广泛吸引更多的技术人才完善TensorFlow系统。这样，TensorFlow的开发进度就大大加快了。 +- 项目质量提升、加快项目进度: 谷歌首席科学家杰夫·迪恩（JeffDean）指出，传统的软件研发实在是太慢了，通常是一个程序员花上几个月写完代码，然后上会讨论，再根据其他人的意见进行相应的修改。相比之下，如果采用开源的协作开发形式，谷歌开发人员能够实时与科学界进行协作，谷歌之外的人才也能够参与 TensorFlow 源代码的编写，而机器学习技术的共享能够广泛吸引更多的技术人才完善 TensorFlow 系统。这样，TensorFlow 的开发进度就大大加快了。 - 收取咨询和服务费用: JBoss、Spring 通过提供技术支持、培训、二次开发支持等技术服务而获得收入 **长期回报** -长期回报是指通过长期持续的开源，获得更多利益和荣誉的行为。企业可以通过长期开源项目，打造核心团队的技术影响力和竞争力，提升企业项目的质量。技术影响力的提升会进一步带来更多技术人员的认同，保持“影响力-人才”的良性循环，吸引更多优质人才加入企业。此外，企业的影响力也能够提升员工归属感和认同感，为企业推行工程师文化提供支持。 +长期回报是指通过长期持续的开源，获得更多利益和荣誉的行为。企业可以通过长期开源项目，打造核心团队的技术影响力和竞争力，提升企业项目的质量。技术影响力的提升会进一步带来更多技术人员的认同，保持「影响力-人才」的良性循环，吸引更多优质人才加入企业。此外，企业的影响力也能够提升员工归属感和认同感，为企业推行工程师文化提供支持。 - 吸引更多的人才: 将产品开源，如果能建立良好的声誉，会让开源开发者对公司产生兴趣，而公司则可以从开源贡献者中选取人才，这提供了一种互相发现对方的机会，招聘到这种人才是非常划算的，因为该程序员的能力早已在项目的贡献中得到检验，而且入职后无需磨合就能够直接上手工作。 - 技术影响力提升: 公司将代码开源，使更多的开发者参与进来，参与进来的开发者可以凭借自身渠道为项目做一定的宣传，从而带动更多的人参与开源项目，形成良性循环，为公司带来一定程度上的声誉从而进一步提高公司在技术方面的影响力 ## 参考资料 -* [为什么微软、Google 等都在纷纷拥抱开源？](https://blog.csdn.net/csdnnews/article/details/106880314). -* [开源之道](http://opensourceway.community/posts/opensource_enterprise_guide/improve-open-source-dev-impact). +* [为什么微软、Google 等都在纷纷拥抱开源？](https://blog.csdn.net/csdnnews/article/details/106880314) +* [开源之道](http://opensourceway.community/posts/opensource_enterprise_guide/improve-open-source-dev-impact) \ No newline at end of file diff --git "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\217\257\344\273\245\347\224\250\345\223\252\344\272\233\346\226\271\345\274\217\345\217\202\344\270\216\345\274\200\346\272\220.md" "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\217\257\344\273\245\347\224\250\345\223\252\344\272\233\346\226\271\345\274\217\345\217\202\344\270\216\345\274\200\346\272\220.md" index 7a2a7ff63500084251a3b9d0c3548aa05a655580..552c5e74b218d880c813d292dc802eb19c835096 100644 --- "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\217\257\344\273\245\347\224\250\345\223\252\344\272\233\346\226\271\345\274\217\345\217\202\344\270\216\345\274\200\346\272\220.md" +++ "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\217\257\344\273\245\347\224\250\345\223\252\344\272\233\346\226\271\345\274\217\345\217\202\344\270\216\345\274\200\346\272\220.md" @@ -68,15 +68,13 @@ GitHub 采用 Pull Requests 方式，可以快速的参与到开源项目中。 Gitee 创新采用了 Gitee Pull Request Lite，不需要 Fork ，直接可以在网页上面进行代码的提交，这种方式使得参与开源项目更加的便捷，尤其适合仅需少量的修改就可以完成的场景。当然，Gitee 也完全支持传统的 fork-update-pr-merge 提交流程，对于大量的代码修改或者多个模块的联动修改，更建议采用这种方式，因为可以更好地通过测试用例来验证代码的影响范围和正确性，保证所提交的代码具有一定的质量水准。 -对于常见的“Fork + Pull”模式，需要将开源项目仓库 Fork 一份副本，占用用户名下仓库空间，在 Fork 和 Clone 过程中存在一定的网络传输和等待时间，为创建一个 Pull Request 带来一定的时间和操作成本，在 Gitee 就可以通过轻量级 PR（Gitee Pull Request Lite），开发者只需在 Web 端完成代码贡献（添加、删除、修改代码等等），就能一键向开源项目仓库提出Pull Request 请求，减去了中间大量的繁琐操作。无论是单文件修改还是多文件编辑都可以使用轻量级 PR，了解更多关于轻量级 PR 的使用方式和介绍可以点击查看 [Gitee 帮助中心](https://gitee.com/help/articles/4291) 。 - +对于常见的「Fork + Pull」模式，需要将开源项目仓库 Fork 一份副本，占用用户名下仓库空间，在 Fork 和 Clone 过程中存在一定的网络传输和等待时间，为创建一个 Pull Request 带来一定的时间和操作成本，在 Gitee 就可以通过轻量级 PR（Gitee Pull Request Lite），开发者只需在 Web 端完成代码贡献（添加、删除、修改代码等等），就能一键向开源项目仓库提出Pull Request 请求，减去了中间大量的繁琐操作。无论是单文件修改还是多文件编辑都可以使用轻量级 PR，了解更多关于轻量级 PR 的使用方式和介绍可以点击查看 [Gitee 帮助中心](https://gitee.com/help/articles/4291)。 ## 注释 - [1] 因为 QQ/WeChat 没有支持 Linux 系统，对于使用 Linux 为主系统的开发者/贡献者/维护者来讲非常不友好，所以才会有很多开源社区/项目使用 Telegram（简称 TG ）作为实时沟通工具。TG 可以通过配置 Bot（机器人）来自动完成很多低级且重复的操作，相比 QQ/WeChat 不支持大文件不支持 `Code 块` 显示有了很多优势，而且消息可追溯和 Bot 配合能很友好的解决很多问题。同时也希望国产软件能够提供支持 Linux 的软件，来完善 Linux 生态。 - ### 参考资料 -* [Gitee 使用流程](https://blog.csdn.net/qq_45069279/article/details/106174340)。 -* [Gitee 参与开源流程](https://blog.csdn.net/u010852680/article/details/77718998)。 \ No newline at end of file +* [Gitee 使用流程](https://blog.csdn.net/qq_45069279/article/details/106174340) +* [Gitee 参与开源流程](https://blog.csdn.net/u010852680/article/details/77718998) \ No newline at end of file diff --git "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\246\202\344\275\225\346\210\220\344\270\272\344\270\200\344\270\252\351\241\271\347\233\256\347\232\204\346\240\270\345\277\203\350\264\241\347\214\256\350\200\205.md" "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\246\202\344\275\225\346\210\220\344\270\272\344\270\200\344\270\252\351\241\271\347\233\256\347\232\204\346\240\270\345\277\203\350\264\241\347\214\256\350\200\205.md" index 6deb30f32b2ab1f83219eac1c7a44a18815f5342..998661748a4c99844ddbfd142f87450eb2aafa57 100644 --- "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\246\202\344\275\225\346\210\220\344\270\272\344\270\200\344\270\252\351\241\271\347\233\256\347\232\204\346\240\270\345\277\203\350\264\241\347\214\256\350\200\205.md" +++ "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\246\202\344\275\225\346\210\220\344\270\272\344\270\200\344\270\252\351\241\271\347\233\256\347\232\204\346\240\270\345\277\203\350\264\241\347\214\256\350\200\205.md" @@ -1,5 +1,3 @@ - - ``` 可补充从社区的角度来阐述对核心贡献者的需求，比如与社区贡献者配合的能力和意愿，维护社区秩序和参与社区共建等。 ``` @@ -11,13 +9,9 @@ ## 核心贡献者有哪些特质 1. 态度上认可 - 2. 能力上匹配 - 3. 自己的时间管理 - 4. 坚持 - 5. 持续不断的学习 ## 这些特质为什么那么重要 @@ -48,20 +42,24 @@ 如果以上几点你都具备了，恭喜你，你已经基本达到了应有的水平。最后的一件事情就是，你不能总是照着别人已经做好的事情做搬砖的事情。那么如何才能将贡献的内容注入自己的灵魂？把你的思维和想法分享给大家，让大家也能从你贡献的内容中有所收获，有所领悟，那么就需要你不断的学习新的东西，技术更新非常之快，那么就需要我们对于自己专业的领域有更多自己的看法，这样才会有更多的创新思路，才会让我们这个领域有更多可发展和延伸的道路。 - ## 如何成为一个项目的核心贡献者（补充） - 1.要顾全的大局 - 不要为了自己的一点私心去做事，大家嘴上不说但都看的到。多了大局去考虑，领导就喜欢这样的人，也愿意提拔爱顾大局的人。 +1. 要顾全的大局 + + 不要为了自己的一点私心去做事，大家嘴上不说但都看的到。多了大局去考虑，领导就喜欢这样的人，也愿意提拔爱顾大局的人。 + +2. 做事不古板 + + 在团队里随时都能发生应急事件，遵守规则制度是应该的。但不可事事太古板，要懂得随机应变，有了处理好应急事件的能力。 + +3. 不逃避责任 + + 在发生事故的时候，不要逃避责任，更不要给自己找垫背的。优秀的人才都是能够承担责任的，事故不可能总有，也不可能总没有，如果次次都选择逃避，还怎么做核心人物。 - 2.做事不古板 - 在团队里随时都能发生应急事件，遵守规则制度是应该的。但不可事事太古板，要懂得随机应变，有了处理好应急事件的能力。 +4. 愿意帮助每个队员 - 3.不逃避责任 - 在发生事故的时候，不要逃避责任，更不要给自己找垫背的。优秀的人才都是能够承担责任的，事故不可能总有，也不可能总没有，如果次次都选择逃避，还怎么做核心人物。 + 收拢人心很要，你能力再强，别人又为什么要选你呢，那是因为你身上有闪光点。而对队员来说，你对大家给予的真诚帮助，就能帮你赢得一大片人心。 - 4.愿意帮助每个队员 - 收拢人心很要，你能力再强，别人又为什么要选你呢，那是因为你身上有闪光点。而对队员来说，你对大家给予的真诚帮助，就能帮你赢得一大片人心。 +5. 取长补短 - 5.取长补短 - 这也是最重要的一条，你拥有了别人不会的技术，又是团队必须具备的技术。你就成了技术骨干了，多去学习别的长处，将自身的短处补齐。 \ No newline at end of file + 这也是最重要的一条，你拥有了别人不会的技术，又是团队必须具备的技术。你就成了技术骨干了，多去学习别的长处，将自身的短处补齐。 \ No newline at end of file diff --git "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\246\202\344\275\225\346\211\276\345\210\260\351\200\202\345\220\210\347\232\204\351\241\271\347\233\256\350\277\233\350\241\214\350\264\241\347\214\256.md" "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\246\202\344\275\225\346\211\276\345\210\260\351\200\202\345\220\210\347\232\204\351\241\271\347\233\256\350\277\233\350\241\214\350\264\241\347\214\256.md" index 1afda86e10efe2a181ced482e4ab6d4a436a17bc..a25d654dd3019a6d551f6cfe7317ef1a451ab87d 100644 --- "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\246\202\344\275\225\346\211\276\345\210\260\351\200\202\345\220\210\347\232\204\351\241\271\347\233\256\350\277\233\350\241\214\350\264\241\347\214\256.md" +++ "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\246\202\344\275\225\346\211\276\345\210\260\351\200\202\345\220\210\347\232\204\351\241\271\347\233\256\350\277\233\350\241\214\350\264\241\347\214\256.md" @@ -2,14 +2,13 @@ ## 前言 -说到“如何找到适合的项目进行贡献”，首先，我们先来聊一聊：什么是所谓“适合的项目”？ +说到「如何找到适合的项目进行贡献」，首先，我们先来聊一聊：什么是所谓「适合的项目」？ - 比如青春时代的你，偶然邂逅了一见钟情的 Ta； - - 比如快意江湖的你，身边结识了意气相投的朋友； - 比如唱着单身情歌的你，在 Starbucks Coffee 等待着第一次见面的相亲对象 -正所谓“最贵的未必是最好的，最适合的一定是最好的”（不要问我这句话的出处，问就是摘自本人语录），这句话放在寻找开源项目上也适用。 +正所谓「最贵的未必是最好的，最适合的一定是最好的」（不要问我这句话的出处，问就是摘自本人语录），这句话放在寻找开源项目上也适用。 想要找到适合自己的开源项目，首先要了解自己。 @@ -17,51 +16,57 @@ 哪怕一次不确定的相亲，也会打扮得衣冠楚楚。可能最后未必合适，那么喝完这杯 Starbucks，咱们就此别过，好聚好散。 -OK，刚才我们用通俗易懂的类比向大家说明了什么叫“适合”，接下来我们言归正传。 +OK，刚才我们用通俗易懂的类比向大家说明了什么叫「适合」，接下来我们言归正传。 ## 目的 首先，要明确参加项目的初衷和目标。下面列举了一些例子，供大家参考。 -- 对 xx 项目仰慕已久，想要“掀起她的盖头来”（听说或见过，想要深入了解开源项目） -- 工作中使用到 xx 项目，日久生情，愿意做彼此的欢喜冤家（工作中经常使用，但也会遇到棘手的问题，喜提 issues） -- 抱 xx 项目的大腿，成为一名牛x哄哄的 contributor（想要提升自己内力，以及职业生涯的含金量） +- 对 xx 项目仰慕已久，想要「掀起她的盖头来」（听说或见过，想要深入了解开源项目） +- 工作中使用到 xx 项目，日久生情，愿意做彼此的欢喜冤家（工作中经常使用，但也会遇到棘手的问题，喜提 Issues） +- 抱 xx 项目的大腿，成为一名牛 x 哄哄的 Contributor（想要提升自己内力，以及职业生涯的含金量） - 没有什么喜欢的项目，随便看看（了解前瞻性技术，保持技术新鲜度） - - …… -下面就带着这些目标，开始“按图索骥”。 +下面就带着这些目标，开始「按图索骥」。 ## 方法 ### 寻找项目信息的渠道 - 从开源网站寻找 - - 比如：Github、GitLab、Gitee、OsChina、CSDN、InfoQ 等 + + 比如：Github、GitLab、Gitee、OsChina、CSDN、InfoQ 等 + - 参加技术沙龙 - - 比如：中国软件技术大会、Pivotal 技术峰会、各种 Meetup 等 + + 比如：中国软件技术大会、Pivotal 技术峰会、各种 Meetup 等 + - 加入技术讨论群 - - 比如：QQ 群、微信群、钉钉群等 + + 比如：QQ 群、微信群、钉钉群等 + - 和身边人沟通 - - 比如：老师、同学、同事、朋友 + + 比如：老师、同学、同事、朋友 ### 匹配合适项目的维度 - 从个人兴趣着手 - - 兴趣是最好的老师。 + 兴趣是最好的老师。 - 和谈恋爱一样，只要保持热情，那么Ta就是适合你的；反之，就要酌情放手 + 和谈恋爱一样，只要保持热情，那么 Ta 就是适合你的；反之，就要酌情放手 - 从个人技术栈着手 - - 比如：C、C++、C#、Java、Python、Golang 等 + 比如：C、C++、C#、Java、Python、Golang 等 - 从工作需求着手 - - “世*有伯乐*,然后有千里马”。一定是现有需求，而后才有解决方案。 + 「世有伯乐，然后有千里马。」一定是现有需求，而后才有解决方案。 - 比如：前端的 Vue、Reactor，后端的 SpringBoot、SpringCloud，大数据相关的 Spark、Fink、Hadoop 等 + 比如：前端的 Vue、Reactor，后端的 SpringBoot、SpringCloud，大数据相关的 Spark、Fink、Hadoop 等 ### 参与项目贡献的方法 @@ -73,15 +78,21 @@ OK，刚才我们用通俗易懂的类比向大家说明了什么叫“适合” ### 参与项目贡献的注意事项 - Issues - - 按照项目要求的格式提交（格式要求、内容要求、语言要求等） + + 按照项目要求的格式提交（格式要求、内容要求、语言要求等） + - Code - - 按照项目要求的编码规范编写代码（代码缩进、代码换行等） - - 项目一般会提供不同 IDE 对应的配置文件，达成代码格式统一 + + 按照项目要求的编码规范编写代码（代码缩进、代码换行等） + 项目一般会提供不同 IDE 对应的配置文件，达成代码格式统一 + - Comment - - 按照项目要求的格式编写注释（代码注释、Git 提交注释等） + + 按照项目要求的格式编写注释（代码注释、Git 提交注释等） - 沟通 - - 沟通是项目发展的基石，多和一个项目的朋友 say hello + + 沟通是项目发展的基石，多和一个项目的朋友 Say hello ## 写在后面 @@ -97,8 +108,7 @@ OK，刚才我们用通俗易懂的类比向大家说明了什么叫“适合” 1. 符合自己的技术栈项目。这个是最起码的要求，总不能选一个自己都不了解的语言项目进行贡献。 2. 在工作和学习中使用比较多，比较熟悉的项目。这样你在动手修改它的代码之前就已经对它有了充分的了解，至少你是熟悉这个项目的各类使用方式和接口。 -3. 各个模块耦合性比较低的项目，比如组件库、工具库，容易找到入手点。如前端所使用的 element-ui ，antd-ui 组件库。组件库的耦合性较低，向组件库增加或修改某一个组件也较为方便。同时工具库也是一个不错的选择，新增或修改某一个功能也较为容易。相反，模块之间耦合性比较大的项目可能就不太合适，比如各种大型的框架，这类开源项目耦合性较高。 +3. 各个模块耦合性比较低的项目，比如组件库、工具库，容易找到入手点。如前端所使用的 Element-ui ，Antd-ui 组件库。组件库的耦合性较低，向组件库增加或修改某一个组件也较为方便。同时工具库也是一个不错的选择，新增或修改某一个功能也较为容易。相反，模块之间耦合性比较大的项目可能就不太合适，比如各种大型的框架，这类开源项目耦合性较高。 4. 兴趣是最好的向导。为自己感兴趣的开源项目做贡献，会更加充满热情和动力。 5. 针对人而不同就会有不同的语言，对于自己比较熟悉的语言开始，从工作中或者培训当中挑选出比熟悉的项目进行贡献。 6. 在工作使用中进行过扩展，并且经受过生产实践，就可以将代码贡献到对应的开源项目中。 - diff --git "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\350\264\241\347\214\256\345\207\206\345\210\231\345\222\214\350\264\241\347\214\256\350\200\205\345\205\254\347\272\246.md" "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\350\264\241\347\214\256\345\207\206\345\210\231\345\222\214\350\264\241\347\214\256\350\200\205\345\205\254\347\272\246.md" index 3a702eee0efbda19ea456cc5913454cfeb7c7b94..ed7d742345f1a958954423d8ac61bab3ef11babb 100644 --- "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\350\264\241\347\214\256\345\207\206\345\210\231\345\222\214\350\264\241\347\214\256\350\200\205\345\205\254\347\272\246.md" +++ "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\350\264\241\347\214\256\345\207\206\345\210\231\345\222\214\350\264\241\347\214\256\350\200\205\345\205\254\347\272\246.md" @@ -10,7 +10,6 @@ ## 贡献准则 - 有助于创建积极环境的行为包括但不限于： - 措辞体贴，友好和耐心 @@ -45,4 +44,4 @@ ## 参考文献 -本贡献准则参考自 [Contributor Covenant](https://www.contributor-covenant.org/)，版本 v2.0，可以在这里查看，[https://www.contributor-covenant.org/version/2/0/code_of_conduct/code_of_conduct.md](https://www.contributor-covenant.org/version/2/0/code_of_conduct/code_of_conduct.md)。 \ No newline at end of file +本贡献准则参考自 [Contributor Covenant](https://www.contributor-covenant.org/)，版本 v2.0，可以在这里查看：。 diff --git "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" index ff137710d13a0d3067d13da4647d2c4d4a1c61a7..461d3822f2e63c43ac36b3f653ce3213c4e178a6 100644 --- "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" +++ "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" @@ -1,17 +1,15 @@ ### 什么是 Issue -Issue 的翻译大致为**议题**、**问题**。 +Issue 的翻译大致为 **议题**、**问题**。 -![issue的翻译](https://images.gitee.com/uploads/images/2020/1103/095504_32fddf55_1277510.png "image-20201030195145149.png") +![Issue 的翻译](https://images.gitee.com/uploads/images/2020/1103/095504_32fddf55_1277510.png "image-20201030195145149.png") -为了方便你理解，我们更愿意把它称之为**待办清单**、**问题或 bug 列表**、**讨论版**等等。相信这些称呼会让你更容易理解什么是 Issue。 +为了方便你理解，我们更愿意把它称之为 **待办清单**、**问题或 Bug 列表**、**讨论版** 等等。相信这些称呼会让你更容易理解什么是 Issue。 这是一种伟大的协作方式，让你可以更方便的对整个仓库进行跟踪、增强和排错[1]。对于一个公开的仓库来说，Issue 是向所有人开放的，不仅仓库的所有者可以给自己提 Issue，其他人也可以对项目提 Issue。 而根据 Gitee 官方的建议，项目相关的技术问题、缺陷报告、建议等信息都可以通过 Issue 进行发布。 - - ### 什么情况下需要提交 Issue 那么什么情况下需要提交 Issue 呢？ @@ -40,8 +38,6 @@ Issue 的翻译大致为**议题**、**问题**。 * 对于你自己来说，自己可以使用 Issue 来发布待办清单，给自己提开发任务或 Bug，开帖找大家探讨项目下一步的发展方向等等。当然，你也可以用它来提出一些跟仓库内容无关的事情，这也是允许的。 * 如果你想要提 Issue 的仓库不是你自己的，而是他人的的时候，Issue 就是一个很好的多人协作系统。比如发现了别人项目的 Bug 的时候；比如想要别人添加某个新功能的时候；比如有使用上的困难，需要求助作者使用步骤的时候，你都可以给别人的仓库提出 Issue。同时，如果你是一个热心的开发者，你也可以帮助原作者回答一些别人提出的 Issue，这样的行为可以极大地帮助原作者分担压力哦。不要觉得自己是在做临时免费工，解答的过程中你的知识和技术也会得到巩固和提高，有时还能结交到许多志同道合的好朋友哦。我助人，人亦助我。 - - ### 一个好的 Issue 应该写些什么 那么一个好的 Issue 应该写点什么呢？ @@ -50,8 +46,8 @@ Issue 的翻译大致为**议题**、**问题**。 #### Issue 的礼仪[2] -1. 提问使用的语言 ：在主要面向母语为中文的开发者的开源平台，首选中文。在其他开源平台，首选仓库维护者的母语进行交流，如果不确定或有困难，建议选择英文交流。 -2. 提问态度和语气 ：因为你面对的是跟你一样的开发者，不卑不亢，虚心求教就可以了，不必要太咋呼，措辞太夸张等。但是言语之间要表示对作者的尊重，最好多使用`请`、`谢谢`、`Please`、`Thanks`等词语。 +1. 提问使用的语言：在主要面向母语为中文的开发者的开源平台，首选中文。在其他开源平台，首选仓库维护者的母语进行交流，如果不确定或有困难，建议选择英文交流。 +2. 提问态度和语气：因为你面对的是跟你一样的开发者，不卑不亢，虚心求教就可以了，不必要太咋呼，措辞太夸张等。但是言语之间要表示对作者的尊重，最好多使用 `请`、`谢谢`、`Please`、`Thanks` 等词语。 3. **如有 Issue 模板，请参照模板写 Issue**。如果原作者定义了 Issue 模板，请按模板来写，避免挤牙膏式的交流。如没有，本文会有比较通用的模板提供给大家。总之，撰写的原则是，把事情表述清楚，便于原作者处理和与你交流。 #### 一个好 Issue 的标准[2] @@ -71,7 +67,7 @@ Issue 的翻译大致为**议题**、**问题**。 先使用方括号（也可以使用`【】`替代方括号），里面写上分类、标签或某文件名（比如这个文件有问题待修改），这部分是便于作者进行问题分类的，也方便其他协作者查找（很多人提 Issue 并没有这一部分，建议加上）。然后使用简短的描述，可以让人通过标题快速了解这个 Issue 是讲什么内容的。 -案例：`[Bug]app.py文件173行运行报错，疑似遗漏一个=号` +案例：`[Bug]app.py 文件 173 行运行报错，疑似遗漏一个 = 号` #### 提出一个 Issue @@ -80,12 +76,8 @@ Issue 的翻译大致为**议题**、**问题**。 ```markdown ### 该问题是怎么引起的？ - - ### 重现步骤 - - ### 报错信息 ``` @@ -95,11 +87,11 @@ Issue 的翻译大致为**议题**、**问题**。 在 Gitee 中，支持在新建仓库时创建 Issue 模板，也支持自定义模板。 -在新建仓库时，勾选`使用 Issue 模板文件初始化这个项目`，实际上就是在仓库根目录下新建了 `.gitee/ISSUE_TEMPLATE.zh-CN.md` 文件，当然你也可以自己创建这个文件，来编写自己的模板。 +在新建仓库时，勾选 `使用 Issue 模板文件初始化这个项目`，实际上就是在仓库根目录下新建了 `.gitee/ISSUE_TEMPLATE.zh-CN.md` 文件，当然你也可以自己创建这个文件，来编写自己的模板。 ![选择使用模板来初始化项目](https://images.gitee.com/uploads/images/2020/1104/184559_3f5d281c_1277510.png "image-20201104183636294.png") -自己创建 Issue 模板，可在仓库中创建`.gitee`目录，并创建对应的模板文件： +自己创建 Issue 模板，可在仓库中创建 `.gitee` 目录，并创建对应的模板文件： 1. `.gitee/ISSUE_TEMPLATE.zh-CN.md`，Issue 中文模板 2. `.gitee/ISSUE_TEMPLATE.en.md`，Issue 英文模板 @@ -107,39 +99,37 @@ Issue 的翻译大致为**议题**、**问题**。 > Q: 不同类型的模板，有什么作用？ > -> A: 例如你的仓库中有 3 种语言类型的 Issue 模板，提交 Issue 的用户使用的是英文版，那么当用户勾选`使用 Issue 模板`，则会智能地使用英文模板，如果对方使用的是中文版则会智能地使用中文 Issue 模板。 +> A: 例如你的仓库中有 3 种语言类型的 Issue 模板，提交 Issue 的用户使用的是英文版，那么当用户勾选 `使用 Issue 模板`，则会智能地使用英文模板，如果对方使用的是中文版则会智能地使用中文 Issue 模板。 当你在敲标题或者 Issue 内容时，项目会自动显示已有的类似 Issue，你可以先查看一下推荐的 Issue 能否解决你的问题，如果不能再提出，避免反复提出同一个问题。 好了，当你完成 Issue 主体内容的填写之后，快去提交给作者吧！ - - ### Issue 案例（有价值和无价值） 下面我们来看几个 Issue 的案例。 **无价值：** -[https://gitee.com/sentsin/layui/issues/I1SS5Z](https://gitee.com/sentsin/layui/issues/I1SS5Z) + ![无价值案例1](https://images.gitee.com/uploads/images/2020/1103/095610_3fe4df54_1277510.png "image-20201102230656555.png") -该案例的标题仅两个字`表格`，作者如果不点进 Issue 的具体内容则无法获知到底这个 Issue 说的是什么。属于无价值案例。 +该案例的标题仅两个字 `表格`，作者如果不点进 Issue 的具体内容则无法获知到底这个 Issue 说的是什么。属于无价值案例。 --- -[https://gitee.com/sentsin/layui/issues/I1PQVC](https://gitee.com/sentsin/layui/issues/I1PQVC) + ![无价值案例2](https://images.gitee.com/uploads/images/2020/1103/095627_8b4fadf6_1277510.png "image-20201102230927454.png") -该案例最抓人眼球的应该是那一长串的`!`号，画面都快容不下了，而且作者在看这样的标题的时候也无法获知到底是个什么问题，有一种过分夸张的感觉。属于无价值案例。 +该案例最抓人眼球的应该是那一长串的 `!` 号，画面都快容不下了，而且作者在看这样的标题的时候也无法获知到底是个什么问题，有一种过分夸张的感觉。属于无价值案例。 --- **有价值：** -[https://gitee.com/sentsin/layui/issues/I1OFU3](https://gitee.com/sentsin/layui/issues/I1OFU3) + ![有价值案例1](https://images.gitee.com/uploads/images/2020/1103/095655_074d520b_1277510.png "image-20201102231303010.png") @@ -147,7 +137,7 @@ Issue 的翻译大致为**议题**、**问题**。 --- -[https://gitee.com/sentsin/layui/issues/I1OD1P](https://gitee.com/sentsin/layui/issues/I1OD1P) + ![有价值案例2](https://images.gitee.com/uploads/images/2020/1103/095715_67d435b1_1277510.png "image-20201102231520201.png") @@ -161,8 +151,6 @@ Issue 的翻译大致为**议题**、**问题**。 因此，Issue 的精准表述是能获得良好协作的基础，提 Issue 也是一种很好的练习表达的方式。 - - ### Issue 的进阶使用 掌握了 Issue 的基础使用之后，作为一个优秀的开发者，我们还可以掌握一些进阶的知识，它能让你压榨干净 Issue 的每一分价值。 @@ -183,7 +171,7 @@ Issue 的翻译大致为**议题**、**问题**。 * **标签**：高质量的 Issue 是项目成功的关键。有些人把 Issue 仅仅看作是一堆你不得不去处理的问题列表，但是如果这些问题单管理完善，进行了分类并打上标签，会令人意想不到的提升我们对代码和社区的了解程度，也让我们更清楚问题的关键点在哪里。[2]将标签完善之后，不管是仓库所有者还是其他人都可以快速定位含有某标签的 Issue，协作的效率也将大大提高。 - 在 Gitee 中，Issue 中的**标签**支持修改原有标签名称、从其它项目导入标签以及新增自定义标签等。一个默认的仓库会有如下一些默认的标签[2][3]： + 在 Gitee 中，Issue 中的 **标签** 支持修改原有标签名称、从其它项目导入标签以及新增自定义标签等。一个默认的仓库会有如下一些默认的标签[2][3]： ![Issue中的默认标签](https://images.gitee.com/uploads/images/2020/1104/121827_6dd23a40_1277510.png "image-20201103210736651.png") @@ -239,21 +227,21 @@ Issue 的翻译大致为**议题**、**问题**。 Issue 在提出之后，对于个人版来说可以有四种状态：待办的、进行中、已完成、已拒绝。负责人或者协作者可以修改该状态。企业版会可选更多的状态。 -> 状态变更之后，允许再次变更，比如设置为`已完成`状态的 Issue，可以再次修改为`进行中`。 +> 状态变更之后，允许再次变更，比如设置为 `已完成` 状态的 Issue，可以再次修改为 `进行中`。 ![Issue 的状态切换](https://images.gitee.com/uploads/images/2020/1104/122341_7c087174_1277510.png "image-20201104120709716.png") -我们还可以在`看板`中看到处于每种状态的 Issue 的列表。 +我们还可以在 `看板` 中看到处于每种状态的 Issue 的列表。 ![看板页面](https://images.gitee.com/uploads/images/2020/1104/122400_f9648c84_1277510.png "image-20201104120934433.png") #### @ 提及别人 -使用`@`符号可以在 Issue 提出或者问题讨论的过程中提及别人，起到被 `艾特`的效果。 +使用 `@` 符号可以在 Issue 提出或者问题讨论的过程中提及别人，起到被 `艾特` 的效果。 #### # 关联其他 Issue -使用`#`符号再加上其他 Issue 的编号，可以关联到其它的 Issue。找到本仓库下 Issue 的编号之后写上即可。 +使用 `#` 符号再加上其他 Issue 的编号，可以关联到其它的 Issue。找到本仓库下 Issue 的编号之后写上即可。 找到 Issue 编号（这里为 `#I23WUE`）： @@ -275,7 +263,7 @@ Issue 在提出之后，对于个人版来说可以有四种状态：待办的 比如在修复一个 Bug 时，某一次 Commit 就是解决了提这个 Bug 的 Issue 的，那么我们可以轻松的在 Commit 的内容中附带上一些特殊信息（在 Commit 信息中或者附加信息中均可），来自动关闭 Issue。 -Gitee 支持的提交方式有（比如我们需要关闭的 Issue 编号为 24，`+`号表示在提交的内容中添加后面部分的内容）[4]： +Gitee 支持的提交方式有（比如我们需要关闭的 Issue 编号为 24，`+` 号表示在提交的内容中添加后面部分的内容）[4]： ```markdown # 任选其一即可！ @@ -304,26 +292,17 @@ Gitee 支持的提交方式有（比如我们需要关闭的 Issue 编号为 24 通过特有的语法可以实现待办清单的功效，修改待办清单里面的项目是否完成无需再打开 Issue 的编辑界面了！ * [x] 吃早餐 - * [ ] 吃午餐 - * [ ] 吃晚餐 ``` -通过`* [x]`来创建已勾选的事项，通过`* [ ]`来创建未勾选的事项即可。 - -> 请注意，设置未勾选状态时，方括号之间会有一个空格`[ ]`，不要漏掉了。 - - - +通过 `* [x]` 来创建已勾选的事项，通过 `* [ ]` 来创建未勾选的事项即可。 +> 请注意，设置未勾选状态时，方括号之间会有一个空格 `[ ]`，不要漏掉了。 ### 参考资料 -[1] [https://guides.github.com/features/issues/](https://guides.github.com/features/issues/) - -[2] [https://zhuanlan.zhihu.com/p/75691927](https://zhuanlan.zhihu.com/p/75691927) - -[3] [https://blog.csdn.net/lovewinner/article/details/80763629](https://blog.csdn.net/lovewinner/article/details/80763629) - -[4] [https://www.jianshu.com/p/5ba1e7f5ad70](https://www.jianshu.com/p/5ba1e7f5ad70) \ No newline at end of file +- [1] +- [2] +- [3] +- [4] \ No newline at end of file diff --git "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Pull Request.md" "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Pull Request.md" index b6f77ecef9a10ea74bd058c21fdf5685ddfbd57a..1d360817bbf74023eadcc6e0aac714b9256a9d72 100644 --- "a/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Pull Request.md" +++ "b/\347\254\2543\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Pull Request.md" @@ -1,22 +1,19 @@ ### 尝试参与开源：提交第一个 Pull Request - ``` 文章以 GitHub 为基准，需要补充 Gitee 的相关操作 ``` ``` -merge pull request的流程相对简单，是通过两个自己项目的repo进行的阐述，需要补充权限说明，code review，approve，CI机制等 +merge pull request 的流程相对简单，是通过两个自己项目的 repo 进行的阐述，需要补充权限说明，code review，approve，CI 机制等 ``` - #### 什么是 Pull Request -这个是由 GitHub 提出的概念。根据 GitHub 的官方文档，Pull Request 是一种通知机制，它可以告知仓库的其他开发者，你推送了一个仓库新分支。 通过Pull Request ，你可以和仓库的协作者一起讨论和审查提交的代码，审查通过后，就可以提交到仓库的主分支中。 +这个是由 GitHub 提出的概念。根据 GitHub 的官方文档，Pull Request 是一种通知机制，它可以告知仓库的其他开发者，你推送了一个仓库新分支。 通过 Pull Request，你可以和仓库的协作者一起讨论和审查提交的代码，审查通过后，就可以提交到仓库的主分支中。 Pull Request 本质上是一种协同工作的机制，可以进行基于网络的多人提交，审核机制，审核通过后，就可以合并到主分支中。 - #### 提交 Pull Request 的步骤 第一步，你需要 Fork 别人的仓库。也就是复制别人的仓库到你自己的仓库中。 @@ -27,14 +24,13 @@ Pull Request 本质上是一种协同工作的机制，可以进行基于网络 第三步，在提交中，描述提交本地提交的说明。 - #### 实际操作一下 1. 在 GitHub 上建立两个帐号 A 和 B。 -1. 使用 A 帐号，创建项目 pull_request_demo +2. 使用 A 帐号，创建项目 pull_request_demo -1. 在本地提交 README.md +3. 在本地提交 README.md ``` echo "pull_request_demo from A" >> README.md @@ -46,9 +42,9 @@ Pull Request 本质上是一种协同工作的机制，可以进行基于网络 git push -u origin main ``` -1. 使用 B 帐号登录 GitHub，然后 Fork 该项目。 +4. 使用 B 帐号登录 GitHub，然后 Fork 该项目。 -1. 下载项目到本地 +5. 下载项目到本地 ``` git clone https://github.com/B/pull_request_demo @@ -58,15 +54,15 @@ Pull Request 本质上是一种协同工作的机制，可以进行基于网络 git push ``` -1. 使用 B 帐号登录 GitHub，进入 pull_request_demo 仓库，点击 Pull request 链接。 +6. 使用 B 帐号登录 GitHub，进入 pull_request_demo 仓库，点击 Pull request 链接。 -1. 选择 base 和 head 仓库。点击「New pull request」按钮。 +7. 选择 base 和 head 仓库。点击「New pull request」按钮。 -1. 填写提交说明后，「Create pull request」。 +8. 填写提交说明后，「Create pull request」。 -1. 使用 A 帐号登录 GitHub，进行 pull_request_demo 项目。 +9. 使用 A 帐号登录 GitHub，进行 pull_request_demo 项目。 -1. 可以看到 Pull request 中有新的数据。 +10. 可以看到 Pull request 中有新的数据。 -1. 点击 Confirm merge，完成合并。 +11. 点击 Confirm merge，完成合并。 diff --git "a/\347\254\2544\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/CONTRIBUTING \347\274\226\345\206\231.md" "b/\347\254\2544\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/CONTRIBUTING \347\274\226\345\206\231.md" index 4ddddfb7350ab600e6ce7e0b8d7d7b80173191c4..5a047b8c8ba95ccedef632a1b338aa5d494d0eca 100644 --- "a/\347\254\2544\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/CONTRIBUTING \347\274\226\345\206\231.md" +++ "b/\347\254\2544\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/CONTRIBUTING \347\274\226\345\206\231.md" @@ -2,9 +2,7 @@ ## CONTRIBUTING 是什么 -> ​ CONTRIBUTING 文件用来告诉人们如何对项目做出贡献. - - +> CONTRIBUTING 文件用来告诉人们如何对项目做出贡献. ## CONTRIBUTING 如何编写 @@ -21,8 +19,6 @@ 7. 分支处理的约定 8. 合并 PR 的形式 - - ### 例子 ```md @@ -58,4 +54,3 @@ 2. 两个及以上的维护者通过. 3. 最新版本 ``` - diff --git "a/\347\254\2544\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/\344\270\272\345\274\200\346\272\220\351\241\271\347\233\256\345\273\272\347\253\213\350\211\257\345\245\275\347\232\204\345\237\272\347\241\200.md" "b/\347\254\2544\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/\344\270\272\345\274\200\346\272\220\351\241\271\347\233\256\345\273\272\347\253\213\350\211\257\345\245\275\347\232\204\345\237\272\347\241\200.md" index 66a4b569afa719053a64c8a252f10978b442e218..2789cf3211ca7dca2e4251ddedc37ecd45e0b02a 100644 --- "a/\347\254\2544\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/\344\270\272\345\274\200\346\272\220\351\241\271\347\233\256\345\273\272\347\253\213\350\211\257\345\245\275\347\232\204\345\237\272\347\241\200.md" +++ "b/\347\254\2544\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/\344\270\272\345\274\200\346\272\220\351\241\271\347\233\256\345\273\272\347\253\213\350\211\257\345\245\275\347\232\204\345\237\272\347\241\200.md" @@ -8,22 +8,20 @@ 但是如果我们的项目是一款开源产品，就需要用既有辨识度又能让人易于记忆的名称了。那怎么能让人易于记忆呢？ -我个人的建议是反向利用联想记忆法，从项目的功能或者特点出发，联想到有一些关联又特别的名称。可以从影视作品、文学作品、游戏作品等取材，因为这些作品往往充满想象，拥有丰富的人物、事物设定。特别是从一些深受欢迎，传播深远的作品中获取灵感。一个典型的案例是 `Python`，它的意思为`蟒蛇`，源于它的创始人龟叔（Guido van Rossum）很喜欢的英国 20 世纪 70 年代首播的电视喜剧《蒙提·派森的飞行马戏团》（Monty Python's Flying Circus）。 +我个人的建议是反向利用联想记忆法，从项目的功能或者特点出发，联想到有一些关联又特别的名称。可以从影视作品、文学作品、游戏作品等取材，因为这些作品往往充满想象，拥有丰富的人物、事物设定。特别是从一些深受欢迎，传播深远的作品中获取灵感。一个典型的案例是 `Python`，它的意思为 `蟒蛇`，源于它的创始人龟叔（Guido van Rossum）很喜欢的英国 20 世纪 70 年代首播的电视喜剧《蒙提·派森的飞行马戏团》（Monty Python's Flying Circus）。 另外，朗朗上口的名称也会让人跟容易记忆。这可能有关语言学，但是很多成功的项目表明，使用双音节，辅音+元音，会有很好的效果！ - 再缩小范围，就是技术群体喜欢的科幻、魔幻作品，比如星球大战、漫威、哈利波特、迪士尼等等。我尝试在下面列出一些已有的和我想到的例子： -| 项目名称 | 项目类型 | 原意 | -| ----------------- | --------------------| ----------------------| -| Azkaban | 工作流 | 哈利波特中的一所监狱 | -| Tars | RPC 框架和配套平台 | 「星际穿越」中的机器人 | -| ZooKeeper | 分布式服务注册和治理 | 动物园管理员 | -| Elsa-workflow | 工作流 | 冰雪奇缘公主 | -| Tomcat | Web 服务管理器 | 经典的汤姆猫 | -| SkyWalking | 观察性分析、应用性能管理 | 天空行走，非常形象 | - +| 项目名称 | 项目类型 | 原意 | +| --- | --- | --- | +| Azkaban | 工作流 | 哈利波特中的一所监狱 | +| Tars | RPC 框架和配套平台 | 「星际穿越」中的机器人 | +| ZooKeeper | 分布式服务注册和治理 | 动物园管理员 | +| Elsa-workflow | 工作流 | 冰雪奇缘公主 | +| Tomcat | Web 服务管理器 | 经典的汤姆猫 | +| SkyWalking | 观察性分析、应用性能管理 | 天空行走，非常形象 | 相比还有很多优秀的项目，都有这种让人过目不忘的名称，欢迎继续补充。 @@ -45,7 +43,6 @@ README 应该包含哪些内容： - 参与贡献方式：指引开发者们如何参与到项目中协同完善整个开源项目。 - 开源协议：开源协议类型指引。 - 也可以参考成熟的开源项目以及同类型开源项目中的 README 的内容。 ### 为项目撰写文档 @@ -76,7 +73,6 @@ README 应该包含哪些内容： ### 开源项目的代码质量要求 - 一个认真打造的开源项目，肯定是希望有其他用户来使用，更希望有更多外部贡献者能参与进来的。那么评价一个开源项目好不好，代码的质量就是非常重要的衡量指标了。 代码质量是程序员的基本功，说到这个话题，首先自然是需要去翻阅经典的专著了，《重构》、《设计模式》、《代码整洁之道》是程序员必备的手边书。 @@ -99,4 +95,4 @@ README 应该包含哪些内容： 第五点，生产案例。开源项目大多数是业余时间进行开发的，本身没有企业支持。那么，当它们被真正用于企业生产环境，并带来收益了，才说明这个项目是真正对用户有价值的。所以，开源项目可以收集一下用户的生产案例，一方面可以鼓励开源贡献者的付出，另一方面又可以展现这个项目的价值，还能对企业进行一定的宣传，这是三赢。 -第六点，代码的注释。开源项目有一个很大的特点就是任何人都可以自愿为其在符合开源协议的情况下进行二次开发或者为其贡献出自己的代码，因此您所写出的应有较高的可读性以避免在他人想要进行贡献时因为代码的阅读产生障碍。所以一个好的开源项目应具有完善的代码注释，这也同样是一个良好的开发习惯，我们也有应理由相信我们能够做在这方面的更好！ \ No newline at end of file +第六点，代码的注释。开源项目有一个很大的特点就是任何人都可以自愿为其在符合开源协议的情况下进行二次开发或者为其贡献出自己的代码，因此您所写出的应有较高的可读性以避免在他人想要进行贡献时因为代码的阅读产生障碍。所以一个好的开源项目应具有完善的代码注释，这也同样是一个良好的开发习惯，我们也有应理由相信我们能够做在这方面的更好！ diff --git "a/\347\254\2544\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/\344\270\272\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256\345\273\272\347\253\213\350\264\241\347\214\256\345\207\206\345\210\231.md" "b/\347\254\2544\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/\344\270\272\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256\345\273\272\347\253\213\350\264\241\347\214\256\345\207\206\345\210\231.md" index b65ba434fe451ac8d46e530c40d9fd539bbfdef3..db2b75f7636834f61300859bcc5135c37a6742df 100644 --- "a/\347\254\2544\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/\344\270\272\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256\345\273\272\347\253\213\350\264\241\347\214\256\345\207\206\345\210\231.md" +++ "b/\347\254\2544\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/\344\270\272\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256\345\273\272\347\253\213\350\264\241\347\214\256\345\207\206\345\210\231.md" @@ -4,7 +4,7 @@ 你可能会问，License 不够用吗？为什么还要加一个贡献者协议呢？这就得从著作权说起了。 -从原理上说，软件开源开放的是软件的**使用权**，而非**著作权**（版权）。开源许可证指明了用户在某些限制下使用软件及其源代码，如果用户违反了开源许可证，最终依然要回归到著作权的法律框架下解决争端。 +从原理上说，软件开源开放的是软件的**使用权**，而非 **著作权**（版权）。开源许可证指明了用户在某些限制下使用软件及其源代码，如果用户违反了开源许可证，最终依然要回归到著作权的法律框架下解决争端。 那么著作权是怎么来的呢？根据《著作权法》的规定，著作权是作品完成时自然产生的，归作品的作者所有。对于大多数开源项目来说，著作权并不属于单一的人或实体，而是所有贡献者都有一份。可以想象，如果发生开源软件侵权，著作权的分散将给维权带来很多麻烦。另外，假如项目所有者想要更换或调整开源许可证，会因为并不持有全部的著作权受到阻碍，还可能由于著作权的原因与贡献者产生潜在的争议。 @@ -14,7 +14,7 @@ 2. 提供保证和免责声明，避免潜在的法律风险。 - > 设想这样一种场景，Alice 为项目贡献了实际为 Bob 所有的代码，并且未获得 Bob 的授权，但 Alice 在提交代码前签署了贡献者协议，保证代码来自于个人原创，此时法律责任完全由 Alice 承担。 + 设想这样一种场景，Alice 为项目贡献了实际为 Bob 所有的代码，并且未获得 Bob 的授权，但 Alice 在提交代码前签署了贡献者协议，保证代码来自于个人原创，此时法律责任完全由 Alice 承担。 具体到形式上，贡献者协议又可以分为 CLA 和 DCO，两者在不同场景下各有优劣。 @@ -26,11 +26,11 @@ CLA 由项目所有方**自行定义**，在细节上有大大小小的差异，没有统一的标准，但大致包括以下内容： -- 关于签署该 CLA 的**主体**和**贡献**的定义； +- 关于签署该 CLA 的 **主体** 和 **贡献** 的定义； - 授予著作权和专利许可给拥有该软件知识产权的公司或组织； - 签署者保证依法有权授予上述许可； -- 所有的贡献内容均为个人**版权所有**，或经过版权所有者的授权，对于贡献内容造成的侵权并不知情； -- 贡献内容的**免责声明**； +- 所有的贡献内容均为个人 **版权所有**，或经过版权所有者的授权，对于贡献内容造成的侵权并不知情； +- 贡献内容的 **免责声明**； - 说明贡献者提交非原创作品应该采用的方式； - 保证在获悉任何方面不准确的事实或情况之时通知签约方。 @@ -40,14 +40,14 @@ CLA 由项目所有方**自行定义**，在细节上有大大小小的差异， **DCO**，全称 Developer Certificate of Origin（开发者原创证书），最初是在 Linux Kernel 项目中引入的，由 Linux 基金会于 2004 年制定。 -相比于 CLA，DCO 是一种更轻量化的机制，它最大的优点是**标准化**，不要求开发者阅读冗长的法律条文，只需在提交的时候签署邮件地址即可。DCO 被很好地集成在了 Kernel 的版本控制软件 Git 里，因此只要在 `git commit` 的时候添加 `-s` 选项，`Signed-off-by` 就能很简单地添加到 `commit log` 中。 +相比于 CLA，DCO 是一种更轻量化的机制，它最大的优点是 **标准化**，不要求开发者阅读冗长的法律条文，只需在提交的时候签署邮件地址即可。DCO 被很好地集成在了 Kernel 的版本控制软件 Git 里，因此只要在 `git commit` 的时候添加 `-s` 选项，`Signed-off-by` 就能很简单地添加到 `commit log` 中。 DCO 目前最新版本是 1.1，内容如下： -> 1. 该贡献全部或部分由我创建，我有权根据文件中指明的开源许可提交；或者： -> 2. 该贡献是基于以前的工作，这些工作基于适当的开源许可，无论这些工作全部还是部分由我完成，我有权根据相同的开源许可证（除非我被允许根据不同的许可证提交）提交修改后的工作；或者： -> 3. 该贡献由 1、2 或 3 认证的其他人直接提供给我，而我没有对其进行修改。 -> 4. 我理解并同意该项目和贡献是公开的，并且该贡献的记录（包括我随之提交的所有个人信息，包括我的签字）将无限期保留，并且可以与本项目或涉及的开源许可保持一致或者重新分配。 +- 该贡献全部或部分由我创建，我有权根据文件中指明的开源许可提交；或者： +- 该贡献是基于以前的工作，这些工作基于适当的开源许可，无论这些工作全部还是部分由我完成，我有权根据相同的开源许可证（除非我被允许根据不同的许可证提交）提交修改后的工作；或者： +- 该贡献由 1、2 或 3 认证的其他人直接提供给我，而我没有对其进行修改。 +- 我理解并同意该项目和贡献是公开的，并且该贡献的记录（包括我随之提交的所有个人信息，包括我的签字）将无限期保留，并且可以与本项目或涉及的开源许可保持一致或者重新分配。 协议的核心在于「原创性确认」，也就是让补丁的提交者确认提交内容是自己创作或者经过别人授权的，并且充分了解项目方会如何使用自己的代码。 @@ -57,14 +57,14 @@ DCO 目前最新版本是 1.1，内容如下： 两种协议的对比如下： -| 属性 | CLA | DCO | -| -------- | -------------------------------- | -------------------------------------- | -| 签署方式 | 一次性签署 | 每次提交时追加 Signed-off-by 信息 | -| 法律责任 | 明确法律义务 | 无声明，用来限制提交者遵守开源 LICENSE | -| 自定义 | 公司或组织可自行定义 | 不可自定义，内容固定 | -| 社区属性 | 弱 | 强 | -| 公司属性 | 强，可签署公司级别的 CLA | 弱 | -| 使用案例 | Google、CNCF、Alibaba、openEuler、Apache SkyWalking | GitLab、Chef | +| 属性 | CLA | DCO | +| --- | --- | --- | +| 签署方式 | 一次性签署 | 每次提交时追加 Signed-off-by 信息 | +| 法律责任 | 明确法律义务 | 无声明，用来限制提交者遵守开源 LICENSE | +| 自定义 | 公司或组织可自行定义 | 不可自定义，内容固定 | +| 社区属性 | 弱 | 强 | +| 公司属性 | 强，可签署公司级别的 CLA | 弱 | +| 使用案例 | Google、CNCF、Alibaba、openEuler、Apache SkyWalking | GitLab、Chef | 说了这么多，究竟应该选择 CLA 还是 DCO 呢？这取决于项目本身和社区的需求，通常来说： @@ -112,9 +112,9 @@ DCO 目前最新版本是 1.1，内容如下： 虽然 CLA 在开源软件中得到了广泛运用，但关于它的争议一直没有停歇过。 -反对者认为 CLA 与开源运动的初衷相违背，多数情况下签署 CLA 即意味着**放弃自己劳动成果的版权**（或者说著作权），一旦版权转移给了项目方，项目方就有权在未来更换其他更严格的许可证，甚至直接将项目闭源，这显然是贡献者不愿意看到的。 +反对者认为 CLA 与开源运动的初衷相违背，多数情况下签署 CLA 即意味着 **放弃自己劳动成果的版权**（或者说著作权），一旦版权转移给了项目方，项目方就有权在未来更换其他更严格的许可证，甚至直接将项目闭源，这显然是贡献者不愿意看到的。 -除此以外，CLA 的**非标准性**可能导致贡献者和项目方处于地位不对等的状态，贡献者需要在参与每个项目时都仔细检查一遍条款，以避免自己的劳动成果被恶意利用，事实上在繁琐的协议条文面前，拥有成熟法务团队的大公司总是处于主导地位，这与尽可能降低门槛、崇尚自由合作的开源精神不符。 +除此以外，CLA 的 **非标准性** 可能导致贡献者和项目方处于地位不对等的状态，贡献者需要在参与每个项目时都仔细检查一遍条款，以避免自己的劳动成果被恶意利用，事实上在繁琐的协议条文面前，拥有成熟法务团队的大公司总是处于主导地位，这与尽可能降低门槛、崇尚自由合作的开源精神不符。 当然也不乏支持 CLA 的声音，理由之一是，CLA 的存在是一种应对法务风险的防御机制，很多大型企业基于开源软件构建产品并对客户提供服务，如果有开源社区的贡献者起诉他们侵犯专利或版权，败诉不仅意味着巨额的赔偿，还可能导致业务中断损失客户。 @@ -124,22 +124,13 @@ CLA 让更多大型企业和组织愿意参与开源社区并成为其中的中 ## 参考链接 -https://en.wikipedia.org/wiki/Contributor_License_Agreement - -https://jimmysong.io/blog/open-source-cla/ - -https://github.com/kubernetes/community/issues/2649 - -https://opensource.com/article/18/3/cla-vs-dco-whats-difference - -http://opensource.guide/zh-hans/ - -https://www.finnegan.com/en/insights/articles/what-you-should-know-about-contributor-license-agreements-in-open-source-projects.html - -https://opensource.stackexchange.com/questions/666/what-can-you-do-if-you-cant-track-down-all-old-contributors-to-sign-a-cla?rq=1 - -https://opensource.com/article/19/2/cla-problems - -https://www.rt-thread.org/cla/ - -http://disksing.com/cla-and-dco/ +- https://en.wikipedia.org/wiki/Contributor_License_Agreement +- https://jimmysong.io/blog/open-source-cla/ +- https://github.com/kubernetes/community/issues/2649 +- https://opensource.com/article/18/3/cla-vs-dco-whats-difference +- http://opensource.guide/zh-hans/ +- https://www.finnegan.com/en/insights/articles/what-you-should-know-about-contributor-license-agreements-in-open-source-projects.html +- https://opensource.stackexchange.com/questions/666/what-can-you-do-if-you-cant-track-down-all-old-contributors-to-sign-a-cla?rq=1 +- https://opensource.com/article/19/2/cla-problems +- https://www.rt-thread.org/cla/ +- http://disksing.com/cla-and-dco/ diff --git "a/\347\254\2544\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/\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201\347\232\204\345\272\224\347\224\250.md" "b/\347\254\2544\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/\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201\347\232\204\345\272\224\347\224\250.md" index ce1ea1637e197f2d4d562b19c2db2dd8aa36c32c..9da74993d8d4be21544f91057760940f667e8b71 100644 --- "a/\347\254\2544\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/\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201\347\232\204\345\272\224\347\224\250.md" +++ "b/\347\254\2544\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/\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201\347\232\204\345\272\224\347\224\250.md" @@ -12,28 +12,26 @@ #### 常见开源许可证授权概述 -| 协议 | 描述 | 要求 | 允许 | 禁止 | -| -------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | ----------------------------------------------- | -------------------------------------------- | -| LGPL | 主要用于一些代码库。衍生代码可以以此协议发布（言下之意你可以用其他协议），但与此协议相关的代码必需遵循此协议。 | 1.公开源码 2.库引用 3.协议和版权信息 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担（禁止让作者承担责任，可以理解为免责） | -| Mozilla | Mozilla Public License (MPL 2.0) 是由 Mozilla 基金创建维护的。此协议旨在较为宽松的 BSD 协议和更加互惠的 GPL 协议中寻找一个折衷点。 | 1.公开源码 2.协议和版权信息 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担 2.商标使用 | -| GPL | 此协议是应用最为广泛的开源协议，拥有较强的版权自由（copyleft）要求。衍生代码的分发需开源并且也要遵守此协议。此协议有许多变种，不同变种的要求略有不同。 | 1.公开源码 2.协议和版权信息 3.声明变更 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 | 1.责任承担 2.附加协议 | -| BSD | 较为宽松的协议，包含两个变种 BSD 2-Clause 和 BSD 3-Clause，两者都与 MIT 协议只存在细微差异。 | 1.协议和版权信息 | 1.商用 2.分发 3.修改 4.私用 5.附加协议 | 1.责任承担 | -| MIT | 宽松简单且精要的一个协议。在适当标明来源及免责的情况下，它允许你对代码进行任何形式的使用。 | 1.协议和版权信息 | 1.商用 2.分发 3.修改 4.私用 5.附加协议 | 1.责任承担 | -| Apache | 一个较宽松且简明地指出了专利授权的协议。 | 1.协议和版权信息 2.声明变更 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担 2.商标使用 | -| AGPL | 一个严格的开源协议，除非获得商业授权，否则无论以何种方式修改或者使用代码，都需要开源。 | 1.公开源码 2.协议和版权信息 3.声明变更 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担 | +| 协议 | 描述 | 要求 | 允许 | 禁止 | +| --- | --- | --- | --- | --- | +| LGPL | 主要用于一些代码库。衍生代码可以以此协议发布（言下之意你可以用其他协议），但与此协议相关的代码必需遵循此协议。 | 1.公开源码 2.库引用 3.协议和版权信息 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担（禁止让作者承担责任，可以理解为免责） | +| Mozilla | Mozilla Public License (MPL 2.0) 是由 Mozilla 基金创建维护的。此协议旨在较为宽松的 BSD 协议和更加互惠的 GPL 协议中寻找一个折衷点。 | 1.公开源码 2.协议和版权信息 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担 2.商标使用 | +| GPL | 此协议是应用最为广泛的开源协议，拥有较强的版权自由（copyleft）要求。衍生代码的分发需开源并且也要遵守此协议。此协议有许多变种，不同变种的要求略有不同。 | 1.公开源码 2.协议和版权信息 3.声明变更 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 | 1.责任承担 2.附加协议 | +| BSD | 较为宽松的协议，包含两个变种 BSD 2-Clause 和 BSD 3-Clause，两者都与 MIT 协议只存在细微差异。 | 1.协议和版权信息 | 1.商用 2.分发 3.修改 4.私用 5.附加协议 | 1.责任承担 | +| MIT | 宽松简单且精要的一个协议。在适当标明来源及免责的情况下，它允许你对代码进行任何形式的使用。 | 1.协议和版权信息 | 1.商用 2.分发 3.修改 4.私用 5.附加协议 | 1.责任承担 | +| Apache | 一个较宽松且简明地指出了专利授权的协议。 | 1.协议和版权信息 2.声明变更 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担 2.商标使用 | +| AGPL | 一个严格的开源协议，除非获得商业授权，否则无论以何种方式修改或者使用代码，都需要开源。 | 1.公开源码 2.协议和版权信息 3.声明变更 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担 | #### 木兰协议介绍 -| 协议 | 描述 | 要求 | 允许 | 禁止 | -|----------|------------|----|----|----| -| MulanPSL | 一个简洁明了宽松的开源协议，对开源的各种实体做出了明确的定义，以中英文双语表述，中英文版本具有同等法律效力。如果中英文版本存在任何冲突不一致，以中文版为准。 | 1.协议和版权信息 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担 2.商标使用 | +| 协议 | 描述 | 要求 | 允许 | 禁止 | +| --- | --- | --- | --- | --- | +| MulanPSL | 一个简洁明了宽松的开源协议，对开源的各种实体做出了明确的定义，以中英文双语表述，中英文版本具有同等法律效力。如果中英文版本存在任何冲突不一致，以中文版为准。 | 1.协议和版权信息 | 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 | 1.责任承担 2.商标使用 | -- 许可证明确不提供对“贡献者”的商品名称、商标、服务标志等的商标许可，保护“贡献者”的切身利益。 +- 许可证明确不提供对「贡献者」的商品名称、商标、服务标志等的商标许可，保护「贡献者」的切身利益。 - 解决联盟存在互诉漏洞，也就是 A 想诉 B，A 授权 C，由 C 可以诉 B 的问题。 - 比 Apache License 更友好一些，Apache License 要求列出每个修改文件，其实很多项目做不到这一点，所以 MulanPSL 直接取消了这项要求。 - - #### 快速选择 国内大神阮一峰根据乌克兰程序员 Paul Bagwell 的开源许可证选择分析图翻译的一份 [中文版本](http://www.ruanyifeng.com/blogimg/asset/201105/free_software_licenses.png)，是我目前见过的最通俗易懂的解析，因为语法支持的问题，用以下代码大致表示为： @@ -76,19 +74,19 @@ ![弹出的许可证向导介绍页面](https://images.gitee.com/uploads/images/2020/1112/101008_b0b4e938_1277510.png "image-20201112093418532.png") -在弹出的界面中，如果你需要创建自定义的许可证，请点击左下角的`创建自定义许可证`按钮，会自动创建一个 `LICENSE` 文件，你可以填入自定义的许可证内容，并进行代码提交即可。 +在弹出的界面中，如果你需要创建自定义的许可证，请点击左下角的 `创建自定义许可证` 按钮，会自动创建一个 `LICENSE` 文件，你可以填入自定义的许可证内容，并进行代码提交即可。 -如果你需要使用向导，请点击右下角的`开始选择`。 +如果你需要使用向导，请点击右下角的 `开始选择`。 ![许可证向导页面](https://images.gitee.com/uploads/images/2020/1112/101035_77bd62dd_1277510.png "image-20201112093643751.png") -接下来，你可以看到一个向导页面，向导页面的原理为通过一系列问题的形式了解你怎样的内置许可证更适合你的项目。如上图所示，我们需要回答设定好的七个问题，每个问题会有详细的解释，请通过你对于你项目的判断如实进行答案选择，然后点击`下一步`继续下一个问题的回答。 +接下来，你可以看到一个向导页面，向导页面的原理为通过一系列问题的形式了解你怎样的内置许可证更适合你的项目。如上图所示，我们需要回答设定好的七个问题，每个问题会有详细的解释，请通过你对于你项目的判断如实进行答案选择，然后点击 `下一步` 继续下一个问题的回答。 -在回答的过程中，你可以随时在下面列举出的内置许可证中选择你需要的许可证，点击右下角的`使用该许可证`结束向导。也可以在回答完所有问题之后，根据评分来进行选择。 +在回答的过程中，你可以随时在下面列举出的内置许可证中选择你需要的许可证，点击右下角的 `使用该许可证` 结束向导。也可以在回答完所有问题之后，根据评分来进行选择。 ![回答完许可证向导问题后](https://images.gitee.com/uploads/images/2020/1112/101056_0c9f2daa_1277510.png "image-20201112094434527.png") -如上图所示，我们已经根据需要回答完了所有的问题，Gitee 会自动对所有许可协议进行评分，一般你可以在得分最高的内置许可证中选择自己需要的即可，按下右下角的`使用该许可证`即可添加该 `LISENCE` 文件到项目的根目录下，十分方便。 +如上图所示，我们已经根据需要回答完了所有的问题，Gitee 会自动对所有许可协议进行评分，一般你可以在得分最高的内置许可证中选择自己需要的即可，按下右下角的 `使用该许可证` 即可添加该 `LISENCE` 文件到项目的根目录下，十分方便。 在确认之前，每个许可证都对每个问题有详细的回答，许可证被扣分的原因是某许可证并不是所有的方面都符合你的要求，你可以仔细阅读你关心的部分后再慎重做出选择。 @@ -102,6 +100,7 @@ * 如果使用多个开源许可证，变更开源许可证后，要防止不同开源许可证在授权上出现冲突的问题 ### 参考资料 + * [如何选择开源协议](https://www.cnblogs.com/cangqinglang/p/11326130.html). * [如何选择开源许可证？](http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html). * [木兰宽松许可证](http://license.coscl.org.cn/MulanPSL2). diff --git "a/\347\254\2544\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/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\347\273\264\346\212\244\345\222\214\347\256\241\347\220\206.md" "b/\347\254\2544\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/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\347\273\264\346\212\244\345\222\214\347\256\241\347\220\206.md" index 21fd094097ff004b7163a275d2cf7653e2ca08da..e5b2bd1690a3841782a45931dd3866610d2a5496 100644 --- "a/\347\254\2544\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/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\347\273\264\346\212\244\345\222\214\347\256\241\347\220\206.md" +++ "b/\347\254\2544\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/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\347\273\264\346\212\244\345\222\214\347\256\241\347\220\206.md" @@ -1,12 +1,12 @@ ### 如何推广开源项目 -「酒香也怕巷子深」这句话在互联网时代特别适用。我在 N 年前看过一本创业公司老板写的研发项目管理方面的书，到现在还记得一句话 「一个公司的核心竞争力，一是技术，二是营销」。对于一个开源项目，将代码放发布到代码托管平台仅仅是一个开始，真正重要的是社区运营工作。如何让更多的人能够快速了解你的项目而不是无人问津？如何让有兴趣的人更积极的参与项目而不是永远仅仅依靠一己之力不可持续？这些都是非常现实的挑战，也是一个开源项目能否健康发展的重要基础。 Apache 软件基金会（ASF）的 Apache Way 的核心理念就是 Community over Code （社区重于代码），也说明开源项目建立社区的重要性。 +「酒香也怕巷子深」这句话在互联网时代特别适用。我在 N 年前看过一本创业公司老板写的研发项目管理方面的书，到现在还记得一句话「一个公司的核心竞争力，一是技术，二是营销」。对于一个开源项目，将代码放发布到代码托管平台仅仅是一个开始，真正重要的是社区运营工作。如何让更多的人能够快速了解你的项目而不是无人问津？如何让有兴趣的人更积极的参与项目而不是永远仅仅依靠一己之力不可持续？这些都是非常现实的挑战，也是一个开源项目能否健康发展的重要基础。 Apache 软件基金会（ASF）的 Apache Way 的核心理念就是 Community over Code（社区重于代码），也说明开源项目建立社区的重要性。 要做好一个开源项目的推广，项目内容中除了源代码之外，完备的文档体系对吸引大家关注以及参与都是非常有帮助的。总之，如果仅仅只有一堆源代码，会让很多人都望而却步，以下简单列举三个非常必要的文档和规则说明。 项目总览自述文件（README） -开源项目中的 README 文件是非常重要的，你可以在 README 里面系统介绍有关这个开源项目的重要内容，包括项目主要功能特性、架构原理、安装及部署说明、简要的使用说明、目录文件结构、常见问题说明、交流沟通方式等内容，以便关注者能快速地了解这个项目的基本情况和总体情况。在常见的代码托管平台如 Github、Gitee 上，项目仓库首页默认展示的内容就是这个 README 文件的内容，相当于整个项目的“主页”。 +开源项目中的 README 文件是非常重要的，你可以在 README 里面系统介绍有关这个开源项目的重要内容，包括项目主要功能特性、架构原理、安装及部署说明、简要的使用说明、目录文件结构、常见问题说明、交流沟通方式等内容，以便关注者能快速地了解这个项目的基本情况和总体情况。在常见的代码托管平台如 Github、Gitee 上，项目仓库首页默认展示的内容就是这个 README 文件的内容，相当于整个项目的「主页」。 贡献说明（Contributing） @@ -14,24 +14,17 @@ 用户使用文档 （User Guide/ Getting Started） -对于开源项目来说，自身的功能与非功能特性固然重要，但如果使用体验不佳甚至很难上手，那么对用户来说门槛会变得很高，特别是对于有意向参与开发的用户来说，如果上手使用都不是很容易，那么参与开发的热情就会受到打击。因此，一份系统完整、条理清晰的用户使用文档，既能帮助普通用户快速上手使用，也能提升潜在开发人员的体验和好感度，进一步增强他们对该项目的兴趣和信心；而且通常开发人员都是从使用开始，发现 Bug，或者待改进的“痛点”，从而很自然地提出 Issue，并给出建议的解决方案。最后，这里的用户使用文档也可以是项目的技术文档（Document）或者教程（Mannuel）的一个重要入口，让对项目细节感兴趣的用户，可以进一步了解。 +对于开源项目来说，自身的功能与非功能特性固然重要，但如果使用体验不佳甚至很难上手，那么对用户来说门槛会变得很高，特别是对于有意向参与开发的用户来说，如果上手使用都不是很容易，那么参与开发的热情就会受到打击。因此，一份系统完整、条理清晰的用户使用文档，既能帮助普通用户快速上手使用，也能提升潜在开发人员的体验和好感度，进一步增强他们对该项目的兴趣和信心；而且通常开发人员都是从使用开始，发现 Bug，或者待改进的「痛点」，从而很自然地提出 Issue，并给出建议的解决方案。最后，这里的用户使用文档也可以是项目的技术文档（Document）或者教程（Mannuel）的一个重要入口，让对项目细节感兴趣的用户，可以进一步了解。 具体的开源项目推广方式比较多，宣传和更新维护都是一个漫长的过程，如果你不是明星账户，如 Google 或者 Twitter 或者 Gitee 上高 Star 项目作者，我们新人能做的只能是坚持。以下列举一些常见的方式。 -1、选择一个平台作为你博客的唯一主页。例如使用 WordPress 搭建自己的站点，但考虑到建站还需要购买服务器或者空间，国内建站需要备案等，你可以考虑使用 Gitee Pages 或者 Github Pages 来搭建属于自己的个人网站。 - -2、写作投稿。将你博客的文章推送到各大流量较高的社区，比如国内比较活跃的知乎问答社区、前端人员聚集的掘金社区，以及 Segmentfault 和博客园等。回答别人的问题时尽力做到用心和详细，回答字数不宜过少，最好图文并茂，语言风趣幽默效果更佳，但切记胡乱回答，尤其专业问题没经过自己验证和测试就凭主观猜想回答。另外，在文章中给出项目地址、说明参与方式，通过这些方式也能够较低成本地将对项目内容感兴趣的开发人员引流到项目社区中，并吸引志同道合的开发者加入项目开源计划。 - -3、迭代更新。可以借助开源中国，Segmentfault，博客园，V2EX 等社区进行更新推广，以及 QQ 群等内部维护的社交渠道版本发布。在社区推广更新版本信息，可以让未接触过该项目的人对项目本身有一个初步了解，可能就会吸引到新的使用者，对已经使用的用户也可以接收到一个版本迭代更新的进度以及内容。 - -4、建立微信群、 QQ 群、钉钉群、微博、公众号、TG 群/频道等沟通渠道，还可以在项目文档中引入 Gitter 这类即时通讯沟通软件方便快捷。通过社交工具，可以更精准及频繁的传递项目信息，建立与社区参与者更高的黏度，充分挖掘社区参与的活跃分子并且通过各种活动方式，让项目社区逐渐形成并壮大； - -5、参与或举办线上线下活动。开源推广跟其他产品或业务推广一样，需要通过不断的曝光、扩大影响范围等方式让项目覆盖更多受众，并且通过各种活动逐步培养项目的灵魂人物和大牛形象，从而吸引更多参与者； - -6、让社区参与者参与宣传。在社区里面，一般有开发者、使用者、项目核心成员等不同角色，我们可以通过各种活动充分利用社区中除项目发起人之外的其他成员的现身说法以及经验分享，一方面鼓励社区内部自由充分的交流，另外这也是对参与者开源精神的认可和赞赏，对于其他参与者也有积极的引导作用。 - -7、社区联合推广。可以尝试与其他社区互动，联合组织上文提到的各种线上或线下活动，以便相互促进。选择联合社区时，优先考虑与本项目在生态上的可集成性、互操作性、兼容性较强的项目社区，且不限于开源项目社区，也可以考虑本地化的知名或热门技术社区。总的原则是目标群体聚集的社区，一般都是比较好的潜在联合对象。 - +1. 选择一个平台作为你博客的唯一主页。例如使用 WordPress 搭建自己的站点，但考虑到建站还需要购买服务器或者空间，国内建站需要备案等，你可以考虑使用 Gitee Pages 或者 Github Pages 来搭建属于自己的个人网站。 +2. 写作投稿。将你博客的文章推送到各大流量较高的社区，比如国内比较活跃的知乎问答社区、前端人员聚集的掘金社区，以及 Segmentfault 和博客园等。回答别人的问题时尽力做到用心和详细，回答字数不宜过少，最好图文并茂，语言风趣幽默效果更佳，但切记胡乱回答，尤其专业问题没经过自己验证和测试就凭主观猜想回答。另外，在文章中给出项目地址、说明参与方式，通过这些方式也能够较低成本地将对项目内容感兴趣的开发人员引流到项目社区中，并吸引志同道合的开发者加入项目开源计划。 +3. 迭代更新。可以借助开源中国，Segmentfault，博客园，V2EX 等社区进行更新推广，以及 QQ 群等内部维护的社交渠道版本发布。在社区推广更新版本信息，可以让未接触过该项目的人对项目本身有一个初步了解，可能就会吸引到新的使用者，对已经使用的用户也可以接收到一个版本迭代更新的进度以及内容。 +4. 建立微信群、 QQ 群、钉钉群、微博、公众号、TG 群/频道等沟通渠道，还可以在项目文档中引入 Gitter 这类即时通讯沟通软件方便快捷。通过社交工具，可以更精准及频繁的传递项目信息，建立与社区参与者更高的黏度，充分挖掘社区参与的活跃分子并且通过各种活动方式，让项目社区逐渐形成并壮大； +5. 参与或举办线上线下活动。开源推广跟其他产品或业务推广一样，需要通过不断的曝光、扩大影响范围等方式让项目覆盖更多受众，并且通过各种活动逐步培养项目的灵魂人物和大牛形象，从而吸引更多参与者； +6. 让社区参与者参与宣传。在社区里面，一般有开发者、使用者、项目核心成员等不同角色，我们可以通过各种活动充分利用社区中除项目发起人之外的其他成员的现身说法以及经验分享，一方面鼓励社区内部自由充分的交流，另外这也是对参与者开源精神的认可和赞赏，对于其他参与者也有积极的引导作用。 +7. 社区联合推广。可以尝试与其他社区互动，联合组织上文提到的各种线上或线下活动，以便相互促进。选择联合社区时，优先考虑与本项目在生态上的可集成性、互操作性、兼容性较强的项目社区，且不限于开源项目社区，也可以考虑本地化的知名或热门技术社区。总的原则是目标群体聚集的社区，一般都是比较好的潜在联合对象。 ### 项目被提交 Issue 时应该怎么做？ @@ -39,23 +32,18 @@ 下面我们来探讨一下在不影响工作、生活的情况下如何有效率的持续迭代，如何将用户的提问引导到项目的 Issue 上来。因为： -1、你没有那么多精力去很多个平台回复问题。这一点与上一章节并不产生矛盾，项目宣传的时候可以去大流量平台做推广，但是当用户对项目有疑问或者 Bug 反馈时，尽量引导他们到项目的 Issue 上来。 - -2、你没有那么多时间天天盯着 QQ 群解答问题。刚开始入群的新人遇到问题会直接在群里艾特你，尤其是一些伸手党看都没看过别人是否提问过该问题，就想让你做他的客服。所以你不必理会，引导他们到你项目的 Issue 上来，这样久而久之用户就知道下一次遇到问题的时候先去你的项目提交 Issue。 - -3、问题应该被集中起来，供使用者反复查阅。 +1. 你没有那么多精力去很多个平台回复问题。这一点与上一章节并不产生矛盾，项目宣传的时候可以去大流量平台做推广，但是当用户对项目有疑问或者 Bug 反馈时，尽量引导他们到项目的 Issue 上来。 +2. 你没有那么多时间天天盯着 QQ 群解答问题。刚开始入群的新人遇到问题会直接在群里艾特你，尤其是一些伸手党看都没看过别人是否提问过该问题，就想让你做他的客服。所以你不必理会，引导他们到你项目的 Issue 上来，这样久而久之用户就知道下一次遇到问题的时候先去你的项目提交 Issue。 +3. 问题应该被集中起来，供使用者反复查阅。 当项目维护者看到有 Issue 提交时，最重要的是迅速反馈，无论是 Bug 还是需求，都可以跟提出者通过 Comment 方式进行充分的沟通，达成共识，也可以对 Issue 打上标签，便于分类管理。另外，还可以将 Issue 分配给其他参与者，或者将 Issue 添加到项目的看板，关联到某个里程碑等操作，当 Issue 中的问题被解决后，应该及时做关闭。 当用户量增多，Isssue 中会提到各种各样奇葩的需求，这时候就需要你判断该需求是否应该被添加，以下是可以几个可以参考的指标： -1、该 Isssue 是用户提出的 Bug,则应当给与解决。 - -2、Issue 是很多用户提过的需求，即大众需求。我们的产品只需要满足90%以上用户需求即可，我们不可能把产品做的面面俱到。当用户提出的是大众需求时，可以把该 Issue 纳入下一版本的更新。 - -3、你判断这个需求对大部分用户是否有用。 - -4、需求符合产品的定位以及未来发展方向，或者该需求能抹平和竞品的差距，或者能和竞品差异化竞争。 +1. 该 Isssue 是用户提出的 Bug,则应当给与解决。 +2. Issue 是很多用户提过的需求，即大众需求。我们的产品只需要满足90%以上用户需求即可，我们不可能把产品做的面面俱到。当用户提出的是大众需求时，可以把该 Issue 纳入下一版本的更新。 +3. 你判断这个需求对大部分用户是否有用。 +4. 需求符合产品的定位以及未来发展方向，或者该需求能抹平和竞品的差距，或者能和竞品差异化竞争。 符合上述条件的 Issue 可以纳入下一版本的升级计划，如果不符合可以予以拒绝。总之是围绕 Issue 能够展开积极互动和响应，这样才可以让社区始终保持活跃，形成一个良性循环。 diff --git "a/\347\254\2544\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\2544\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 34096cb1366c1c57551fb592d753330ed11f5ae5..3f80d34e84f4638046d35d5801222524276cf4be 100644 --- "a/\347\254\2544\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\2544\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" @@ -69,21 +69,17 @@ 一个好的 README 应该包含以下几点： -1）项目的名称和简介，基本上简短概括为主，说明你的项目主要用在哪些领域，能解决哪些问题。 - -2）项目的特性，也是以简洁的语言进行概括几点。 - -3）简单的快速开始用例，这部分旨在用最快的方式让别人通过用例了解你的项目。你项目中细节的说明和配置不应该放到这里。否则就会显得太冗长了。 - -4）个人不太建议把项目的文档写在 README 中，因为文档本身是项目使用的详细说明，会涵盖各个方面，放到 README 里面不太妥当，如果你有自己的文档页面，应当在 README 里面放一个超链进行跳转。当然如果你的项目非常的小，基本上一页纸就能说完的事情，放到 README 中也是可以的。 - -5）作者的介绍和联系方式（或者提供提 Issue 或者 Pull Requests 的方式等）。让别人碰到问题时能快速联系到你。 +1. 项目的名称和简介，基本上简短概括为主，说明你的项目主要用在哪些领域，能解决哪些问题。 +2. 项目的特性，也是以简洁的语言进行概括几点。 +3. 简单的快速开始用例，这部分旨在用最快的方式让别人通过用例了解你的项目。你项目中细节的说明和配置不应该放到这里。否则就会显得太冗长了。 +4. 个人不太建议把项目的文档写在 README 中，因为文档本身是项目使用的详细说明，会涵盖各个方面，放到 README 里面不太妥当，如果你有自己的文档页面，应当在 README 里面放一个超链进行跳转。当然如果你的项目非常的小，基本上一页纸就能说完的事情，放到 README 中也是可以的。 +5. 作者的介绍和联系方式（或者提供提 Issue 或者 Pull Requests 的方式等）。让别人碰到问题时能快速联系到你。 ## 建立严格的版本号规范 如果你想做成一个成熟规范的开源项目，那么版本号应当遵从开源项目的规范，对你的迭代也有帮助。 -版本号建议为 3 位数字，比如 `1.1.0`，`1.5.1` 这样，但是我们经常看到在版本号后面还有一些修饰词，比如`Alpha`、`Beta`、`Release` 等等，对于这部分的规范如下： +版本号建议为 3 位数字，比如 `1.1.0`，`1.5.1` 这样，但是我们经常看到在版本号后面还有一些修饰词，比如 `Alpha`、`Beta`、`Release` 等等，对于这部分的规范如下： - `Alpha`（如 `1.1.0-alpha`）：内部测试版本，Bug 可能比较多，一般用于开发人员内部使用 - `Beta`（如 `1.1.0-beta`）：用户测试版，Bug 相比 Alpha 少一点，但同样不建议用于生产环境，一般用于面向急于使用新功能的群众进行公测，并向开发人员进行反馈 @@ -114,15 +110,11 @@ 一份好的使用文档应当是能让用户和你的项目快速建立连接的，这里有一些写作文档的建议： -1）使用主动语态：尽可能使用“你可以这样更改配置”，而避免过多的使用“配置可以这样更改"，这样在阅读体验上会更加容易，反之就会显得你的文档比较拗口。 - -2）使用简洁明了的句子：写文档不是写小说，不是写诗歌，不需要用过多的修饰词，能让用户明白你想表达的意思即可。 - -3）保持条理性：你可以再文档中通过写标题，划重点，引链接等方式，把各类信息划分为不同的部分，避免将所有内容都揉在一大段冗长的文字当中。 - -4）提高可读性：除了文字之外，使用图标也是众多种角度表达的方式之一。 - -5）注意拼写和语法：必须检查文档中是否有词语的拼写错误和语法错误，尤其是程序的关键词语。 +1. 使用主动语态：尽可能使用「你可以这样更改配置」，而避免过多的使用「配置可以这样更改」，这样在阅读体验上会更加容易，反之就会显得你的文档比较拗口。 +2. 使用简洁明了的句子：写文档不是写小说，不是写诗歌，不需要用过多的修饰词，能让用户明白你想表达的意思即可。 +3. 保持条理性：你可以再文档中通过写标题，划重点，引链接等方式，把各类信息划分为不同的部分，避免将所有内容都揉在一大段冗长的文字当中。 +4. 提高可读性：除了文字之外，使用图标也是众多种角度表达的方式之一。 +5. 注意拼写和语法：必须检查文档中是否有词语的拼写错误和语法错误，尤其是程序的关键词语。 只要在文档的写作和编辑过程中应用到良好的技巧，你就能和读者建立起沟通和信任，读者会觉得你的项目很专业，印象上也会加分不少。 diff --git "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\344\270\252\344\272\272\347\273\264\346\212\244\345\222\214\345\273\272\347\253\213\347\244\276\345\214\272\357\274\214\344\270\244\350\200\205\345\246\202\344\275\225\351\200\211\346\213\251.md" "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\344\270\252\344\272\272\347\273\264\346\212\244\345\222\214\345\273\272\347\253\213\347\244\276\345\214\272\357\274\214\344\270\244\350\200\205\345\246\202\344\275\225\351\200\211\346\213\251.md" index ad2346deeddf52cbce160f14b16179648bce3eb1..16941d6e5ae8e9db180565cede451932f800e591 100644 --- "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\344\270\252\344\272\272\347\273\264\346\212\244\345\222\214\345\273\272\347\253\213\347\244\276\345\214\272\357\274\214\344\270\244\350\200\205\345\246\202\344\275\225\351\200\211\346\213\251.md" +++ "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\344\270\252\344\272\272\347\273\264\346\212\244\345\222\214\345\273\272\347\253\213\347\244\276\345\214\272\357\274\214\344\270\244\350\200\205\345\246\202\344\275\225\351\200\211\346\213\251.md" @@ -42,11 +42,10 @@ 尽管社区的组织形式不尽相同，但是一般都会有核心决策团体或者管理委员会来从技术和项目管理的角度履行管理者的权力。甚至有些社区组织结构非常接近于公司的产品开发，从而保证其协同效率。 - ## 个人维护 VS 建设社区 从上面的描述中可以看出，个人维护更加适合初期学习开源项目维护的朋友，积累沟通协作的经验，深入理解开源文化和开源世界。 对于小的项目而言，个人维护可以快速决策，减少沟通成本，进而提升效率。但是在项目推广上无法借助社区的优势，影响力提升较慢。 -作为个人开发者，可以从个人维护项目开始，借助开源平台认识结交一群志同道合的朋友，形成一个强有力的团队，进而建设社区。同时也可以选择加入一个开源社区一边贡献一边学习和了解开源，很多社区都是从小到大，逐渐演变成一个成熟的团队的。 \ No newline at end of file +作为个人开发者，可以从个人维护项目开始，借助开源平台认识结交一群志同道合的朋友，形成一个强有力的团队，进而建设社区。同时也可以选择加入一个开源社区一边贡献一边学习和了解开源，很多社区都是从小到大，逐渐演变成一个成熟的团队的。 diff --git "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\270\270\350\247\201\346\262\273\347\220\206\346\236\266\346\236\204.md" "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\270\270\350\247\201\346\262\273\347\220\206\346\236\266\346\236\204.md" index 311b9a32b09566ff3a97286366effaa789b1cc3f..663a88021a386e18c3bbc127773d589e7fc6097b 100644 --- "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\270\270\350\247\201\346\262\273\347\220\206\346\236\266\346\236\204.md" +++ "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\270\270\350\247\201\346\262\273\347\220\206\346\236\266\346\236\204.md" @@ -1,4 +1,3 @@ - ### 3 种常见的开源项目治理架构。 **BDFL:** BDFL 是英文「Benevolent Dictator For Life」的缩写。中文翻译为「仁慈的终身独裁者」。在此架构下，有一个人（通常是项目的最初的作者，或者是社区选举的一个人）拥有项目中所有最后的决定。较小的项目可能默认就是 BDFL 结构，因为此类项目一般就是一到两位维护者。若是公司组织的项目也极有可能会采用 BDFL 结构，以便掌握项目的决策权。 @@ -11,43 +10,37 @@ 应该选择哪一种模式了呢？每个模式都有优点，也有缺点。如果是非公司开源项目，可以在开始的时候简单定义基本的流程。例如，你可以将某些预期的行为定义清楚，贡献的流程是如何的，或者项目是如何启动的，等等。如果是公司开源的项目，在启动之前，应该做一些讨论，如公司将会如何维护项目，随着项目的发展，决策该如何定夺。可以公开的解释一下，开源之后，公司是否还继续参与贡献，还是完全由社区决定，等等。没有最优的答案，一切在于出自内心的选择。 - ### Node.js 的自由贡献规则 - 1.Node.js 核心库：Node.js 核心代码库在 https://github.com/nodejs/node。你可以尝试通过提 PR 与 Issue 的形式为核心代码库做贡献。 - - 2.Node.js 工作组：工作组与核心代码并非直接关联，而是专注在其周边的一些具体任务，比如站点工作组负责 Node.js 官网事宜，构建工作组负责 Node.js 在各个平台上的编译构建，Benchmark 工作组关注 Node.js 的性能相关问题。 - - 3.Node.js 生态圈：即使你对核心库与工作组的东西不感兴趣，也可以通过参与生态建设的方式做出贡献，例如参加 Node.js 的布道，出席社区聚会等等。 - +1. Node.js 核心库：Node.js 核心代码库在 。你可以尝试通过提 PR 与 Issue 的形式为核心代码库做贡献。 +2. Node.js 工作组：工作组与核心代码并非直接关联，而是专注在其周边的一些具体任务，比如站点工作组负责 Node.js 官网事宜，构建工作组负责 Node.js 在各个平台上的编译构建，Benchmark 工作组关注 Node.js 的性能相关问题。 +3. Node.js 生态圈：即使你对核心库与工作组的东西不感兴趣，也可以通过参与生态建设的方式做出贡献，例如参加 Node.js 的布道，出席社区聚会等等。 ### BDFL 治理模型 - #### 总览 + 1. 项目由仁慈的独裁者领导，并由社区管理。也就是说，社区积极地为项目的日常维护做出了贡献，但是仁慈的独裁者划定了总体战略方针。如有分歧，则保留最后决定权。解决社区内部的争端并确保项目能够以协调的方式进行，这是仁慈的独裁者的工作。反过来，通过积极的参与和贡献来指导仁慈的独裁者的决定是社区的工作。 - #### 角色 + 1. 仁慈的独裁者:仁慈的独裁者或项目负责人是自任命的。但是，由于社区始终具有分叉的能力，因此此人对社区完全负责。项目负责人的角色是一个困难的角色：他们确定了项目的战略目标，并将这些目标明确地传达给社区。他们还必须了解整个社区，并努力满足尽可能多的冲突需求，同时确保项目能够长期生存。 2. 提交者:提交者是对项目做出了一些宝贵贡献的贡献者，现在都依赖于将代码直接写到存储库中并筛选其他贡献者。通常，提交者将专注于项目的特定方面，并将带来一定程度的专业知识和理解，从而赢得社区和项目领导者的尊重。 3. 贡献者:任何人都可以成为贡献者。没有期望对项目的承诺，没有特定的技能要求，也没有选择过程。要成为贡献者，社区成员只需执行一项或多项对项目有益的行动。 - #### 社区治理方向 - 当项目的团队还比较小的时候，而且用户的社区也比较小，这时仁慈的独裁者会按照传统的自上而下的方式来做出所有的决策。然而，随着社区的增长，这会变得越来越困难，很少有人能够完全理解所要解决问题的所有细节，因此，他们可能会对在不怎么专业的领域所做出的决定不是太有把握。随着项目规模和范围的扩大，人们对于不能有十足把握的模块也会增长，那么作为项目的带头人，就无法做到面面俱到。基于如上原因，一个颇为高效率的独裁者会慢慢转变为协调者，或者叫做仲裁者，他们通常情况下，不会在辩论当中站队，Linux Torvalds曾经说过，“我宁愿看到的场面是有15个人为一个问题而争执的面红耳赤，而不愿意看到15个人分成两支队伍，每支队伍都只和自己观点相近的人说话。 - + 当项目的团队还比较小的时候，而且用户的社区也比较小，这时仁慈的独裁者会按照传统的自上而下的方式来做出所有的决策。然而，随着社区的增长，这会变得越来越困难，很少有人能够完全理解所要解决问题的所有细节，因此，他们可能会对在不怎么专业的领域所做出的决定不是太有把握。随着项目规模和范围的扩大，人们对于不能有十足把握的模块也会增长，那么作为项目的带头人，就无法做到面面俱到。基于如上原因，一个颇为高效率的独裁者会慢慢转变为协调者，或者叫做仲裁者，他们通常情况下，不会在辩论当中站队，Linux Torvalds曾经说过，“我宁愿看到的场面是有15个人为一个问题而争执的面红耳赤，而不愿意看到15个人分成两支队伍，每支队伍都只和自己观点相近的人说话。 ### 三种治理架构对应的模板，供参考： - ``` 需补充以下三种案例的模版或规则 ``` - - BDFL 模式模版 - 精英模式模版 - Node.js 的自由贡献规则 - ## 参考 - [1] [Benevolent Dictator Governance Model](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) diff --git "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\346\211\223\351\200\240\345\274\200\346\272\220\347\244\276\345\214\272.md" "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\346\211\223\351\200\240\345\274\200\346\272\220\347\244\276\345\214\272.md" index 791aefd78e616c2029a46dd5f04ab927785e2cc6..8284cfd43146cde0cd6756ec522ded1f4ffd78f4 100644 --- "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\346\211\223\351\200\240\345\274\200\346\272\220\347\244\276\345\214\272.md" +++ "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\346\211\223\351\200\240\345\274\200\346\272\220\347\244\276\345\214\272.md" @@ -2,13 +2,13 @@ > 如何为自己的项目打造开源社区？建立一个开源社区的前提是什么？如何将其发展壮大？ -`社区（community）`一词源于拉丁语，原意为亲密的关系或共同的东西。`社区`是一个抽象的概念，每个人眼中的社区可能都不一样，读者不妨先问一下自己——你眼中的社区是什么？从汉语的角度来看：`社区`由`社`和`区`两个字组成，前者指「相互有联系、有某些共同特征的人群」，后者指「一定的区域范围」。要想给`社区`下一个准确的定义是很难的，不过我们可以简单地将社区看作是「在某个环境中相互交往的群体」。维基百科中提到了社区的两个属性：「共同文化」和「共同地域」。当我们说「和平里社区」和「四方社区」时，我们侧重的是社区的「共同地域」属性；而当我们说「华人社区」和「开源社区」时，我们侧重的是「共同文化」属性。开源本身代表的就是一种文化。 +`社区（community）`一词源于拉丁语，原意为亲密的关系或共同的东西。`社区` 是一个抽象的概念，每个人眼中的社区可能都不一样，读者不妨先问一下自己——你眼中的社区是什么？从汉语的角度来看：`社区` 由 `社` 和 `区` 两个字组成，前者指「相互有联系、有某些共同特征的人群」，后者指「一定的区域范围」。要想给 `社区` 下一个准确的定义是很难的，不过我们可以简单地将社区看作是「在某个环境中相互交往的群体」。维基百科中提到了社区的两个属性：「共同文化」和「共同地域」。当我们说「和平里社区」和「四方社区」时，我们侧重的是社区的「共同地域」属性；而当我们说「华人社区」和「开源社区」时，我们侧重的是「共同文化」属性。开源本身代表的就是一种文化。 社区无处不在，社区的形式也多种多样。不过所有的社区几乎都有一个共同的特点，那就是：社区成员有着共同的信仰或者乐趣，他们对此充满热情，正是这种热情使得人们聚集在一起。**归属感（belonging）** 使人们驻留在社区，这种归属感也是社区建设的重要目标之一。一个强大社区的标志就是：社区成员都拥有归属感。 ## 什么是开源社区 -`开源社区（open source communities）`是社区的一种，它的核心在于**开源（open source）**（或者说是**开放（open）**）。前面我们说开源代表一种文化，我们也可以将开源看成是开源社区成员们的共同兴趣，或者信仰。读者不妨先想一想——什么是开放？就`open source`一词中的`open`来说，它既表示开源项目的源代码是开放的，任何人都可以获得以及修改它，也表示开源社区本身是开放的，任何人都可以加入社区，参与社区活动。更进一步，我们也可以说`开放社区（open communities）`，它的含义比开源社区更广，开放社区的核心在于**透明性（transparency）**、**包容性（inclusivity）**、**适应性（adaptability）**、**协作（collaboration）**和**社区（community）**。 +`开源社区（open source communities）`是社区的一种，它的核心在于 **开源（open source）**（或者说是 **开放（open）**）。前面我们说开源代表一种文化，我们也可以将开源看成是开源社区成员们的共同兴趣，或者信仰。读者不妨先想一想——什么是开放？就 `open source` 一词中的 `open` 来说，它既表示开源项目的源代码是开放的，任何人都可以获得以及修改它，也表示开源社区本身是开放的，任何人都可以加入社区，参与社区活动。更进一步，我们也可以说 `开放社区（open communities）`，它的含义比开源社区更广，开放社区的核心在于 **透明性（transparency）**、**包容性（inclusivity）**、**适应性（adaptability）**、**协作（collaboration）** 和 **社区（community）**。 现在全球已经形成了大量以技术为中心的开源社区。这些开源社区一般都依托于对应的开源项目，在开源项目的发展过程中逐渐形成，社区内聚集了一大批对该项目感兴趣的人，这些人参与开源项目的开发、文档编写、测试和社区讨论等活动。随着项目的发展，一些人可能会因为各种原因离开社区，反之，又可能会有新人不断地加入进来，社区会变得日新月异。 @@ -26,19 +26,19 @@ 1. 社区的使命是什么？ - **使命**能够激励社区成员、凝聚社区力量。使命也是社区成员共同的**信仰**。想一想社区渴望的最终结果是什么，或者说社区要达到怎样的目标？ + **使命** 能够激励社区成员、凝聚社区力量。使命也是社区成员共同的**信仰**。想一想社区渴望的最终结果是什么，或者说社区要达到怎样的目标？ 2. 社区能为参与者带来哪些机会？ - 参与者能从社区中获得的**机会**有哪些。更进一步说，如果社区实现了它的目标，它能带给参与者哪些可能。这个问题能够帮助社区寻找一个更深层次的终极目标，因为社区是离不开参与者的。 + 参与者能从社区中获得的 **机会** 有哪些。更进一步说，如果社区实现了它的目标，它能带给参与者哪些可能。这个问题能够帮助社区寻找一个更深层次的终极目标，因为社区是离不开参与者的。 3. 参与者在社区内可以一同做什么？ - 参与者可以在社区内**协同工作**的任务，例如编写文档、组织会议、进行宣传等等。如果参与者无事可做，这还是社区吗？ + 参与者可以在社区内 **协同工作** 的任务，例如编写文档、组织会议、进行宣传等等。如果参与者无事可做，这还是社区吗？ 4. 参与者需要具备哪些技能？ - 社区对参与者的**技能要求**，即参与者完成任务或实现目标所需要具备的能力。如果你能清晰明了地写出来，他可能会帮你吸引更多的参与者（通过这个，参与者能够清楚地知道自己可以做出哪些贡献）。 + 社区对参与者的 **技能要求**，即参与者完成任务或实现目标所需要具备的能力。如果你能清晰明了地写出来，他可能会帮你吸引更多的参与者（通过这个，参与者能够清楚地知道自己可以做出哪些贡献）。 5. 你期望的社区是怎样的？ @@ -52,7 +52,7 @@ 想要建立一个新社区，有很多准备工作要做，而其中最重要的两个任务：**组建一个早期的核心团队、建立良好的沟通渠道** -- “兵熊熊一个，将熊熊一窝”，一个高凝聚力的团队，是社区的“地基”，也决定了社区究竟能走多远。 +- 「兵熊熊一个，将熊熊一窝」，一个高凝聚力的团队，是社区的「地基」，也决定了社区究竟能走多远。 - 保持高效沟通，可以统一步调，决定了社区究竟能走多快。在这里列举常见的沟通渠道供大家选择：邮件列表、论坛、Slack、Telegram、QQ、微信等等。 @@ -79,7 +79,7 @@ 也就是说，**要对正确的人做宣传**。 -**选择宣传渠道 ** +**选择宣传渠道** 常规的推广方式无非两种，软广+硬广，即各平台的引流推广/付费广告推广。主要包括：公众号、社区群、平台付费推广。 @@ -87,14 +87,14 @@ - 包括自媒体公众号和官媒公众号 - 自媒体公众号就是个人创建的公众号，通过个人公众号来进行宣传。 - 优点在于公众号众多，通过个体传播方式扩散。 - - 官媒公众号就是官方媒体的公众号（比如Gitee），主要通过官媒影响力进行宣传。 + - 官媒公众号就是官方媒体的公众号（比如 Gitee），主要通过官媒影响力进行宣传。 - 优点是依托官方影响力，通过平台传播方式扩散。 - 社区群 - 社区群比较五花八门了，常见的开源项目一般都会有自己的社区群。 - 优点是借助社区影响力，通过平台传播方式扩散。 - 平台付费推广 - 不多做介绍了，找专业的人做专业的事。 - - 优点是专业平台提供宣传方案和落地方案，有钱就是可以“为所欲为”。 + - 优点是专业平台提供宣传方案和落地方案，有钱就是可以「为所欲为」。 在这里，贴个链接供大家参考：https://www.zhihu.com/question/343991769/answer/810943254 @@ -104,10 +104,10 @@ 下面为大家举例说明： -- 承诺**遵守社区规范**，积极参与社区建设，有**持之以恒的毅力** -- 掌握参与社区**必知必会的技能**（设计、研发、文档、宣传等），能够为社区提供技术支持 -- 有良好的**沟通问题**和**解决问题**的能力 -- 有良好的**自驱力**和学习能力 +- 承诺 **遵守社区规范**，积极参与社区建设，有 **持之以恒的毅力** +- 掌握参与社区 **必知必会的技能**（设计、研发、文档、宣传等），能够为社区提供技术支持 +- 有良好的 **沟通问题** 和 **解决问题** 的能力 +- 有良好的 **自驱力** 和学习能力 #### 引导参与者做出贡献 @@ -131,21 +131,21 @@ ### 社区健康 -林子大了，什么鸟都有。开放社区由一群性格迥异的人组成，他们职责不一、技能和经历也天差地别，这些差异加上社区的包容性就带来了社区的多样性。社区的多样性会触发各种各样的火花，有好的，也有坏的。作为社区的创建者，你需要了解的健康情况。对社区健康情况的了解可以从观察开始，例如：邮件列表活跃吗？有人报告缺陷时，开发人员能否迅速积极地做出响应？ 成员在回答问题时是否有礼貌且富有成效？ +林子大了，什么鸟都有。开放社区由一群性格迥异的人组成，他们职责不一、技能和经历也天差地别，这些差异加上社区的包容性就带来了社区的多样性。社区的多样性会触发各种各样的火花，有好的，也有坏的。作为社区的创建者，你需要了解的健康情况。对社区健康情况的了解可以从观察开始，例如：邮件列表活跃吗？有人报告缺陷时，开发人员能否迅速积极地做出响应？成员在回答问题时是否有礼貌且富有成效？ #### 如何观察和解决 -- 定期进行项目review +- 定期进行项目 Review - “子不孝，父之过”。项目就像一个婴儿一样，需要在成长中不断引导。一开始的想法往往并不成熟，想要孵化出一个优秀的开源项目，定期的项目review可以对项目发展方向及时纠偏，避免在成长中“误入歧途”。 + 「子不孝，父之过」。项目就像一个婴儿一样，需要在成长中不断引导。一开始的想法往往并不成熟，想要孵化出一个优秀的开源项目，定期的项目 Review 可以对项目发展方向及时纠偏，避免在成长中「误入歧途」。 -- 及时处理issues和PR +- 及时处理 Issues 和 PR - 项目的开源状态和问题缺陷的数量往往是成正比的，优秀的开源项目会喜提很多issues和PR。问题缺陷是往往是不可避免的，在项目孵化期间甚至是正式版本发布后，随着项目的成长，问题总会层出不穷，就算是赫赫有名的Douge Lee也逃脱不掉“八阿哥”的魔掌。有问题不可怕，可怕的是不能及时响应和解决。 + 项目的开源状态和问题缺陷的数量往往是成正比的，优秀的开源项目会喜提很多 Issues 和 PR。问题缺陷是往往是不可避免的，在项目孵化期间甚至是正式版本发布后，随着项目的成长，问题总会层出不穷，就算是赫赫有名的 Douge Lee 也逃脱不掉「八阿哥」的魔掌。有问题不可怕，可怕的是不能及时响应和解决。 试想一下，如果你聚集了大批志同道合的小伙伴去旅行，旅行途中抛锚了，如果不及时修好车子上路，小伙伴们是不是就只能被迫下车搭乘其他的车辆去了。因此，及时响应参与者提出的问题和优化建议，是非常重要的！ - 正所谓“偏听则暗，兼听则明”，我们会从这些源源不断的提议中发现并解决问题，甚至能够发现更多新鲜的idea，这些都是促进项目良性持续发展的重要法宝。 + 正所谓「偏听则暗，兼听则明」，我们会从这些源源不断的提议中发现并解决问题，甚至能够发现更多新鲜的 Idea，这些都是促进项目良性持续发展的重要法宝。 - 了解行业最新动态 @@ -168,11 +168,11 @@ - 指定城市负责人 - 参与人数较少时，可由核心参与者担任 - 参与人数较多时，可选择有经验的参与者担任 -- 定期举办meetup等活动 +- 定期举办 Meetup 等活动 ### 社区治理 -想必大家都不会对`治理`这个词感到陌生，治理是一个庞大而复杂的话题。例如，国家政府以改善基础设施、提升国民生活水平为己任。那么，社区也需要治理吗？答案并不是绝对的。如果你的社区只有 5 个人，可能真没有治理的必要。但是，如果你的社区规模达到了 500 人，你就需要好好考虑一下了。 +想必大家都不会对 `治理` 这个词感到陌生，治理是一个庞大而复杂的话题。例如，国家政府以改善基础设施、提升国民生活水平为己任。那么，社区也需要治理吗？答案并不是绝对的。如果你的社区只有 5 个人，可能真没有治理的必要。但是，如果你的社区规模达到了 500 人，你就需要好好考虑一下了。 #### 治理模式 @@ -182,7 +182,7 @@ 2. 开明专制：没有正式的领导者，唯才是用。比如 KDE 社区。 3. 委托式管理：社区的治理权被委派给一个治理机构。这种方式开放、透明，非常有利于社区的健康发展。比如 Ubuntu 社区。 -治理的首要职责是**解决冲突**，目标是带来社区的祥和。随着社区规模的扩大，人们的观点会出现分歧，分歧可能变成争论，并发展成派系斗争。这将是一个非常严重的问题。冲突会损害社区健康，将社区变成一个不舒适的环境，影响社区成员的感受。值得一提的是，虽然冲突容易引起不适，但它也有好的一面。冲突能够帮助社区管理者发现社区内的多样性、社区成员的激情，以及社区的活跃程度。 +治理的首要职责是 **解决冲突**，目标是带来社区的祥和。随着社区规模的扩大，人们的观点会出现分歧，分歧可能变成争论，并发展成派系斗争。这将是一个非常严重的问题。冲突会损害社区健康，将社区变成一个不舒适的环境，影响社区成员的感受。值得一提的是，虽然冲突容易引起不适，但它也有好的一面。冲突能够帮助社区管理者发现社区内的多样性、社区成员的激情，以及社区的活跃程度。 ## 参考资料 diff --git "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\347\241\256\344\277\235\345\274\200\346\272\220\344\273\243\347\240\201\350\264\250\351\207\217\347\232\204\345\207\240\344\270\252\350\246\201\347\202\271.md" "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\347\241\256\344\277\235\345\274\200\346\272\220\344\273\243\347\240\201\350\264\250\351\207\217\347\232\204\345\207\240\344\270\252\350\246\201\347\202\271.md" index 86f39a271f4233337814c180a50d93a915e63f62..10869e9f5094989c06d470b03cb6204e4fe975d6 100644 --- "a/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\347\241\256\344\277\235\345\274\200\346\272\220\344\273\243\347\240\201\350\264\250\351\207\217\347\232\204\345\207\240\344\270\252\350\246\201\347\202\271.md" +++ "b/\347\254\2545\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\347\241\256\344\277\235\345\274\200\346\272\220\344\273\243\347\240\201\350\264\250\351\207\217\347\232\204\345\207\240\344\270\252\350\246\201\347\202\271.md" @@ -6,7 +6,7 @@ 2014 年 4 月，OpenSSL 向外界公布 OpenSSL 的实现上，存在 Heartbleed 漏洞隐患，截止 2014 年 5 月 20 日，在 80 万最热门的启用 TLS 的网站中，仍有 1.5％ 易受心脏出血漏洞的攻击。如果说 Heartbleed 带来了什么好处，那就是它让人们更加关注软件测试的重要性。它影响了 50 多万个网站。因此，专家们现在正在梳理 OpenSSL 的代码，以及许多其他开源项目的代码，以确保提高公开源代码的质量和安全性。 -基于贡献代码构建的事实是，没有任何一个开源项目是完全不可破解的。正如世界上没有“银弹”一样，开源社区也没有完美的开源代码。我们要能够容忍开源代码有缺陷，但容忍不代表对其放任自由，不做约束。低质量的开源代码是放在路边的“潘多拉魔盒”，会对开源代码的众多追随者造成巨大的影响！因此，我们需要通过一系列的措施，确保开源代码质量。 +基于贡献代码构建的事实是，没有任何一个开源项目是完全不可破解的。正如世界上没有「银弹」一样，开源社区也没有完美的开源代码。我们要能够容忍开源代码有缺陷，但容忍不代表对其放任自由，不做约束。低质量的开源代码是放在路边的「潘多拉魔盒」，会对开源代码的众多追随者造成巨大的影响！因此，我们需要通过一系列的措施，确保开源代码质量。 ## 质量衡量标准 @@ -16,16 +16,11 @@ 软件质量的主要衡量标准如下（想要获得更多信息，请参考资料）： -- 功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力 - +- 功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能 - 可靠性：在指定条件使用时，软件产品维护规定的性能级别的能力 - - 易用性：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力 - - 效率性：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力 - - 维护性：软件产品可被修改的能力。包括纠正、改进或对环境、需求和功能规格说明变化的适应 - - 移植性：软件产品从一种环境迁移到另外一种环境的能力 ## 管理周期与内容 @@ -48,7 +43,7 @@ ## 管理方式与方法 -开源项目的管理方式和方法，用一个词来形容，那就是“百家争鸣”。因为每个项目所处的阶段不同，管理重点不同，甚至是成员性格不同，所以也就出现了各式各样的方式和方法。没有最好的管理方式，只有最适合的管理方式。 +开源项目的管理方式和方法，用一个词来形容，那就是「百家争鸣」。因为每个项目所处的阶段不同，管理重点不同，甚至是成员性格不同，所以也就出现了各式各样的方式和方法。没有最好的管理方式，只有最适合的管理方式。 在管理周期和内容中，其实已经涉及一部分管理方式和方法。这里，我们列举多个维度的方式方法供大家参考。 @@ -63,12 +58,12 @@ - 口述的内容要落实到纸面上，用来指导项目迭代，可作为后期项目复盘的依据，也有助于降低人员变动带来的风险 - 制定代码规范 - 适用于开发阶段，统一编码规范 - - 大部分开源项目都会提供编码规范，包括编码规范、日志规范、注释规范、数据库规范等等。比如：提供不同IDE的开发规范配置文件“***.xml”，又或者安装开发规范插件……等等 -- 代码review + - 大部分开源项目都会提供编码规范，包括编码规范、日志规范、注释规范、数据库规范等等。比如：提供不同 IDE 的开发规范配置文件「***.xml」，又或者安装开发规范插件……等等 +- 代码 Review - 适用于开发阶段，对照软件质量衡量标准进行完善项目 - 合理利用工具 - 适用于所有阶段，巧用工具提升效率 - - 比如：使用JIRA进行项目管理，使用Axure绘制原型，使用Word编写文档，使用GitHub 平台进行代码开发，使用Selenium进行功能测试，使用FindBugs 在 Java 查找缺陷，使用Clang 静态分析器分析C、C++ 和 Objective-C 程序中的错误。 + - 比如：使用 JIRA 进行项目管理，使用 Axure 绘制原型，使用 Word 编写文档，使用 GitHub 平台进行代码开发，使用 Selenium 进行功能测试，使用 FindBugs 在 Java 查找缺陷，使用 Clang 静态分析器分析 C、C++ 和 Objective-C 程序中的错误。 - 其他方式 - 引入人才 - 适用于所有阶段，借助组织的力量提升项目 @@ -80,6 +75,4 @@ ## 参考资料 - [做软件质量管理需要方面的知识，度量要如何开展？](https://www.zhihu.com/question/20825147) - - [质量特性及子特性：功能性、可靠性、易用性、效率、维护性、可移植性](http://www.cnitpm.com/pm/6274.html) - diff --git "a/\347\254\2546\351\203\250\345\210\206\342\200\224\342\200\224\345\205\266\344\273\226\351\227\256\351\242\230/\345\205\263\344\272\216\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\225\206\344\270\232\345\214\226.md" "b/\347\254\2546\351\203\250\345\210\206\342\200\224\342\200\224\345\205\266\344\273\226\351\227\256\351\242\230/\345\205\263\344\272\216\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\225\206\344\270\232\345\214\226.md" index f8919bc1edf843fcc9b5f385790ba8063b565742..036b4573bf85c63ca7c36a8c4a8b62d52b6f7af5 100644 --- "a/\347\254\2546\351\203\250\345\210\206\342\200\224\342\200\224\345\205\266\344\273\226\351\227\256\351\242\230/\345\205\263\344\272\216\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\225\206\344\270\232\345\214\226.md" +++ "b/\347\254\2546\351\203\250\345\210\206\342\200\224\342\200\224\345\205\266\344\273\226\351\227\256\351\242\230/\345\205\263\344\272\216\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\225\206\344\270\232\345\214\226.md" @@ -16,7 +16,6 @@ 疑问来了，不是说好的开源吗？怎么又冒出来个协议？难道我都获得了源代码了还不能用于我的项目之上吗？作者还要收费不成？没错是有这么个协议存在，而且具有一定的约束能力。我们所理解的开源和实际的开源还是存在一点点的差别，所以必须把开源协议拿出来修饰一下这个话题。 - > 开源许可协议：开源许可协议是指开源社区为了维护作者和贡献者的合法权利，保证软件不被一些商业机构或个人窃取，影响软件的发展而开发的协议。（来源：[百度百科](http://https://baike.baidu.com/item/%E5%BC%80%E6%BA%90%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE/2470967?fr=aladdin)） 不同的开源协议有着不同的开源约束能力，是为了保障开源项目的可持续性发展，只要我们在约束条件内，可以自由发挥，并非完全不能使用开源项目，使用者可以最大程度去复制、分发、盈利、修改、发行。 @@ -29,16 +28,12 @@ 开源和商业化并不冲突，而是相互共存、互补、突现。 - - ### 商业化的开源项目特征 - ``` 本段内容可进行修改补充 ``` - 互联网高速发展的时代，让开源项目变成了可能，很多开源项目已经实现了价值。开源是每一个个体和组织都可以贡献的一种资源，数据表明近年来中国的开源贡献以每年 37% 的速度在增长。 尽管国家也高度重视开源精神、鼓励开源生态的发展，但是当下国内开源生态并不是很乐观，还有很大的发展空间。我们需要去创新、去发现、去贡献，每个开源贡献者即便是微乎其微的努力也在影响着开源生态发展，让国内开源生态更加完善。 @@ -74,49 +69,50 @@ 部分成功的商业化开源项目 - ``` 需补充商业化前的背景，商业化后的发展情况。 ``` +- Red Hat + + Red Hat Enterprise Linux 是 Red Hat 公司的 Linux 发行版，面向商业市场，包括大型机。 + +- MySQL -> Red Hat + MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，属于 Oracle 旗下产品。 -Red Hat Enterprise Linux 是 Red Hat 公司的 Linux 发行版，面向商业市场，包括大型机。 +- MariaDB -> MySQL + MariaDB 数据库管理系统是 MySQL 的一个分支，主要由开源社区在维护，采用 GPL 授权许可。MariaDB 的目的是完全兼容 MySQL，包括 API 和命令行，使之能轻松成为 MySQL 的代替品。 -MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，属于 Oracle 旗下产品。 +- OceanBase 蚂蚁金服数据库 -> MariaDB + OceanBase 是由蚂蚁集团完全自主研发的金融级分布式关系数据库，始创于 2010 年。OceanBase 具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准和主流关系数据库、低成本等特点。 -MariaDB 数据库管理系统是 MySQL 的一个分支，主要由开源社区在维护，采用 GPL 授权许可。MariaDB 的目的是完全兼容 MySQL，包括 API 和命令行，使之能轻松成为 MySQL 的代替品。 +- React -> OceanBase 蚂蚁金服数据库 + 用于构建用户界面的 JavaScript 库 -OceanBase 是由蚂蚁集团完全自主研发的金融级分布式关系数据库，始创于 2010 年。OceanBase 具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准和主流关系数据库、低成本等特点。 +- Vue -> React + **起源** -用于构建用户界面的 JavaScript 库 + Vue 起源与尤雨溪在 Google 工作时的一个想法有关，当年尤雨溪在 Google 工作时需要在浏览器上进行大量原型设计，因为大量设计这些东西太过繁琐，于是他想要尽快获得有形的东西，恰巧当时公司有些项目在使用 Angular，这给了他一个借鉴的想法，Angular 提供了一些用数据绑定和数据驱动来处理 DOM 的方法，不必自己去碰 DOM。但它也有一些副作用，就是需要按照它规定的方式来构建代码。这对于当时的场景而言实在是太过于笨重了。于是尤雨溪就把自己喜欢的部分从 Angular 中提出来，建立一个非常轻巧的库，去除掉了那些额外的逻辑，这便是最开始的 Vue。 -> Vue + **发展阶段** -- #### 起源 -Vue 起源与尤雨溪在 Google 工作时的一个想法有关，当年尤雨溪在 Google 工作时需要在浏览器上进行大量原型设计，因为大量设计这些东西太过繁琐，于是他想要尽快获得有形的东西，恰巧当时公司有些项目在使用 Angular，这给了他一个借鉴的想法，Angular 提供了一些用数据绑定和数据驱动来处理 DOM 的方法，不必自己去碰 DOM。但它也有一些副作用，就是需要按照它规定的方式来构建代码。这对于当时的场景而言实在是太过于笨重了。于是尤雨溪就把自己喜欢的部分从 Angular 中提出来，建立一个非常轻巧的库，去除掉了那些额外的逻辑，这便是最开始的 Vue。 -- #### 发展阶段 -尤雨溪在使用了一段时间后，觉得自己这个项目还有点前途，于是花费了一段时间对这个项目进行了封装，并取名为 Vue.js。`花了这么多时间，不能只有我一个人用，我应该和别人分享，他们也会感觉到 Vue 的好处，他们也会喜欢上 Vue 的。`秉承着这种想法，在封装完成后尤雨溪便将迅速将 Vue 发布到了 Github 上面，并把链接发送到了 Hacker News 上。没过多久 Vue 便被顶上了首页，并在首页保留了好几个小时，这也是 Vue 第一次面向大众。这时的 Vue 还刚初出茅庐，没什么名气，真正让 Vue 普及起来还得归功于，2014年 Taylor otwell（一个非常热门的 php 框架 laravel 的作者）第一次在 Twitter 上发表了关于 Vue.js 的推文，内容大概是学习 React 很难，现在我正在学习 Vue.js，因为这看起来比较简单。也就是这条推文，让 Vue.js 这个框架得到了认可，所有 laravel 用户觉得：wow，Taylor is liking Vue.js ，it must be a good tool，we should try it，于是就开始有了很多从 laravel 社区来的用户。Vue 因此收获了一大波用户，为 Vue 的繁荣打下了结实的基础。 + 尤雨溪在使用了一段时间后，觉得自己这个项目还有点前途，于是花费了一段时间对这个项目进行了封装，并取名为 Vue.js。`花了这么多时间，不能只有我一个人用，我应该和别人分享，他们也会感觉到 Vue 的好处，他们也会喜欢上 Vue 的。`秉承着这种想法，在封装完成后尤雨溪便将迅速将 Vue 发布到了 Github 上面，并把链接发送到了 Hacker News 上。没过多久 Vue 便被顶上了首页，并在首页保留了好几个小时，这也是 Vue 第一次面向大众。这时的 Vue 还刚初出茅庐，没什么名气，真正让 Vue 普及起来还得归功于，2014年 Taylor otwell（一个非常热门的 PHP 框架 Laravel 的作者）第一次在 Twitter 上发表了关于 Vue.js 的推文，内容大概是学习 React 很难，现在我正在学习 Vue.js，因为这看起来比较简单。也就是这条推文，让 Vue.js 这个框架得到了认可，所有 Laravel 用户觉得：Wow，Taylor is liking Vue.js，it must be a good tool，we should try it，于是就开始有了很多从 Laravel 社区来的用户。Vue 因此收获了一大波用户，为 Vue 的繁荣打下了结实的基础。 -- #### 从开源中变现 -`我为开发者们创造了价值，所以从理论上说，如果我能以某种方式得到接近于这些价值的钱，那么我应该能够养活自己。`Vue 的用户群非常有活力。许多来自 Laravel 社区的 Vue 用户，他们非常热情真诚，也非常的友好。这让尤雨溪感觉众筹可能是个不错的想法。于是不久后尤雨溪便在 Patreon 上挂出了众筹页面。为了众筹尤雨溪还在 Patreon 众筹上加了一个附加奖励。如果有公司愿意赞助他，那么他可以把公司的标志放在 vuejs.org 的赞助商页面上，就相当于在社区给公司打了广告。Patreon 众筹得到的金额里有一半是来自个人的，其中还有一个人每月赞助他 2000 美元以支持他开发Vue。据尤雨溪本人透露，自己在家中全职开发 VUE 的初期，每月就能从众筹网站上获得至少 1 万美元的资助。尤雨溪就这样凭借自身能力依靠 Vue 项目的变现实现了自身的财务自由。 -> antd + **从开源中变现** -antd 是基于 Ant Design 设计体系的 React UI 组件库，主要用于研发企业级中后台产品。 + `我为开发者们创造了价值，所以从理论上说，如果我能以某种方式得到接近于这些价值的钱，那么我应该能够养活自己。`Vue 的用户群非常有活力。许多来自 Laravel 社区的 Vue 用户，他们非常热情真诚，也非常的友好。这让尤雨溪感觉众筹可能是个不错的想法。于是不久后尤雨溪便在 Patreon 上挂出了众筹页面。为了众筹尤雨溪还在 Patreon 众筹上加了一个附加奖励。如果有公司愿意赞助他，那么他可以把公司的标志放在 vuejs.org 的赞助商页面上，就相当于在社区给公司打了广告。Patreon 众筹得到的金额里有一半是来自个人的，其中还有一个人每月赞助他 2000 美元以支持他开发 Vue。据尤雨溪本人透露，自己在家中全职开发 Vue 的初期，每月就能从众筹网站上获得至少 1 万美元的资助。尤雨溪就这样凭借自身能力依靠 Vue 项目的变现实现了自身的财务自由。 -> Unreal Engine 4 +- antd -大名鼎鼎的虚幻 4 游戏引擎。拥有独创的蓝图系统，降低了游戏开发门槛。渲染效果逼真，甚至被大量用于电影和 CG 渲染。虚幻商场提供了大量预设资源，降低了游戏开发成本。且虚幻引擎本身的使用是完全免费的，在发行产品（使用虚幻 4 引擎制作的包括但不限于游戏的商业发行产品）开始商业化运营，且总营收超过 1000000 美金后才开始支付 5% 的分成费用，使独立游戏开发者能够投入更多精力到游戏开发之中，而不必担心引擎授权费问题。正是由于这些优点，使虚幻 4 成为了最为著名和使用最为广泛的游戏引擎之一。 + antd 是基于 Ant Design 设计体系的 React UI 组件库，主要用于研发企业级中后台产品。 +- Unreal Engine 4 + 大名鼎鼎的虚幻 4 游戏引擎。拥有独创的蓝图系统，降低了游戏开发门槛。渲染效果逼真，甚至被大量用于电影和 CG 渲染。虚幻商场提供了大量预设资源，降低了游戏开发成本。且虚幻引擎本身的使用是完全免费的，在发行产品（使用虚幻 4 引擎制作的包括但不限于游戏的商业发行产品）开始商业化运营，且总营收超过 1000000 美金后才开始支付 5% 的分成费用，使独立游戏开发者能够投入更多精力到游戏开发之中，而不必担心引擎授权费问题。正是由于这些优点，使虚幻 4 成为了最为著名和使用最为广泛的游戏引擎之一。 -还有很多很多开源项目走向了商业化…… \ No newline at end of file +还有很多很多开源项目走向了商业化…… diff --git "a/\347\254\2546\351\203\250\345\210\206\342\200\224\342\200\224\345\205\266\344\273\226\351\227\256\351\242\230/\346\200\216\346\240\267\345\234\250\346\234\254\350\201\214\345\267\245\344\275\234\345\222\214\345\274\200\346\272\220\351\241\271\347\233\256\351\227\264\345\201\232\345\245\275\345\271\263\350\241\241.md" "b/\347\254\2546\351\203\250\345\210\206\342\200\224\342\200\224\345\205\266\344\273\226\351\227\256\351\242\230/\346\200\216\346\240\267\345\234\250\346\234\254\350\201\214\345\267\245\344\275\234\345\222\214\345\274\200\346\272\220\351\241\271\347\233\256\351\227\264\345\201\232\345\245\275\345\271\263\350\241\241.md" index ebeb85c36a1284e4aa65df328c4951f0582f44a4..814ae2593c7365b842cfe50b6ac5d8a7abe1e470 100644 --- "a/\347\254\2546\351\203\250\345\210\206\342\200\224\342\200\224\345\205\266\344\273\226\351\227\256\351\242\230/\346\200\216\346\240\267\345\234\250\346\234\254\350\201\214\345\267\245\344\275\234\345\222\214\345\274\200\346\272\220\351\241\271\347\233\256\351\227\264\345\201\232\345\245\275\345\271\263\350\241\241.md" +++ "b/\347\254\2546\351\203\250\345\210\206\342\200\224\342\200\224\345\205\266\344\273\226\351\227\256\351\242\230/\346\200\216\346\240\267\345\234\250\346\234\254\350\201\214\345\267\245\344\275\234\345\222\214\345\274\200\346\272\220\351\241\271\347\233\256\351\227\264\345\201\232\345\245\275\345\271\263\350\241\241.md" @@ -4,8 +4,6 @@ 友情提示，本文主要针对那些个人开发者，不针对那些以开源计算 KPI 的企业或者企业员工或全职开源者。 - - 开源不是工作，开源更多的是一种对自我能力、自我影响力或自我约束力的升华。在写这篇文章之前，我专门向多位开源圈的大佬请教过这个问题，大佬们给我的答案大部门意思都一样，总结一下就是：**学会规划自己的时间，要明确工作是工作，开源是开源，开源一定是牺牲自己的业余时间去做的**。 ## 工作能带给我们什么？ @@ -17,21 +15,19 @@ 3. 心理上：投入感、自我肯定、被信赖感、支配感等 ## 开源能带给我们什么？ + 1. 在这你可以找到一群志同道合的朋友，一起分享编写编码的乐趣，找到属于自己的共同点。 2. 你可以在开源项目中磨砺自身，提升自身的沟通能力，与代码编写技巧。更能丰富你的阅历，让你知道如何作为团队的一部分，和其他人一起协作开发一个项目。而且由于代码公开，这些项目可以作为你技能熟练度的佐证，有助于自身建立个人品牌。 3. 开源可以让你站在其他人的视角上面看待一个问题，人无完人，一个人的思维总归还是会有一定的局限性。对于一个技术难点我们不必死缠烂打，不妨看看别人的代码，拓宽自己的思路，打破自身思维所带来的局限性，取人之长，补己之短。 个人能力锻炼和提升： - 1. 专业技术能力； 2. 架构设计和模块化思维能力； 3. 团队精神和协作能力； 4. 文档习惯和写作能力； 5. 需求理解能力； - - 精神生活丰富有趣味： 1. 参与大型团队，比肩业内大佬； @@ -40,8 +36,7 @@ 4. 偶有项目奖励，内心喜不自禁； 5. 个性创新不断，行业视角更广； - -关于这部分详细内容，请参考[开源与个人技术成长](../第1部分——初识开源/开源与个人技术成长.md)、[个人为什么要参与开源贡献](../第3部分——尝试参与开源/个人为什么要参与开源贡献.md) +关于这部分详细内容，请参考 [开源与个人技术成长](../第1部分——初识开源/开源与个人技术成长.md)、[个人为什么要参与开源贡献](../第3部分——尝试参与开源/个人为什么要参与开源贡献.md) - 提升专业技术能力 - 提升个人成就感和自信 @@ -49,14 +44,13 @@ - 丰富阅历、拓宽知识面 - 结识更多领域的专家 - ## 亲身经历 在这儿，我不妨先给大家分享一些我的亲身经历： 以往我在面试开发者时必问的一点就是：你做没做过开源？如果面试者回答做过，我会继续问他为什么要做开源？开源能带给你什么？可悲的是大部分（几乎可以说全部）开发者一致的回答是：一直想做但平常没有时间做。 -由此可见一斑，大部分人对于开源的态度都是“我工作忙，没有时间”，试问你真的是没有时间吗？容我斗胆猜测目前国内开发者的状态： +由此可见一斑，大部分人对于开源的态度都是「我工作忙，没有时间」，试问你真的是没有时间吗？容我斗胆猜测目前国内开发者的状态： 1. 965，工作轻松有，还能结伴撮顿酒。 2. 996，工作累成狗，回家倒床就一宿。 @@ -69,7 +63,7 @@ 在工作的时候，你真的是在认真工作吗？是真的全身心的投入到工作中了吗？ - 你是否还记得早上一个小时喝茶上厕所的时候？ -- 你是否还记得在各个群里吹天砍地、斗图“蹦迪”的时候？ +- 你是否还记得在各个群里吹天砍地、斗图「蹦迪」的时候？ - 你是否还记得你在工位上追着没追完的剧的时候？ - 你是否还记得…… @@ -84,7 +78,7 @@ 我想你也可能是选择性的忘记了。 -希望经过上面的“反省”，各位开发者能对自己的实际情况有一个比较客观的认识。 +希望经过上面的「反省」，各位开发者能对自己的实际情况有一个比较客观的认识。 ## 怎么办？ @@ -98,7 +92,7 @@ OK，言归正传，书接上文。我们应该怎么办？应该怎么做到两 这个道理很简单，我们越高效的完成工作，那么留给我们的空余时间就会越多，我们就可以利用这些空余时间去学习新技术提高自己的能力或者参与开源项目（诶，你这糟老头子，说了满篇废话，终于点到题上了）。 -友情提示：有些公司明令禁止不得在工作时间利用公司资源搞其他的东西。这个范围是很宽泛的，既包括兼职又包括开源（开源可以理解成一个短期或者基本无收入的“兼职”）。这一点不在本文的讨论范围内，不做过多解释。 +友情提示：有些公司明令禁止不得在工作时间利用公司资源搞其他的东西。这个范围是很宽泛的，既包括兼职又包括开源（开源可以理解成一个短期或者基本无收入的「兼职」）。这一点不在本文的讨论范围内，不做过多解释。 ### 提高自控力 @@ -128,13 +122,13 @@ OK，言归正传，书接上文。我们应该怎么办？应该怎么做到两 首先，我们应该从自身能力出发。 -- 如果你是**未参加工作的学生**，建议你**以学习内容为轴心**，丰富的理论知识可以让你在相关项目的实践上大展拳脚。 -- 如果你是**其他行业的人士**，请**确定自己感兴趣的方向**，掌握必知必会的技能，开源指日可待。 -- 如果你是一个**初次参与开源**的“新手玩家”，熟悉的领域比较少，建议你从**工作相关的内容**入手，可以更好地开启你的开源之路。 +- 如果你是 **未参加工作的学生**，建议你 **以学习内容为轴心**，丰富的理论知识可以让你在相关项目的实践上大展拳脚。 +- 如果你是 **其他行业的人士**，请 **确定自己感兴趣的方向**，掌握必知必会的技能，开源指日可待。 +- 如果你是一个 **初次参与开源** 的「新手玩家」，熟悉的领域比较少，建议你从 **工作相关的内容** 入手，可以更好地开启你的开源之路。 -- 如果你是一个有**丰富经验的开发者**，但各个领域并不精通，请尝试从**自身技术栈**出发，解锁开源的第一步。 +- 如果你是一个有 **丰富经验的开发者**，但各个领域并不精通，请尝试从 **自身技术栈** 出发，解锁开源的第一步。 -- 如果你是一个开源界的“老炮”，知识面广泛且深入，相信你已经不需要再依据这篇文章来进行开源的抉择了，欢迎你更积极地“发光发热”，帮助更多的人晋升为“老炮”。 +- 如果你是一个开源界的「老炮」，知识面广泛且深入，相信你已经不需要再依据这篇文章来进行开源的抉择了，欢迎你更积极地「发光发热」，帮助更多的人晋升为「老炮」。 其次，可以从自身需求出发。 @@ -153,10 +147,6 @@ OK，言归正传，书接上文。我们应该怎么办？应该怎么做到两 2. 提高自控力 3. 必要的牺牲 - ## 结语 这篇文章是我在工作之外，利用自己的业余时间，前前后后构思了好久才写完的。内容可能不尽人意，各位看官暂且一阅，欢迎指正欢迎交流。 - - -