From 3947ad2598bd679b0e37e5204f0e465a15d10e04 Mon Sep 17 00:00:00 2001 From: Yufan You Date: Mon, 15 Feb 2021 17:09:36 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E6=AD=A3=E6=9D=82=E4=B9=B1=E7=9A=84?= =?UTF-8?q?=E7=A9=BA=E7=99=BD=E5=AD=97=E7=AC=A6?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 在 Linux 下运行这个命令得到这个 commit: dos2unix ./**/*.md && perl -i -p0e 's/^\s+$//g;s/\n{3,}/\n\n/g;s/ {3,}$/ /g;s/\s+\n\n/\n\n/g' ./**/*.md 这个命令完成了以下几个步骤： 1. 将 CRLF 转换为 LF 2. 将只有空白字符的行转换为空行 3. 将两个及以上的连续空行转换为一个空行 4. 将行末多于两个的空格转换为两个空格（行末连续两个空格在 Markdown 中表示
，即不带空白的换行） 5. 将下面一行是空行的行末空白字符删除，这样的行末空白字符没有用 --- README.md | 82 ++-- Revision-activities.md | 84 ++-- ...20\347\232\204\344\270\226\347\225\214.md" | 67 ++- ...00\346\272\220\346\214\207\345\214\227.md" | 166 ++++---- ...45\272\246\344\271\213DolphinScheduler.md" | 112 +++-- ...64\241\347\214\256 @types \345\214\205.md" | 184 ++++---- ...00\346\272\220\345\216\206\347\250\213.md" | 10 +- ...70\344\270\215\350\244\252\350\211\262.md" | 160 +++---- ...25\347\250\277\350\257\264\346\230\216.md" | 42 +- ...AP\347\232\204\346\225\205\344\272\213.md" | 48 +-- ...10\347\232\204\346\225\205\344\272\213.md" | 10 +- ...27\347\232\204\346\225\205\344\272\213.md" | 304 ++++++------- "\347\233\256\345\275\225.md" | 95 ++--- ...10\346\230\257\345\274\200\346\272\220.md" | 10 +- ...00\346\234\257\346\210\220\351\225\277.md" | 2 +- ...57\345\274\200\346\272\220\347\232\204.md" | 6 +- ...20\345\237\272\351\207\221\344\274\232.md" | 19 +- ...70\350\247\201\350\257\257\345\214\272.md" | 6 +- ...07\344\273\266\350\256\244\350\257\206.md" | 3 +- ...13\345\276\205\345\274\200\346\272\220.md" | 3 +- ...21\345\261\225\350\266\213\345\212\277.md" | 14 +- ...00\346\272\220\350\264\241\347\214\256.md" | 2 +- ...02\344\270\216\345\274\200\346\272\220.md" | 2 +- ...02\344\270\216\345\274\200\346\272\220.md" | 12 +- ...33\350\241\214\350\264\241\347\214\256.md" | 1 - ...\254\254\344\270\200\344\270\252 Issue.md" | 26 +- ...4\344\270\200\344\270\252 Pull Request.md" | 5 +- ...03\350\264\241\347\214\256\350\200\205.md" | 1 - ...56\350\200\205\345\205\254\347\272\246.md" | 1 - ...00\346\272\220\351\241\271\347\233\256.md" | 6 +- ...20\350\256\270\345\217\257\350\257\201.md" | 12 - ...36\350\265\217\346\226\207\345\214\226.md" | 5 - ...02\344\275\225\351\200\211\346\213\251.md" | 1 - ...73\347\220\206\346\236\266\346\236\204.md" | 7 - ...32\345\245\275\345\271\263\350\241\241.md" | 10 +- ...04\345\225\206\344\270\232\345\214\226.md" | 19 +- ...16\344\275\225\345\274\200\345\247\213.md" | 1 - ...75\347\232\204\345\237\272\347\241\200.md" | 4 - ...01\347\232\204\345\272\224\347\224\250.md" | 4 +- ...44\345\222\214\347\256\241\347\220\206.md" | 1 - ...2CONTRIBUTING \347\274\226\345\206\231.md" | 6 +- ...45\206\231\345\274\225\345\257\274-1.0.md" | 68 ++- ...26\345\206\231\346\214\207\345\215\227.md" | 4 +- ...26\345\206\231\350\247\204\350\214\203.md" | 403 +++++++++--------- 44 files changed, 949 insertions(+), 1079 deletions(-) diff --git a/README.md b/README.md index 368f34b..747ec52 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -![输入图片说明](https://images.gitee.com/uploads/images/2020/1014/153301_92280c77_1899542.png "置顶.png") +![输入图片说明](https://images.gitee.com/uploads/images/2020/1014/153301_92280c77_1899542.png "置顶.png") #### 🤷‍♀️ 这个仓库是什么？ @@ -7,16 +7,16 @@ 那么，开源的问题为什么不用开源的方式去解决呢？于是现在有了这样一个仓库，我们邀请广大开发者、开源爱好者、开源社区等与我们一起编写这本 **《开源指北》** ，分享自己对开源的认识和参与开源实践的经历，为那些想参与开源的开发者们提供一个丰富详实的操作指南，让更多开发者认识开源、参与开源、爱上开源。 #### 💡 快速引导 -1. 查看[目录](/%E7%9B%AE%E5%BD%95.md) ，了解本次电子书需编写的章节内容 -2. 进入目录章节，点击【编辑】按钮，通过[轻量级 PR ](https://gitee.com/help/articles/4291)的方式对内容进行补充； -详情请查看>>[编写指南](/编写指南.md) -3. 加入编写社群，了解项目编写情况 -添加 Gitee 小助手（gitee2013），备注「开源指北」，拉你入群 -![输入图片说明](https://images.gitee.com/uploads/images/2020/0712/212657_b00725ef_1899542.png "150-小助手微信.png") +1. 查看[目录](/%E7%9B%AE%E5%BD%95.md) ，了解本次电子书需编写的章节内容 +2. 进入目录章节，点击【编辑】按钮，通过[轻量级 PR ](https://gitee.com/help/articles/4291)的方式对内容进行补充； +详情请查看>>[编写指南](/编写指南.md) +3. 加入编写社群，了解项目编写情况 +添加 Gitee 小助手（gitee2013），备注「开源指北」，拉你入群 +![输入图片说明](https://images.gitee.com/uploads/images/2020/0712/212657_b00725ef_1899542.png "150-小助手微信.png") #### 📎 版本 -开源指北 1.0 版本：https://gitee.com/opensource-guide/ - +开源指北 1.0 版本：https://gitee.com/opensource-guide/ + #### 🔁 《开源指北》制作流程 | 事项 | 开始时间 | 结束时间 | 推进方式 | @@ -24,8 +24,7 @@ | 内容编写&审核 | 10 月 23 日 | 11 月 8 日 |由开源爱好者、开源组织&社区共同编写，审校专家团队筛选内容 | | 修改与整理|11 月 9 日 | 12 月 6 日|对内容进行最终的查漏补缺 | |汇编与制作 |12 月 20 日|待定|最终确定的内容将会以 Gitee Pages 和电子书的形式制作并展示| -|全面推广与内容更新 |待定 |永久|该仓库将始终保持开放状态，欢迎开发者持续提交内容更新与补充的 PR| - +|全面推广与内容更新 |待定 |永久|该仓库将始终保持开放状态，欢迎开发者持续提交内容更新与补充的 PR| #### 📜 编写方式 以参与开源贡献的方式，共同完成《开源指北》的初步编写。 @@ -36,7 +35,6 @@ * 最佳实践/案例 - #### 👩‍💻 参与编写者要求 我们的初衷是希望能够通过这个文档为刚接触开源的伙伴们普及开源基础知识，提供参与开源过程的经验分享，我们欢迎任何热爱开源的开发者或组织社区加入编写，如果你符合以下的任意条件，即可加入我们的编写队伍。 @@ -46,42 +44,40 @@ * 没有特别丰富的开源实践经验，但有较强的的信息检索与过滤能力，能提供详实的参考资料。 #### ❓ 如何参与编写 -* 想要直接参与编写？点击查看[编写指南](/%E7%BC%96%E5%86%99%E6%8C%87%E5%8D%97.md)。 +* 想要直接参与编写？点击查看[编写指南](/%E7%BC%96%E5%86%99%E6%8C%87%E5%8D%97.md)。 * 想要围观？欢迎你在评论区留下你宝贵的意见。 - -#### 🏆 通过活动你可以获得 -* 一次亲身参与开源项目的经历，并成为 Gitee 官方开源电子文档编写成员（将在开源指北电子书“编写成员”栏署名，并发放电子证书） - -* 优秀贡献者（提交 PR 内容优质且符合规则，并被评审团合并）可获得纪念周边一份（T恤/马克杯） - - -#### 👩‍👩‍👧‍👦 审校专家团队 -为保证电子文档的内容更有参考价值，Gitee 内容组特别邀请了几位技术专家担任本次的审校人员（以下名单按首字母排序）： - -**代立冬** -易观大数据平台总监，负责每日数百亿条数据处理链条的架构设计，技术选型，技术攻关等工作。十分热爱开源，是大数据任务调度 - Apache DolphinScheduler 的 PPMC & Committer，也活跃于各个大数据开源社区。 - -**姜宁** -华为开源能力中心技术专家，Apache 软件基金会会员，前红帽软件主任软件工程师，在企业级开源中间件开发方面有十余年经验，有丰富的 Java 开发和使用经验，函数式编程爱好者。从 2006 年开始一直从事 Apache 开源中间件项目的开发工作，先后参与 Apache CXF，Apache Camel，以及 Apache ServiceMix 的开发。 - - -**李建盛（笔名适兕）** -李建盛，开源文化布道师,技术翻译，开源之道作者，opensourceway.community 创始人、作家、译者、开源社成员。 - -**潘娟** -京东数科高级 DBA，Apache ALC Beijing member， Apache ShardingSphere PMC 主要负责京东数科分布式数据库开发、数据库运维自动化平台开发等工作。曾负责京东数科数据库自动化平台设计与开发，现专注于 Apache ShardingSphere 分布式数据库中间件生态的架构及研发。主要在分布式数据库、开源、分布式架构等相关领域进行探索。多次受邀参加数据库&架构领域的相关会议并进行分享交流。 - -**卫剑钒** -开源“圣经”《大教堂与集市》中文版译者，国际信息系统安全认证专家（CISSP），目前就职于某大型金融机构，从事信息科技管理工作。曾发表过《开源的7大理念》、《从契约精神谈 MIT 协议》、《copyright 的真正含义是什么》、《步进式解读 Apache 许可证》、《使用 Apache 协议的是自由软件吗》等文章。 - -**张亮** + +#### 🏆 通过活动你可以获得 +* 一次亲身参与开源项目的经历，并成为 Gitee 官方开源电子文档编写成员（将在开源指北电子书“编写成员”栏署名，并发放电子证书） + +* 优秀贡献者（提交 PR 内容优质且符合规则，并被评审团合并）可获得纪念周边一份（T恤/马克杯） + +#### 👩‍👩‍👧‍👦 审校专家团队 +为保证电子文档的内容更有参考价值，Gitee 内容组特别邀请了几位技术专家担任本次的审校人员（以下名单按首字母排序）： + +**代立冬** +易观大数据平台总监，负责每日数百亿条数据处理链条的架构设计，技术选型，技术攻关等工作。十分热爱开源，是大数据任务调度 - Apache DolphinScheduler 的 PPMC & Committer，也活跃于各个大数据开源社区。 + +**姜宁** +华为开源能力中心技术专家，Apache 软件基金会会员，前红帽软件主任软件工程师，在企业级开源中间件开发方面有十余年经验，有丰富的 Java 开发和使用经验，函数式编程爱好者。从 2006 年开始一直从事 Apache 开源中间件项目的开发工作，先后参与 Apache CXF，Apache Camel，以及 Apache ServiceMix 的开发。 + +**李建盛（笔名适兕）** +李建盛，开源文化布道师,技术翻译，开源之道作者，opensourceway.community 创始人、作家、译者、开源社成员。 + +**潘娟** +京东数科高级 DBA，Apache ALC Beijing member， Apache ShardingSphere PMC 主要负责京东数科分布式数据库开发、数据库运维自动化平台开发等工作。曾负责京东数科数据库自动化平台设计与开发，现专注于 Apache ShardingSphere 分布式数据库中间件生态的架构及研发。主要在分布式数据库、开源、分布式架构等相关领域进行探索。多次受邀参加数据库&架构领域的相关会议并进行分享交流。 + +**卫剑钒** +开源“圣经”《大教堂与集市》中文版译者，国际信息系统安全认证专家（CISSP），目前就职于某大型金融机构，从事信息科技管理工作。曾发表过《开源的7大理念》、《从契约精神谈 MIT 协议》、《copyright 的真正含义是什么》、《步进式解读 Apache 许可证》、《使用 Apache 协议的是自由软件吗》等文章。 + +**张亮** 京东数科数字技术中心架构专家，Apache ShardingSphere，ElasticJob 创始人。热爱开源，擅长以 Java 为主分布式架构，推崇优雅代码。 目前主要精力投入在将分布式数据库中间件 Apache ShardingSphere 打造为业界一流的金融级数据解决方案之上。 -Apache ShardingSphere 是京东主导的首个 Apache 软件基金会顶级项目，也是 Apache 软件基金会首个分布式数据库中间件。曾出版书籍《未来架构——从服务化到云原生》。 - +Apache ShardingSphere 是京东主导的首个 Apache 软件基金会顶级项目，也是 Apache 软件基金会首个分布式数据库中间件。曾出版书籍《未来架构——从服务化到云原生》。 + #### 🎪 支持社区 -![输入图片说明](https://images.gitee.com/uploads/images/2020/1126/135201_1f86cd37_1899542.png "支持社区-11-26.png") +![输入图片说明](https://images.gitee.com/uploads/images/2020/1126/135201_1f86cd37_1899542.png "支持社区-11-26.png") ### 📌 License diff --git a/Revision-activities.md b/Revision-activities.md index 65e537b..eab6095 100644 --- a/Revision-activities.md +++ b/Revision-activities.md @@ -1,26 +1,26 @@ #### 🤷‍♀️ 开源指北是什么？ - -开源指北是一本完全由开源爱好者、开源社区、开源领域专家编写的开源入门电子书籍，在 52 位开源贡献者和 6 位开源领域专家的共同努力下，开源指北 1.0 已正式进入修订的阶段，欢迎更多爱好开源的小伙伴加入我们的修订工作中！ - -[开源指北目录>>](/%E7%9B%AE%E5%BD%95.md) -[开源指北项目主页>>](https://gitee.com/gitee-community/opensource-guide) - + +开源指北是一本完全由开源爱好者、开源社区、开源领域专家编写的开源入门电子书籍，在 52 位开源贡献者和 6 位开源领域专家的共同努力下，开源指北 1.0 已正式进入修订的阶段，欢迎更多爱好开源的小伙伴加入我们的修订工作中！ + +[开源指北目录>>](/%E7%9B%AE%E5%BD%95.md) +[开源指北项目主页>>](https://gitee.com/gitee-community/opensource-guide) + #### ⏱ 修订时间 -2020 年 12 月 10 日 - 12 月 20 日 - +2020 年 12 月 10 日 - 12 月 20 日 + #### ❓ 修订规则 你可以通过 **轻量级 PR** 或 **Fork+ PR** 两种方式修订 -**修订内容：** +**修订内容：** - 根据修订任务对该章节进行补充或修改 -- 若你对该章节有更深的理解，也欢迎进行其他内容补充 - +- 若你对该章节有更深的理解，也欢迎进行其他内容补充 + #### 🏆 参与修订，你可以获得： 1. 一次亲身参与开源项目的经历，并成为 Gitee 官方开源电子文档编写成员（将在开源指北电子书“编写成员”栏署名，若为优秀内容贡献者，将颁发纸质证书） 2. 优秀贡献者（提交 PR 内容优质且符合规则，并被评审团合并）可获得纪念 T 恤一件 -3. [贡献榜](https://gitee.com/gitee-community/opensource-guide/contributors?ref=master) 前 10 名（前三位官方维护人员除外）可获得 TiDB 开发文具礼盒 一份 - +3. [贡献榜](https://gitee.com/gitee-community/opensource-guide/contributors?ref=master) 前 10 名（前三位官方维护人员除外）可获得 TiDB 开发文具礼盒 一份 + #### 📜 待修订章节 | 章节名 | 修订任务 | 链接 | |---|---|---| @@ -37,40 +37,38 @@ |开源治理-开源项目的常见治理架构| 补充 BDFL 模式、精英模式、Node.js 的自由贡献规则等三种模版（或规则） | [立即修订](第5部分——开源治理/开源项目的常见治理架构.md) | |开源治理-确保开源代码质量的几个要点| 本篇需要重点补充软件质量管理的内容，从技术和工具角度来给与建议 | [立即修订](第5部分——开源治理/确保开源代码质量的几个要点.md) | |其他问题-怎样在本职工作和开源项目间做好平衡| （1）从开源与个人技术成长、为什么要参与开源贡献的文章中总结出几点（2）增加“家人的支持”、“开源的选题”（开源选题是否要和工作内容有关系？如何把握？）的相关内容 | [立即修订](第6部分——其他问题/怎样在本职工作和开源项目间做好平衡.md) | -|其他问题-关于开源项目的商业化| （1）对有关 “Linux系统衍生的 Red Hat 系统”的说法需补充查证（2）关于“商业化开源项目参考”需补充商业化前的背景，商业化后的发展情况。 | [立即修订](第6部分——其他问题/关于开源项目的商业化.md) | - +|其他问题-关于开源项目的商业化| （1）对有关 “Linux系统衍生的 Red Hat 系统”的说法需补充查证（2）关于“商业化开源项目参考”需补充商业化前的背景，商业化后的发展情况。 | [立即修订](第6部分——其他问题/关于开源项目的商业化.md) | + #### 💡 快速引导 -有任何编写相关问题可联系 Gitee 小助手咨询，完成修订后可联系小助手加入开源指北维护群，发放奖品，领取证书。 -添加 Gitee 小助手（gitee2013），备注「开源指北」 -![输入图片说明](https://images.gitee.com/uploads/images/2020/0712/212657_b00725ef_1899542.png "150-小助手微信.png") - - -### 👩‍👩‍👧‍👦 审校专家团队 -为保证电子文档的内容更有参考价值，Gitee 内容组特别邀请了几位技术专家担任本次的审校人员（以下名单按首字母排序）： - -**代立冬** -易观大数据平台总监，负责每日数百亿条数据处理链条的架构设计，技术选型，技术攻关等工作。十分热爱开源，是大数据任务调度 - Apache DolphinScheduler 的 PPMC & Committer，也活跃于各个大数据开源社区。 - -**姜宁** -华为开源能力中心技术专家，Apache软件基金会会员，前红帽软件主任软件工程师，在企业级开源中间件开发方面有十余年经验，有丰富的 Java 开发和使用经验，函数式编程爱好者。从 2006 年开始一直从事 Apache 开源中间件项目的开发工作，先后参与Apache CXF，Apache Camel，以及 Apache ServiceMix 的开发。 - -**李建盛（笔名适兕）** -李建盛，开源文化布道师,技术翻译，开源之道作者，opensourceway.community 创始人、作家、译者、开源社成员。 - - -**潘娟** -京东数科高级 DBA，Apache ALC Beijing member， Apache ShardingSphere PMC 主要负责京东数科分布式数据库开发、数据库运维自动化平台开发等工作。曾负责京东数科数据库自动化平台设计与开发，现专注于Apache ShardingSphere分布式数据库中间件生态的架构及研发。主要在分布式数据库、开源、分布式架构等相关领域进行探索。多次受邀参加数据库&架构领域的相关会议并进行分享交流。 - -**卫剑钒** -开源“圣经”《大教堂与集市》中文版译者，国际信息系统安全认证专家（CISSP），目前就职于某大型金融机构，从事信息科技管理工作。曾发表过《开源的7大理念》、《从契约精神谈MIT协议》、《copyright的真正含义是什么》、《步进式解读Apache许可证》、《使用Apache协议的是自由软件吗》等文章。 - -**张亮** +有任何编写相关问题可联系 Gitee 小助手咨询，完成修订后可联系小助手加入开源指北维护群，发放奖品，领取证书。 +添加 Gitee 小助手（gitee2013），备注「开源指北」 +![输入图片说明](https://images.gitee.com/uploads/images/2020/0712/212657_b00725ef_1899542.png "150-小助手微信.png") + +### 👩‍👩‍👧‍👦 审校专家团队 +为保证电子文档的内容更有参考价值，Gitee 内容组特别邀请了几位技术专家担任本次的审校人员（以下名单按首字母排序）： + +**代立冬** +易观大数据平台总监，负责每日数百亿条数据处理链条的架构设计，技术选型，技术攻关等工作。十分热爱开源，是大数据任务调度 - Apache DolphinScheduler 的 PPMC & Committer，也活跃于各个大数据开源社区。 + +**姜宁** +华为开源能力中心技术专家，Apache软件基金会会员，前红帽软件主任软件工程师，在企业级开源中间件开发方面有十余年经验，有丰富的 Java 开发和使用经验，函数式编程爱好者。从 2006 年开始一直从事 Apache 开源中间件项目的开发工作，先后参与Apache CXF，Apache Camel，以及 Apache ServiceMix 的开发。 + +**李建盛（笔名适兕）** +李建盛，开源文化布道师,技术翻译，开源之道作者，opensourceway.community 创始人、作家、译者、开源社成员。 + +**潘娟** +京东数科高级 DBA，Apache ALC Beijing member， Apache ShardingSphere PMC 主要负责京东数科分布式数据库开发、数据库运维自动化平台开发等工作。曾负责京东数科数据库自动化平台设计与开发，现专注于Apache ShardingSphere分布式数据库中间件生态的架构及研发。主要在分布式数据库、开源、分布式架构等相关领域进行探索。多次受邀参加数据库&架构领域的相关会议并进行分享交流。 + +**卫剑钒** +开源“圣经”《大教堂与集市》中文版译者，国际信息系统安全认证专家（CISSP），目前就职于某大型金融机构，从事信息科技管理工作。曾发表过《开源的7大理念》、《从契约精神谈MIT协议》、《copyright的真正含义是什么》、《步进式解读Apache许可证》、《使用Apache协议的是自由软件吗》等文章。 + +**张亮** 京东数科数字技术中心架构专家，Apache ShardingSphere，ElasticJob 创始人。热爱开源，擅长以 Java 为主分布式架构，推崇优雅代码。 目前主要精力投入在将分布式数据库中间件 Apache ShardingSphere 打造为业界一流的金融级数据解决方案之上。 -Apache ShardingSphere 是京东主导的首个 Apache 软件基金会顶级项目，也是 Apache 软件基金会首个分布式数据库中间件。曾出版书籍《未来架构——从服务化到云原生》。 - +Apache ShardingSphere 是京东主导的首个 Apache 软件基金会顶级项目，也是 Apache 软件基金会首个分布式数据库中间件。曾出版书籍《未来架构——从服务化到云原生》。 + #### 🎪 支持社区 -![输入图片说明](https://images.gitee.com/uploads/images/2020/1126/135201_1f86cd37_1899542.png "支持社区-11-26.png") +![输入图片说明](https://images.gitee.com/uploads/images/2020/1126/135201_1f86cd37_1899542.png "支持社区-11-26.png") ### License diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/DolphinScheduler\345\246\202\344\275\225\345\270\246\351\242\206\346\210\221\350\265\260\350\277\233\345\274\200\346\272\220\347\232\204\344\270\226\347\225\214.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/DolphinScheduler\345\246\202\344\275\225\345\270\246\351\242\206\346\210\221\350\265\260\350\277\233\345\274\200\346\272\220\347\232\204\344\270\226\347\225\214.md" index 74e05fd..9dead13 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/DolphinScheduler\345\246\202\344\275\225\345\270\246\351\242\206\346\210\221\350\265\260\350\277\233\345\274\200\346\272\220\347\232\204\344\270\226\347\225\214.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/DolphinScheduler\345\246\202\344\275\225\345\270\246\351\242\206\346\210\221\350\265\260\350\277\233\345\274\200\346\272\220\347\232\204\344\270\226\347\225\214.md" @@ -1,36 +1,33 @@ -## 摘要 -> Apache DolphinScheduler 目前是 Apache 孵化项目，目前正在快速发展中。加入Apache DolphinScheduler社区已一年多，已有 400+ 公司在生产上使用，代码+文档贡献者近200位，社区用户4000 +人。本篇文章主要介绍我在Apache DolphinScheduler的经历及收获。 - -## 个人简介 -> 陈兴春，易观数科大数据平台测试工程师，Apache DolphinScheduler的一名 Commiter，拥有5年测试经验，平常主要负责千帆产品和DS的测试工作，喜欢专研新技术，对未知事物充满好奇心的一枚萌妹子 - - -## Apache DolphinScheduler 简述 - -Apache DolphinScheduler 是一个开源的分布式去中心化、易扩展的可视化DAG大数据调度系统。 于2017年在易观数科立项，2019年3月开源，于2019年8月29日通过Apache基金会投票正式成为Apache孵化器项目。 - -Apache DolphinScheduler致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。可调度Shell、Python、SQL、数据存储、Spark、Flink、MR、HTTP、子流程、依赖、条件判断等任务，DAG可视化，支持自定义时间调度、历史数据补数、指定单个任务运行、任务/资源监控、重跑、停止、暂停、失败重试、恢复失败、恢复运行、告警、容错、全局参数、自定义参数、系统内置参数等功能。 - - -## 结缘Apache DolphinScheduler - -2019年9月，我非常荣幸的加入易观数科，同时也加入了Apache DolphinScheduler社区，开始了与DolphinScheduler的成长之旅。DolphinScheduler是我参加的第一个开源项目，也正是Apache DolphinScheduler社区，让我知道中国开源正在崛起，中国开源的力量在壮大，越来越多的开发者及公司正在积极的拥抱开源。 - -## 入选commiter之路 - -初入DolphinScheduler社区时，@dailidong 冬哥说了一句让我至今也印象深刻的话：兴春，争取早日成为commiter。当时的我是不相信自己能成为commiter的，因为我不是开发，感觉没机会提交pr，何谈成为commiter。但是后面了解到成为commiter，不仅只有提交pr一条道路，只要为社区贡献一份力量，问题答疑、贡献文章、文档、社区运营宣传，都有机会成为commiter。 - -前期在@qiaozhanwei 占卫(DolphinScheduler PPMC)的帮助下，细心的帮我讲解DolphinScheduler业务、架构、部署以及各个服务之间的实现与联系，加上自己对linux、shell脚本、python、数据库及代码部署等有较好的基础，因此在短时间内就熟练的掌握DolphinScheduler并开始接管测试工作，把控DolphinScheduler每次发版质量的最后一道关卡。平时除了测试DolphinScheduler的业务，开始在社区进行答疑，处理GitHub上的issue，修改官网的文档。在测试V1.1.0到V1.2.0升级脚本时，发现install.sh中数据库类型为postgresql时，数据库连接却用的mysql，因此我的第一个pr产生了，哪怕只是改了一个简单的mysql，却是一个里程碑的开始，因为无数的pr及勇气都是第一个pr奠定的基石。后期经过不断的贡献与坚持，终于赶上第二批commiter的选拔，并成功入选成为DolphinScheduler的commiter。 - -当然，成为commiter不应该是加入开源项目的终极目标。成为commiter，拥有更大的操作权限，能更方便、更快捷的服务社区，同时对于项目及社区的发展与壮大，更多了一份责任，只有项目变强且被更多人及公司认可时，commiter的头衔才会变得更有意义。 - -## 社区氛围 - -社区最近多次在线上讨论master重构，经过几次会议后，加入讨论的社区人员越来越多，大家各抒己见，讨论技术实现的利与弊。作为一个测试人员，也许我不能提出专业的技术建议，也许整场会议我没有发言，但是我从不会缺席。在技术讨论过程中，我会关注开发的实现方式和逻辑，在后期测试的时候，我才能发现更多隐藏的测试点以及容易忽视的细节。 - -在DolphinScheduler社区，认识了很多大神，每天都在进行大脑风暴，讨论技术、架构及需求实现。他们利用自己休闲娱乐的时间，不断的为DolphinScheduler出谋划策，完善DolphinScheduler的功能，解决github上的issue。在他们身上，总能学到很多东西，不仅是在技术层面，更重要的是那份为了开源项目无私奉献的精神。也正是大家的贡献以及社区小伙伴的认可，社区用户群从当初的1个群增加到8个群，外加2个开发群，而且还在不断扩大，代码Contributors也从当初的1个人增长到148个，文档贡献者也有近50人了。还有一件非常值得庆贺的事情，Apache DolphinScheduler 2020年在数百个开源项目评选中脱颖而出荣获十大开源新锐项目。 - - -## 未来期许 - +## 摘要 +> Apache DolphinScheduler 目前是 Apache 孵化项目，目前正在快速发展中。加入Apache DolphinScheduler社区已一年多，已有 400+ 公司在生产上使用，代码+文档贡献者近200位，社区用户4000 +人。本篇文章主要介绍我在Apache DolphinScheduler的经历及收获。 + +## 个人简介 +> 陈兴春，易观数科大数据平台测试工程师，Apache DolphinScheduler的一名 Commiter，拥有5年测试经验，平常主要负责千帆产品和DS的测试工作，喜欢专研新技术，对未知事物充满好奇心的一枚萌妹子 + +## Apache DolphinScheduler 简述 + +Apache DolphinScheduler 是一个开源的分布式去中心化、易扩展的可视化DAG大数据调度系统。 于2017年在易观数科立项，2019年3月开源，于2019年8月29日通过Apache基金会投票正式成为Apache孵化器项目。 + +Apache DolphinScheduler致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。可调度Shell、Python、SQL、数据存储、Spark、Flink、MR、HTTP、子流程、依赖、条件判断等任务，DAG可视化，支持自定义时间调度、历史数据补数、指定单个任务运行、任务/资源监控、重跑、停止、暂停、失败重试、恢复失败、恢复运行、告警、容错、全局参数、自定义参数、系统内置参数等功能。 + +## 结缘Apache DolphinScheduler + +2019年9月，我非常荣幸的加入易观数科，同时也加入了Apache DolphinScheduler社区，开始了与DolphinScheduler的成长之旅。DolphinScheduler是我参加的第一个开源项目，也正是Apache DolphinScheduler社区，让我知道中国开源正在崛起，中国开源的力量在壮大，越来越多的开发者及公司正在积极的拥抱开源。 + +## 入选commiter之路 + +初入DolphinScheduler社区时，@dailidong 冬哥说了一句让我至今也印象深刻的话：兴春，争取早日成为commiter。当时的我是不相信自己能成为commiter的，因为我不是开发，感觉没机会提交pr，何谈成为commiter。但是后面了解到成为commiter，不仅只有提交pr一条道路，只要为社区贡献一份力量，问题答疑、贡献文章、文档、社区运营宣传，都有机会成为commiter。 + +前期在@qiaozhanwei 占卫(DolphinScheduler PPMC)的帮助下，细心的帮我讲解DolphinScheduler业务、架构、部署以及各个服务之间的实现与联系，加上自己对linux、shell脚本、python、数据库及代码部署等有较好的基础，因此在短时间内就熟练的掌握DolphinScheduler并开始接管测试工作，把控DolphinScheduler每次发版质量的最后一道关卡。平时除了测试DolphinScheduler的业务，开始在社区进行答疑，处理GitHub上的issue，修改官网的文档。在测试V1.1.0到V1.2.0升级脚本时，发现install.sh中数据库类型为postgresql时，数据库连接却用的mysql，因此我的第一个pr产生了，哪怕只是改了一个简单的mysql，却是一个里程碑的开始，因为无数的pr及勇气都是第一个pr奠定的基石。后期经过不断的贡献与坚持，终于赶上第二批commiter的选拔，并成功入选成为DolphinScheduler的commiter。 + +当然，成为commiter不应该是加入开源项目的终极目标。成为commiter，拥有更大的操作权限，能更方便、更快捷的服务社区，同时对于项目及社区的发展与壮大，更多了一份责任，只有项目变强且被更多人及公司认可时，commiter的头衔才会变得更有意义。 + +## 社区氛围 + +社区最近多次在线上讨论master重构，经过几次会议后，加入讨论的社区人员越来越多，大家各抒己见，讨论技术实现的利与弊。作为一个测试人员，也许我不能提出专业的技术建议，也许整场会议我没有发言，但是我从不会缺席。在技术讨论过程中，我会关注开发的实现方式和逻辑，在后期测试的时候，我才能发现更多隐藏的测试点以及容易忽视的细节。 + +在DolphinScheduler社区，认识了很多大神，每天都在进行大脑风暴，讨论技术、架构及需求实现。他们利用自己休闲娱乐的时间，不断的为DolphinScheduler出谋划策，完善DolphinScheduler的功能，解决github上的issue。在他们身上，总能学到很多东西，不仅是在技术层面，更重要的是那份为了开源项目无私奉献的精神。也正是大家的贡献以及社区小伙伴的认可，社区用户群从当初的1个群增加到8个群，外加2个开发群，而且还在不断扩大，代码Contributors也从当初的1个人增长到148个，文档贡献者也有近50人了。还有一件非常值得庆贺的事情，Apache DolphinScheduler 2020年在数百个开源项目评选中脱颖而出荣获十大开源新锐项目。 + +## 未来期许 + Apache DolphinScheduler正在拙壮成长，希望早日毕业成为顶级项目，而且我也坚信通过社区的力量与努力，DolphinScheduler一定会开辟出自己的一片天地，被越来越多的人熟知及应用。也希望广大同胞们的日子就如DolphinScheduler的slogan一样“调度选得好、下班回家早、调度选得对、回家安心睡”。同时，DolphinScheduler也欢迎更多的小伙伴加入社区，加入开源的队伍，为开源贡献一份力所能及的力量 \ No newline at end of file diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\342\200\234\346\210\221\347\232\204\344\270\200\345\211\202\350\211\257\350\215\257\342\200\235\344\271\213\345\274\200\346\272\220\346\214\207\345\214\227.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\342\200\234\346\210\221\347\232\204\344\270\200\345\211\202\350\211\257\350\215\257\342\200\235\344\271\213\345\274\200\346\272\220\346\214\207\345\214\227.md" index aee6be6..8005e4f 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\342\200\234\346\210\221\347\232\204\344\270\200\345\211\202\350\211\257\350\215\257\342\200\235\344\271\213\345\274\200\346\272\220\346\214\207\345\214\227.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\342\200\234\346\210\221\347\232\204\344\270\200\345\211\202\350\211\257\350\215\257\342\200\235\344\271\213\345\274\200\346\272\220\346\214\207\345\214\227.md" @@ -1,84 +1,84 @@ -# “我的一剂良药”之开源指北 - -> 文章较长，适合闲来无事时阅读。 - -## 开篇 - -开源指北是 Gitee 开源社区送给所有开源人的一份保姆级开源百科，它的出现让开源相关知识不再像“沧海遗珠”一样散落在瀚海苍茫，让初识开源者可以从容地面对开源之海的首次“起航”，让众多热衷开源的开源爱好者在这里畅谈其所想。 - -不得不说，开源指北项目的发起是一个非常有趣的想法，其秉持着“开源问题由开源来解决”的思想，吸引了众多开源爱好者参与到这项开源运动中来，我也是其中一员。这是我参与的第一个开源项目，在拟定标题时再三思忖，结合自身的亲身感受，最终定了这个标题。至于为什么说对我而言是“一剂良药”，在下文中我会作出解释。 - -相比“满满的正能量”，我更希望从平常视角坦诚相待，有喜悦，有悲伤，有勇往直前，有踟蹰迷茫。不管读到这篇文章的你正拥有着哪种情绪，都能从这些稀松平常的小事中有所得，然后继续努力前行，成为更好的自己。 - -接下来，分享一段普普通通、简简单单的故事。 - -## 源起 - -**“青山若无素，偃蹇不相亲。要识庐山面，他年是故人。”** - -我叫西狩，有些朋友也会叫我老江，从事 Java 开发相关工作。 - -2020年是动荡的一年。从我的大脑里进行热词分析，浮现出来了很多“动荡”的词汇。比如：“疫情”、“大选”、“制裁”、“猝死”、“内卷”等等。我们深知处在一个贩卖焦虑的时代，但有时还是会不自觉地被这些外界的焦虑所影响，对于处在人生各种分岔路口的人们而言，受到的影响可能会更大。随着时间越走越快，看到很多新鲜的事物如雨后春笋般破土而出，陌生而又新奇。就像是面对琳琅满目的商品一样，一不小心便挑花了眼。这时我们可能会迷茫，但我们深知，自己需要去做些什么来面对它们。 - -我不确定每个人是否都有过这种迷茫的经历，但就我个人而言，迷茫期是经常的，也是正常的。生活是一座围城，选择了漂泊但又渴望稳定，选择了努力但又渴望闲适。“有的人想得多却做得少”，我不确定这句话是否符合自己，但我深知自己做得还远远不够。大家应该都听过这样一句话：“学习最好的时间是十年前，其次是现在”。所以，**不要害怕迷茫，只要敢于面对迷茫并踏出下一步，那就是有意义的。** - -我不确定命运是否会眷顾内心和自己拧巴的人，但能够参与一项有意义的开源活动，我觉得自己是幸运的。一切的源头是从日常阅读公众号文章开始讲起，几个月前 [张乘辉](https://github.com/objcoding) 老师的一篇推文《使用 Hexo + Gitee 快速搭建属于自己的博客》，文章内容很简单易懂，而后我开始考虑搭建自己的博客。在搭建过程中，我 Gitee 平台上无意间看到了开源指北的开源活动，怀着一颗好奇心的自己就这样与开源指北相遇了。说实话，虽然平时也会在 Github、Gitee 上转一转，但顶多都是走马观花似的了解，并没有参与到什么开源项目中。起初自己也是随便了解一下。在了解项目简介、阅读其中几篇文章后，感觉自己对一些内容有一定的认知和共鸣，而且内容还有很多缺失，于是便尝试提交了一次 PR。 - -故事讲到这里，我可能还并不会深陷其中。在提交后的第二天，官方小伙伴 [tenngo](https://gitee.com/tenngoxars) 就合并了我的 PR。及时的正向反馈让我受到了很大的鼓舞，就像是可治百病的“一剂良药”，使我无处安放的心静了下来。于是便开始了我的第一次开源之旅。 - -## 指天说地 - -**“一点浩然气，千里快哉风。”** - -在开源指北之前，其实网络上有很多开源知识的相关文章，但太过零散，不成体系，对于想要参与开源的人并不友好。开源指北最大的意义就是对开源知识的整合，它涵盖了大部分常见的入门知识，可以帮助很多想要参与开源而不知如何入手的小伙伴，所以，我想有必要分享一下在开源指北参与过程中的感受与收获。 - -在《降临》中，有句台词让我记忆深刻：“If you immerse yourself into a foreign language, you can actually rewire your brain”。正如前文提到的迷茫期，最近一年的时间里发生了很多事情，思绪万千但却发现脚步却慢了下来。当我下意识提起自己的脚步时，却感觉似乎前方全是岔路，就在这时，开源指北出现了。在参与过程中，无论是查阅资料，还是编写文章，又或是提交 PR，都能感受到开源带给自己的活力。仔细想想，当自己毕业时，不愿在一眼望到头的生活里度过一生，那么自己对未来的迷茫和担忧就可以很好地接收了，因为这就是自己想要的生活。人生在世，不如意事常八九，大多数人都并非是一帆风顺的。**与其每日杞人忧天，不如沉下心来倾听内心的想法，然后坚定地踏出接下来的每一步。** - -在开始分享开源过程中的感悟前，先谈及了心态，是因为自己深知心态对我的重要性。在自己心静下来后，做事情的效率会有明显的提高，并且在交流、沟通以及决策上都可以更加清醒。接下来，便带着这份心态聊到哪算哪喽！ - -开源与我的本职专业有着密切的联系，虽然是第一次参与开源，但自己对开源并不算陌生。曾经怀着激动的心情参加的每次 Pivotal 技术峰会、各种技术的 Meetup 以及各位大佬的技术分享，在这一刻似乎派上了一定的用场。这也说明了**平日积累的重要性**，碎片化学习虽然并不能建立起心中的一套完整的框架体系，但对自己的影响是潜移默化的。我会对每个章节进行阅读，文章结构不顺就梳理结构，上下文衔接问题就修改上下文，明显出现内容缺失就通过查阅资料再加上自己的理解进行补充。后面又进行了反复的阅读，以及关注小伙伴们提交的 PR。我们会为项目中提及的“半开源”的概念展开探讨，会对开源知识互相交流以至于忘记时间，诸如 arch、CLA、中国第一个被 OSI 认可的协议等等。我们也会因为项目中的不足而争辩，而且可能最终谁也说服不了谁，大家的思想是平等的，没有对错，而最终的结论也是有趣而一致的。那么这个结论是什么呢？其实很简单，各自提交 PR 就好了。**求同存异是开源社区的不二法则，我不认可你的观点，但我尊重你表达思想的权利。** - -因工作需要，我在 2017 年加入了 Kettle 技术交流群，经过学习掌握了它，但由于后续没有机会再使用，我对 Kettle 的熟练程度大幅度下降，更不要说现在最新的开源版本。同样的原因，我在 2019 年初加入了 Skywalking 交流群，基本属于一个“潜水者”，只是经常会查看技术交流的消息。其他社群我就不一一列举了，我之所以提到这两段经历，是想反思一下自己：为什么曾经有那么多优秀的开源项目摆在自己面前，到现在自己还是一个开源小白？我感觉有两个重要的事情自己没有做得很好：**坚持和思维模式**。 - -- 参与开源不是一蹴而就的事情，我们需要花费大量的时间来将其打造成为一个更好的东西。我因为不再使用而放弃对 Kettle 的关注，所以它自然而然就离我远去了。**其实大多数人都并非天才，能成为一个项目中优秀开源者的主要原因就是坚持。** -- 我学习 Kettle 只想使用它来解决问题，但从未想过自己还可以改变它。如果保持这样的思维模式继续下去，那么坚持的意义就是十分有限的了，因为我只是一个熟练工，可能永远都无法突破成为建筑师。**一个目标是否能够可达，有时候需要的只是一个思维的转变。** - -最近看了吴晟老师在开放原子基金会 2020 年技术峰会上发表的演讲——[开源运营治理分论坛 - Educate Community Over Support Community](https://www.bilibili.com/video/BV125411E7GK?p=1&share_medium=iphone&share_plat=ios&share_source=QQ&share_tag=s_i×tamp=1611211180&unique_k=ZKplUv)。演讲中很清晰地为大家讲解了我们在开源中应该关注的重点，解释了社区各种角色的职责，也谈及了对社区发展和社区生态的看法。当然，其中让人受益匪浅的内容还有很多，而且没有太多难理解的技术，更多的是对开源经验的分享，感兴趣的小伙伴可以了解一下。这也是我的一个小建议：**多去与他人交谈，倾听他人的想法，我们需要在思想碰撞的过程中不断刺激自己进行思维升级。** - -再分享一则个人觉得有趣的事情，每个开源项目都有自己的排版规则，在参与开源指北过程中，我在一个关于排版的开源项目中发现了一个有趣的协议：WTFPL。参考知乎问答“[什么是 WTFPL（Do What the Fuck You Want to Public License），为什么会有人使用这一授权许可？](https://www.zhihu.com/question/20865060/answer/51757033)”中的描述来了解一下： - -> 由于程序拥有所有权，所以每段代码允许大家在何种程度上自然使用就成为了一个严肃的法律问题，所以就诞生了licence这个概念。其中有一些代码是写出来让大家随意免费使用的，所以licence就要规定你可以干一切事情。可是在法律里，“允许你干任何事情”这句话并不严谨，所以随着不断的诉讼、打官司、法学家的诠释，诞生了诸如 [@IAMSK](http://www.zhihu.com/people/c55d6c118b9141f20776588b0308e586) 所说的一大堆授权协议。 -> 但是问题来了。 -> 这个协议是给程序员看的，却是由法学家和律师写的。 -> 于是随着时间的推移，这些协议变得unreadable，也就是程序员根本不可能看懂。 -> -> 而这些协议还会越来越长，随着欧美法律不断地被新的判例充实。。。。 -> -> 于是一些程序员为了反抗这一恶性循环，发明了WTFPL。 -> -> 简而言之，就是：**“你TM爱干啥干啥”** - -有趣的点在于，我仿佛能脑补出当时程序员看到冗长的法律条文和专业名词的时候抓狂的面部表情，是个很有意思的小故事。 - -最后要说一下，个人认为，开源指北项目参与门槛并不高，虽然在内容上会尽力做到精益求精，但它的受众是每一个开源人，大家都可以在这里各抒己见。这个项目的维护也会一直开放，也希望能够在以后听到更多开源故事和开源声音。**毕竟开源这件事儿，一起热闹起来才好玩嘛！** - -## 北窗之友 - -**“今日北窗下，自问何所为，欣然得三友，三友者为谁？琴罢辄举酒，酒罢辄吟诗。”** - -如果说有人问：“一次开源经历中，最重要的是什么事情？是最后的结果么？”我想可能不是。当我们去做任何一件事情的时候，都无法预料到下一秒会发生什么，更不会预料到最后的结果会是什么样子，所以结论并不适合放在开源经历的第一位。正所谓兴趣是最好的老师，与其猜测未知的结果，不如遵从本心去体会在开源中遇到的所有感受。因此，**一次成功的硕果固然可喜，但更重要的是享受过程。** - -我们可以对于开源项目的任何事情畅所欲言，可以发表自己对开源项目的理解，可以讨论目前存在的问题，还可以从交流中了解到更加广阔的开源世界。当然，开源社区不会是只有一种声音，我们可以有不同的观点，可以有分歧和争辩，还可以享受每一次思想的碰撞。除了必要的社区准则以外，我们的文字、代码以及思想都是无比自由的，或许这就是开源精神带给我的一种体验。 - -既然谈到了开源精神，那么一群志同道合的秉承开源精神的小伙伴自然是必不可少的。在此，要感谢在开源指北项目中帮助和鼓励过我的小伙伴们： - -- 感谢 [jack960330](https://gitee.com/jack960330) 对我编写修订过程中给予的专业指点，也感谢耐心的讲解和对我的认可，钦佩你的专业态度。 - -- 感谢 [taotieren](https://gitee.com/taotieren) 的中文排版指北项目，在了解一种排版规范的同时，还发现其使用的 WTFPL 开源协议——一个有趣的协议以及背后有趣的小故事。 - -- 感谢众多的开源小伙伴，我们一起沟通探讨了很多开源小知识，也通过他们了解到了很多开源项目，一起奋战的日子会是一段非常美好的回忆！ - -- 感谢 Gitee 小助手带我加入开源小队，还给我邮递了那么多奖品，我会继续努力的。不辜负每一次参与！ -- 感谢与开源指北的不期而遇，这是我这个冬季里最温暖的“小太阳”。 - +# “我的一剂良药”之开源指北 + +> 文章较长，适合闲来无事时阅读。 + +## 开篇 + +开源指北是 Gitee 开源社区送给所有开源人的一份保姆级开源百科，它的出现让开源相关知识不再像“沧海遗珠”一样散落在瀚海苍茫，让初识开源者可以从容地面对开源之海的首次“起航”，让众多热衷开源的开源爱好者在这里畅谈其所想。 + +不得不说，开源指北项目的发起是一个非常有趣的想法，其秉持着“开源问题由开源来解决”的思想，吸引了众多开源爱好者参与到这项开源运动中来，我也是其中一员。这是我参与的第一个开源项目，在拟定标题时再三思忖，结合自身的亲身感受，最终定了这个标题。至于为什么说对我而言是“一剂良药”，在下文中我会作出解释。 + +相比“满满的正能量”，我更希望从平常视角坦诚相待，有喜悦，有悲伤，有勇往直前，有踟蹰迷茫。不管读到这篇文章的你正拥有着哪种情绪，都能从这些稀松平常的小事中有所得，然后继续努力前行，成为更好的自己。 + +接下来，分享一段普普通通、简简单单的故事。 + +## 源起 + +**“青山若无素，偃蹇不相亲。要识庐山面，他年是故人。”** + +我叫西狩，有些朋友也会叫我老江，从事 Java 开发相关工作。 + +2020年是动荡的一年。从我的大脑里进行热词分析，浮现出来了很多“动荡”的词汇。比如：“疫情”、“大选”、“制裁”、“猝死”、“内卷”等等。我们深知处在一个贩卖焦虑的时代，但有时还是会不自觉地被这些外界的焦虑所影响，对于处在人生各种分岔路口的人们而言，受到的影响可能会更大。随着时间越走越快，看到很多新鲜的事物如雨后春笋般破土而出，陌生而又新奇。就像是面对琳琅满目的商品一样，一不小心便挑花了眼。这时我们可能会迷茫，但我们深知，自己需要去做些什么来面对它们。 + +我不确定每个人是否都有过这种迷茫的经历，但就我个人而言，迷茫期是经常的，也是正常的。生活是一座围城，选择了漂泊但又渴望稳定，选择了努力但又渴望闲适。“有的人想得多却做得少”，我不确定这句话是否符合自己，但我深知自己做得还远远不够。大家应该都听过这样一句话：“学习最好的时间是十年前，其次是现在”。所以，**不要害怕迷茫，只要敢于面对迷茫并踏出下一步，那就是有意义的。** + +我不确定命运是否会眷顾内心和自己拧巴的人，但能够参与一项有意义的开源活动，我觉得自己是幸运的。一切的源头是从日常阅读公众号文章开始讲起，几个月前 [张乘辉](https://github.com/objcoding) 老师的一篇推文《使用 Hexo + Gitee 快速搭建属于自己的博客》，文章内容很简单易懂，而后我开始考虑搭建自己的博客。在搭建过程中，我 Gitee 平台上无意间看到了开源指北的开源活动，怀着一颗好奇心的自己就这样与开源指北相遇了。说实话，虽然平时也会在 Github、Gitee 上转一转，但顶多都是走马观花似的了解，并没有参与到什么开源项目中。起初自己也是随便了解一下。在了解项目简介、阅读其中几篇文章后，感觉自己对一些内容有一定的认知和共鸣，而且内容还有很多缺失，于是便尝试提交了一次 PR。 + +故事讲到这里，我可能还并不会深陷其中。在提交后的第二天，官方小伙伴 [tenngo](https://gitee.com/tenngoxars) 就合并了我的 PR。及时的正向反馈让我受到了很大的鼓舞，就像是可治百病的“一剂良药”，使我无处安放的心静了下来。于是便开始了我的第一次开源之旅。 + +## 指天说地 + +**“一点浩然气，千里快哉风。”** + +在开源指北之前，其实网络上有很多开源知识的相关文章，但太过零散，不成体系，对于想要参与开源的人并不友好。开源指北最大的意义就是对开源知识的整合，它涵盖了大部分常见的入门知识，可以帮助很多想要参与开源而不知如何入手的小伙伴，所以，我想有必要分享一下在开源指北参与过程中的感受与收获。 + +在《降临》中，有句台词让我记忆深刻：“If you immerse yourself into a foreign language, you can actually rewire your brain”。正如前文提到的迷茫期，最近一年的时间里发生了很多事情，思绪万千但却发现脚步却慢了下来。当我下意识提起自己的脚步时，却感觉似乎前方全是岔路，就在这时，开源指北出现了。在参与过程中，无论是查阅资料，还是编写文章，又或是提交 PR，都能感受到开源带给自己的活力。仔细想想，当自己毕业时，不愿在一眼望到头的生活里度过一生，那么自己对未来的迷茫和担忧就可以很好地接收了，因为这就是自己想要的生活。人生在世，不如意事常八九，大多数人都并非是一帆风顺的。**与其每日杞人忧天，不如沉下心来倾听内心的想法，然后坚定地踏出接下来的每一步。** + +在开始分享开源过程中的感悟前，先谈及了心态，是因为自己深知心态对我的重要性。在自己心静下来后，做事情的效率会有明显的提高，并且在交流、沟通以及决策上都可以更加清醒。接下来，便带着这份心态聊到哪算哪喽！ + +开源与我的本职专业有着密切的联系，虽然是第一次参与开源，但自己对开源并不算陌生。曾经怀着激动的心情参加的每次 Pivotal 技术峰会、各种技术的 Meetup 以及各位大佬的技术分享，在这一刻似乎派上了一定的用场。这也说明了**平日积累的重要性**，碎片化学习虽然并不能建立起心中的一套完整的框架体系，但对自己的影响是潜移默化的。我会对每个章节进行阅读，文章结构不顺就梳理结构，上下文衔接问题就修改上下文，明显出现内容缺失就通过查阅资料再加上自己的理解进行补充。后面又进行了反复的阅读，以及关注小伙伴们提交的 PR。我们会为项目中提及的“半开源”的概念展开探讨，会对开源知识互相交流以至于忘记时间，诸如 arch、CLA、中国第一个被 OSI 认可的协议等等。我们也会因为项目中的不足而争辩，而且可能最终谁也说服不了谁，大家的思想是平等的，没有对错，而最终的结论也是有趣而一致的。那么这个结论是什么呢？其实很简单，各自提交 PR 就好了。**求同存异是开源社区的不二法则，我不认可你的观点，但我尊重你表达思想的权利。** + +因工作需要，我在 2017 年加入了 Kettle 技术交流群，经过学习掌握了它，但由于后续没有机会再使用，我对 Kettle 的熟练程度大幅度下降，更不要说现在最新的开源版本。同样的原因，我在 2019 年初加入了 Skywalking 交流群，基本属于一个“潜水者”，只是经常会查看技术交流的消息。其他社群我就不一一列举了，我之所以提到这两段经历，是想反思一下自己：为什么曾经有那么多优秀的开源项目摆在自己面前，到现在自己还是一个开源小白？我感觉有两个重要的事情自己没有做得很好：**坚持和思维模式**。 + +- 参与开源不是一蹴而就的事情，我们需要花费大量的时间来将其打造成为一个更好的东西。我因为不再使用而放弃对 Kettle 的关注，所以它自然而然就离我远去了。**其实大多数人都并非天才，能成为一个项目中优秀开源者的主要原因就是坚持。** +- 我学习 Kettle 只想使用它来解决问题，但从未想过自己还可以改变它。如果保持这样的思维模式继续下去，那么坚持的意义就是十分有限的了，因为我只是一个熟练工，可能永远都无法突破成为建筑师。**一个目标是否能够可达，有时候需要的只是一个思维的转变。** + +最近看了吴晟老师在开放原子基金会 2020 年技术峰会上发表的演讲——[开源运营治理分论坛 - Educate Community Over Support Community](https://www.bilibili.com/video/BV125411E7GK?p=1&share_medium=iphone&share_plat=ios&share_source=QQ&share_tag=s_i×tamp=1611211180&unique_k=ZKplUv)。演讲中很清晰地为大家讲解了我们在开源中应该关注的重点，解释了社区各种角色的职责，也谈及了对社区发展和社区生态的看法。当然，其中让人受益匪浅的内容还有很多，而且没有太多难理解的技术，更多的是对开源经验的分享，感兴趣的小伙伴可以了解一下。这也是我的一个小建议：**多去与他人交谈，倾听他人的想法，我们需要在思想碰撞的过程中不断刺激自己进行思维升级。** + +再分享一则个人觉得有趣的事情，每个开源项目都有自己的排版规则，在参与开源指北过程中，我在一个关于排版的开源项目中发现了一个有趣的协议：WTFPL。参考知乎问答“[什么是 WTFPL（Do What the Fuck You Want to Public License），为什么会有人使用这一授权许可？](https://www.zhihu.com/question/20865060/answer/51757033)”中的描述来了解一下： + +> 由于程序拥有所有权，所以每段代码允许大家在何种程度上自然使用就成为了一个严肃的法律问题，所以就诞生了licence这个概念。其中有一些代码是写出来让大家随意免费使用的，所以licence就要规定你可以干一切事情。可是在法律里，“允许你干任何事情”这句话并不严谨，所以随着不断的诉讼、打官司、法学家的诠释，诞生了诸如 [@IAMSK](http://www.zhihu.com/people/c55d6c118b9141f20776588b0308e586) 所说的一大堆授权协议。 +> 但是问题来了。 +> 这个协议是给程序员看的，却是由法学家和律师写的。 +> 于是随着时间的推移，这些协议变得unreadable，也就是程序员根本不可能看懂。 +> +> 而这些协议还会越来越长，随着欧美法律不断地被新的判例充实。。。。 +> +> 于是一些程序员为了反抗这一恶性循环，发明了WTFPL。 +> +> 简而言之，就是：**“你TM爱干啥干啥”** + +有趣的点在于，我仿佛能脑补出当时程序员看到冗长的法律条文和专业名词的时候抓狂的面部表情，是个很有意思的小故事。 + +最后要说一下，个人认为，开源指北项目参与门槛并不高，虽然在内容上会尽力做到精益求精，但它的受众是每一个开源人，大家都可以在这里各抒己见。这个项目的维护也会一直开放，也希望能够在以后听到更多开源故事和开源声音。**毕竟开源这件事儿，一起热闹起来才好玩嘛！** + +## 北窗之友 + +**“今日北窗下，自问何所为，欣然得三友，三友者为谁？琴罢辄举酒，酒罢辄吟诗。”** + +如果说有人问：“一次开源经历中，最重要的是什么事情？是最后的结果么？”我想可能不是。当我们去做任何一件事情的时候，都无法预料到下一秒会发生什么，更不会预料到最后的结果会是什么样子，所以结论并不适合放在开源经历的第一位。正所谓兴趣是最好的老师，与其猜测未知的结果，不如遵从本心去体会在开源中遇到的所有感受。因此，**一次成功的硕果固然可喜，但更重要的是享受过程。** + +我们可以对于开源项目的任何事情畅所欲言，可以发表自己对开源项目的理解，可以讨论目前存在的问题，还可以从交流中了解到更加广阔的开源世界。当然，开源社区不会是只有一种声音，我们可以有不同的观点，可以有分歧和争辩，还可以享受每一次思想的碰撞。除了必要的社区准则以外，我们的文字、代码以及思想都是无比自由的，或许这就是开源精神带给我的一种体验。 + +既然谈到了开源精神，那么一群志同道合的秉承开源精神的小伙伴自然是必不可少的。在此，要感谢在开源指北项目中帮助和鼓励过我的小伙伴们： + +- 感谢 [jack960330](https://gitee.com/jack960330) 对我编写修订过程中给予的专业指点，也感谢耐心的讲解和对我的认可，钦佩你的专业态度。 + +- 感谢 [taotieren](https://gitee.com/taotieren) 的中文排版指北项目，在了解一种排版规范的同时，还发现其使用的 WTFPL 开源协议——一个有趣的协议以及背后有趣的小故事。 + +- 感谢众多的开源小伙伴，我们一起沟通探讨了很多开源小知识，也通过他们了解到了很多开源项目，一起奋战的日子会是一段非常美好的回忆！ + +- 感谢 Gitee 小助手带我加入开源小队，还给我邮递了那么多奖品，我会继续努力的。不辜负每一次参与！ +- 感谢与开源指北的不期而遇，这是我这个冬季里最温暖的“小太阳”。 + “琴罢辄举酒，酒罢辄吟诗”，这是我理想中的开源世界。所谓“琴”、“酒”、“诗”，是代指令自己感到美好的事物——是得到认可的喜悦，是有所收获的满足，是感受到如鱼得水般的自由。我觉得开源指北就是这样的，希望它在未来成长的路上，依旧如此自由！也希望参与开源的你——**Forever to be free !** \ No newline at end of file diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\344\274\227\351\207\214\345\257\273\345\245\271\345\215\203\347\231\276\345\272\246\344\271\213DolphinScheduler.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\344\274\227\351\207\214\345\257\273\345\245\271\345\215\203\347\231\276\345\272\246\344\271\213DolphinScheduler.md" index d1992ce..a36536d 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\344\274\227\351\207\214\345\257\273\345\245\271\345\215\203\347\231\276\345\272\246\344\271\213DolphinScheduler.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\344\274\227\351\207\214\345\257\273\345\245\271\345\215\203\347\231\276\345\272\246\344\271\213DolphinScheduler.md" @@ -1,61 +1,51 @@ - -### 前述 -#### 关于我 -我是CalvinKirs，目前是Apache DolphinScheduler的Commiter。擅长大数据olap、大数据调度、分布式组件开发等。目前专注于大数据领域核心技术研发。 -我也是一名开源爱好者，我要讲的是我从起始给 DolphinScheduler 做贡献到近期加入到易观数科大家庭的故事。 - -#### 关于 Apache DolphinScheduler社区 -Apache DolphinScheduler(incubator) 于17年在易观数科立项，19年3月开源， 19 年8月进入Apache 孵化器，社区发展非常迅速，目前已有 400+ 公司在生产上使用，代码+文档贡献者近200位，社区用户4000 +人。DolphinScheduler (简称DS) 致力于使大数据任务调度开箱即用，它以拖拉拽的可视化方式将各种任务间的关系组装成 DAG(有向无环图)，并实时监控整个数据pipeline的运行状态，同时支持失败重试、重跑、恢复失败、补数等大数据常用操作 - - -### 遇见DolphinScheduler - -我是一个有开源情节的人，开源以不同的方式陪伴了我相当长的一段时间，同样也给我带来了一些比较大的改变。 - -我个人接触的开源项目是比较多的，但是深度贡献的并不多，也是一个偶然的契机接触到DolphinScheduler，从此开始了深度贡献。 - -选择对味的社区其实很重要，如同恋爱一般，总需要几个回合摸索试探才能决定是否合适，DolphinScheduler社区给我的一个最大的感受就是足够包容，我不认同你，但是我支持你。这是[dailidong](https://github.com/dailidong)给我的一个最直观的感受,你的想法不成熟的时候，作为PPMC，他需要对社区负责，他可能不是很认同，但是他支持你去完善去佐证，这个过程中也是很感谢社区的一些其他伙伴，[qiaozhanwei](https://github.com/qiaozhanwei)、[Tboy](https://github.com/Technoboy-)、[gaojun2048](https://github.com/gaojun2048),[lgcarrer](https://github.com/lgcareer)(license的大佬)、[lenboo](https://github.com/lenboo)(核心流程找他就对了)等，一开始我总有种人微言轻的感觉，一般都处在旁听的状态，毕竟这些贡献者基本上都是各大公司的精英人物。后来发现是我多虑了，大神们其实非常平易近人。也是因为这些人，让我喜欢上DolphinScheduler社区。 - -### 社区带给我的影响 - -随着社区的发展，越来越多同学的加入，我们可能（甚至是必然）会在一些设计上存在一些不同的意见，但这其实也是开源的魅力，对于社区来讲，也是一种好事，不同思想的碰撞才会导致设计趋近于更加完善。也只有这样，DolphinScheduler才能更好走向全球。当然，对于个人来讲，也是一种提升，就我而言，我之前在社区讨论关于通讯序列化方案的想法，我们的导师，[吴晟老师](https://github.com/wu-sheng)问我，为什么不选择protobuf呢，我以前的认知，只体现在一个很片面的范围内，但是吴晟老师从更高层次回答了我所谓的protobuf鸡肋的地方，这确实打开了我的视野。感兴趣的可以去搜邮件列表，我所想要表达的是，开源是一个全球的舞台，会有各种不同的人进来参与，也正是由于这样，你的提升才会更大，因为你不再停留在原有的圈子原有的认知去思考，你会接受各种各样的人来进行review（不仅仅是code，同样包括一些设计等等），这种过程其实也是在逐渐拓宽自己的专业领域与认知。 - -### DolphinScheduler微内核插件化设计 - -项目的推进导致架构的变化，捐给Apache之后，意味着你要面向全球的用户，不同的用户对于不同场景的需求是不同的，我们更希望的是DolphinScheduler作为一个基础设施提供给用户，给用户提供强大的扩展能力，用户在DolphinScheduler这个平台上去快速扩充自己的功能。 - -在2020年（近期会发版），[高俊老师](https://github.com/gaojun2048)提出了微内核插件化的架构设计，拿alert来讲，我们alert发版后是支持五种告警方式，这能够满足绝大多数用户的一个需求，但依然有一些需求是没办法满足的，这个时候用户想要自己实现其实很简单，他不需要系统的去了解DolphinScheduler的整个架构，只需要关注alert的扩展接口，对于其他功能来讲是完全隔离的（这也意味着你降低了污染传递，当你的模块出现问题的时候，你不会过多影响其他模块，甚至你可以完全移除你自己的插件），这对于用户来讲，理解成本更低、开发成本测试成本同样更低，对于贡献者来讲亦是如此，降低贡献者门槛，才能使得一个项目走的更远，曲高和寡，对于开源项目来讲同样如此，DolphinScheduler社区目前有很多其他社区的贡献者，比如SkyWalking、ShardingSphere、Dubbo、TubeMq等，调度系统更是与其他大数据生态紧密结合，我们也是希望，通过微内核插件化的方式，使得各个领域的专家都可以以最低成本的贡献进来。 - -### 开源的乐趣 - - -[姜宁老师](https://github.com/WillemJiang)讲，开源社区其实是一帮对的人才能够聚在一起，这种过程会让你很享受，我之前收到过一封邮件，是一个印度贡献者的，我merge了他参与Apache DolphinScheduler的第一个PR，他写了大概几百字的一封邮件，表达对于开源的向往以及询问我后续参与贡献的一个途径，我不太确定这是否会导致他从此踏上开源这条路，成为一个深度贡献者，但至少对于他来讲，这一刻他有了深度参与的一个想法，我当时也是因为首次贡献被merge之后于是踏上了开源这条路，我至今依然记得我对于Apache的第一个PR，虽然小，甚至从今天看来，那可能是我贡献的PR中最微不足道的一个，但对于我来讲，它为我打开了一扇门，所以其实到今天，我很乐意给那些初次贡献的贡献者提供深度的一个帮助，帮他们认识开源、走进开源。曾经有人为我打开了一扇门，那我希望我能够给更多的人提供走进这扇门的一个帮助，这可能也是一种属于开源人的传承（BTW,强烈推荐[ALC BeiJing](https://github.com/alc-beijing)）。 - -马斯洛需求层次理论中讲到人的高级需求，其实对我来讲，通过DolphinScheduler，我达到了自我实现与尊重。 - -当我写的代码，会运行在数万台服务器上，影响几亿的用户，我也是第一次感觉作为个体和这个世界有了更加紧密的一个联系，这种内心的成就感是非常高的。 - -当我看到被我merge代码的同学发朋友圈或者邮件的时候，我内心其实也是非常愉快的，我老板说：优秀的人成就自己，卓越的人成就他人，我可能不是很优秀的人，但如果能够从一件小事上影响到别人，对于我来讲，我也是很愉悦的（成年人的快乐有时候就这么简单）。 - - -### 尾篇 致下一个贡献者的你 - -[大侠](https://github.com/William-GuoWei)在ALC Beijing-开源到底有多难中以[开源，不是天才的甜点，而是勤奋者的盛宴](https://zhuanlan.zhihu.com/p/208577284)为题的分享有几句话是比较触动我的 -``` -“中国没有开源”这个观点我是不愿意相信的。我相信这一代年轻人，不仅仅是程序猿，而是越来越多的人，愿意参加到各行各业的非盈利团体当中去，贡献自己的想法、代码、知识，让这个世界变得更加美好。 - - - -我相信哪怕我们这一代人看不到开源的春天，我们的下一代人也不应该再看到开源的“雾霾天”。于是我们就积攒了更多的力量，筹备了一年，把我们自己内部使用的一个产品 — Dolphin Scheduler 进行了开源。 -``` -我身边参与开源的人其实蛮多的，但倘若放到整个公司来讲，其实也并不多，上家公司，产研三四百多人，但是是Apache commiter或者PMC的仅仅只有三人，然而我们整个基础设施一大半是在开源软件的基础上进行开发的（其中一大半是ASF的），对于所使用到的开源项目，我们基本都是内部单独维护了一个分支，这样做当然有好处，我们可以跑的很快，有什么问题可以很快修复，但是很少有人会把这些贡献给上游，最终结果导致和上游差异过大，彻底和社区脱节。大家的现状是很忙，没有时间思考，大多数人不断的掉进坑里面再爬出来，但如果每个人都做出一点点努力，那么这样其实成本是最少的。你贡献一点，他贡献一点，那么其实我们的工作量会减少很多，因为社区帮你做了。这也是开源的力量，还是回到那句话，一个人可以走的很快，但一群人可以走得很远。 - - -熟悉吴晟老师的人都知道吴晟老师喜欢用『各怀鬼胎』来形容开源社区，我想说的是，无论你怀有什么样的心思（又或者仅仅是单纯的喜欢开源），透过开源确实可以帮你达到一些需求的满足，无论是一份光鲜的履历，或者一份 good job，或者隐形的人脉、技术实力的提升、多一点谈资等等。但这个前提是你去参与，去贡献。（BTW，我本人其实也是开源的受益者，因为参与开源，我有幸加入了易观，大多数企业对于开源贡献者还是比较友好的，吴晟老师的一次[分享](https://www.bilibili.com/video/BV17Q4y1N7iA)，有数据显示：87%的雇主希望招聘到具备开源能力的员工，而55%的开源业内人士表示他们可以轻松地找到一份新工作。） - -中国并不缺乏优秀的工程师，缺乏的仅仅是如何正确的认识开源，参与开源。今天的中国开源其实已经非常好了，有很多前辈以及组织在开源这个领域为我们进行铺路布道，比如开源社、ALC Beijing等，我们所缺少的，仅仅是大家的参与。有一句很老套的话：如果不是现在，那是什么时候？如果不是你，那会是谁？我是[CalvinKirs](https://github.com/CalvinKirs)，我在[DolphinScheduler](https://github.com/apache/incubator-dolphinscheduler)社区等你。 - - - - - + +### 前述 +#### 关于我 +我是CalvinKirs，目前是Apache DolphinScheduler的Commiter。擅长大数据olap、大数据调度、分布式组件开发等。目前专注于大数据领域核心技术研发。 +我也是一名开源爱好者，我要讲的是我从起始给 DolphinScheduler 做贡献到近期加入到易观数科大家庭的故事。 + +#### 关于 Apache DolphinScheduler社区 +Apache DolphinScheduler(incubator) 于17年在易观数科立项，19年3月开源， 19 年8月进入Apache 孵化器，社区发展非常迅速，目前已有 400+ 公司在生产上使用，代码+文档贡献者近200位，社区用户4000 +人。DolphinScheduler (简称DS) 致力于使大数据任务调度开箱即用，它以拖拉拽的可视化方式将各种任务间的关系组装成 DAG(有向无环图)，并实时监控整个数据pipeline的运行状态，同时支持失败重试、重跑、恢复失败、补数等大数据常用操作 + +### 遇见DolphinScheduler + +我是一个有开源情节的人，开源以不同的方式陪伴了我相当长的一段时间，同样也给我带来了一些比较大的改变。 + +我个人接触的开源项目是比较多的，但是深度贡献的并不多，也是一个偶然的契机接触到DolphinScheduler，从此开始了深度贡献。 + +选择对味的社区其实很重要，如同恋爱一般，总需要几个回合摸索试探才能决定是否合适，DolphinScheduler社区给我的一个最大的感受就是足够包容，我不认同你，但是我支持你。这是[dailidong](https://github.com/dailidong)给我的一个最直观的感受,你的想法不成熟的时候，作为PPMC，他需要对社区负责，他可能不是很认同，但是他支持你去完善去佐证，这个过程中也是很感谢社区的一些其他伙伴，[qiaozhanwei](https://github.com/qiaozhanwei)、[Tboy](https://github.com/Technoboy-)、[gaojun2048](https://github.com/gaojun2048),[lgcarrer](https://github.com/lgcareer)(license的大佬)、[lenboo](https://github.com/lenboo)(核心流程找他就对了)等，一开始我总有种人微言轻的感觉，一般都处在旁听的状态，毕竟这些贡献者基本上都是各大公司的精英人物。后来发现是我多虑了，大神们其实非常平易近人。也是因为这些人，让我喜欢上DolphinScheduler社区。 + +### 社区带给我的影响 + +随着社区的发展，越来越多同学的加入，我们可能（甚至是必然）会在一些设计上存在一些不同的意见，但这其实也是开源的魅力，对于社区来讲，也是一种好事，不同思想的碰撞才会导致设计趋近于更加完善。也只有这样，DolphinScheduler才能更好走向全球。当然，对于个人来讲，也是一种提升，就我而言，我之前在社区讨论关于通讯序列化方案的想法，我们的导师，[吴晟老师](https://github.com/wu-sheng)问我，为什么不选择protobuf呢，我以前的认知，只体现在一个很片面的范围内，但是吴晟老师从更高层次回答了我所谓的protobuf鸡肋的地方，这确实打开了我的视野。感兴趣的可以去搜邮件列表，我所想要表达的是，开源是一个全球的舞台，会有各种不同的人进来参与，也正是由于这样，你的提升才会更大，因为你不再停留在原有的圈子原有的认知去思考，你会接受各种各样的人来进行review（不仅仅是code，同样包括一些设计等等），这种过程其实也是在逐渐拓宽自己的专业领域与认知。 + +### DolphinScheduler微内核插件化设计 + +项目的推进导致架构的变化，捐给Apache之后，意味着你要面向全球的用户，不同的用户对于不同场景的需求是不同的，我们更希望的是DolphinScheduler作为一个基础设施提供给用户，给用户提供强大的扩展能力，用户在DolphinScheduler这个平台上去快速扩充自己的功能。 + +在2020年（近期会发版），[高俊老师](https://github.com/gaojun2048)提出了微内核插件化的架构设计，拿alert来讲，我们alert发版后是支持五种告警方式，这能够满足绝大多数用户的一个需求，但依然有一些需求是没办法满足的，这个时候用户想要自己实现其实很简单，他不需要系统的去了解DolphinScheduler的整个架构，只需要关注alert的扩展接口，对于其他功能来讲是完全隔离的（这也意味着你降低了污染传递，当你的模块出现问题的时候，你不会过多影响其他模块，甚至你可以完全移除你自己的插件），这对于用户来讲，理解成本更低、开发成本测试成本同样更低，对于贡献者来讲亦是如此，降低贡献者门槛，才能使得一个项目走的更远，曲高和寡，对于开源项目来讲同样如此，DolphinScheduler社区目前有很多其他社区的贡献者，比如SkyWalking、ShardingSphere、Dubbo、TubeMq等，调度系统更是与其他大数据生态紧密结合，我们也是希望，通过微内核插件化的方式，使得各个领域的专家都可以以最低成本的贡献进来。 + +### 开源的乐趣 + +[姜宁老师](https://github.com/WillemJiang)讲，开源社区其实是一帮对的人才能够聚在一起，这种过程会让你很享受，我之前收到过一封邮件，是一个印度贡献者的，我merge了他参与Apache DolphinScheduler的第一个PR，他写了大概几百字的一封邮件，表达对于开源的向往以及询问我后续参与贡献的一个途径，我不太确定这是否会导致他从此踏上开源这条路，成为一个深度贡献者，但至少对于他来讲，这一刻他有了深度参与的一个想法，我当时也是因为首次贡献被merge之后于是踏上了开源这条路，我至今依然记得我对于Apache的第一个PR，虽然小，甚至从今天看来，那可能是我贡献的PR中最微不足道的一个，但对于我来讲，它为我打开了一扇门，所以其实到今天，我很乐意给那些初次贡献的贡献者提供深度的一个帮助，帮他们认识开源、走进开源。曾经有人为我打开了一扇门，那我希望我能够给更多的人提供走进这扇门的一个帮助，这可能也是一种属于开源人的传承（BTW,强烈推荐[ALC BeiJing](https://github.com/alc-beijing)）。 + +马斯洛需求层次理论中讲到人的高级需求，其实对我来讲，通过DolphinScheduler，我达到了自我实现与尊重。 + +当我写的代码，会运行在数万台服务器上，影响几亿的用户，我也是第一次感觉作为个体和这个世界有了更加紧密的一个联系，这种内心的成就感是非常高的。 + +当我看到被我merge代码的同学发朋友圈或者邮件的时候，我内心其实也是非常愉快的，我老板说：优秀的人成就自己，卓越的人成就他人，我可能不是很优秀的人，但如果能够从一件小事上影响到别人，对于我来讲，我也是很愉悦的（成年人的快乐有时候就这么简单）。 + +### 尾篇 致下一个贡献者的你 + +[大侠](https://github.com/William-GuoWei)在ALC Beijing-开源到底有多难中以[开源，不是天才的甜点，而是勤奋者的盛宴](https://zhuanlan.zhihu.com/p/208577284)为题的分享有几句话是比较触动我的 +``` +“中国没有开源”这个观点我是不愿意相信的。我相信这一代年轻人，不仅仅是程序猿，而是越来越多的人，愿意参加到各行各业的非盈利团体当中去，贡献自己的想法、代码、知识，让这个世界变得更加美好。 + +我相信哪怕我们这一代人看不到开源的春天，我们的下一代人也不应该再看到开源的“雾霾天”。于是我们就积攒了更多的力量，筹备了一年，把我们自己内部使用的一个产品 — Dolphin Scheduler 进行了开源。 +``` +我身边参与开源的人其实蛮多的，但倘若放到整个公司来讲，其实也并不多，上家公司，产研三四百多人，但是是Apache commiter或者PMC的仅仅只有三人，然而我们整个基础设施一大半是在开源软件的基础上进行开发的（其中一大半是ASF的），对于所使用到的开源项目，我们基本都是内部单独维护了一个分支，这样做当然有好处，我们可以跑的很快，有什么问题可以很快修复，但是很少有人会把这些贡献给上游，最终结果导致和上游差异过大，彻底和社区脱节。大家的现状是很忙，没有时间思考，大多数人不断的掉进坑里面再爬出来，但如果每个人都做出一点点努力，那么这样其实成本是最少的。你贡献一点，他贡献一点，那么其实我们的工作量会减少很多，因为社区帮你做了。这也是开源的力量，还是回到那句话，一个人可以走的很快，但一群人可以走得很远。 + +熟悉吴晟老师的人都知道吴晟老师喜欢用『各怀鬼胎』来形容开源社区，我想说的是，无论你怀有什么样的心思（又或者仅仅是单纯的喜欢开源），透过开源确实可以帮你达到一些需求的满足，无论是一份光鲜的履历，或者一份 good job，或者隐形的人脉、技术实力的提升、多一点谈资等等。但这个前提是你去参与，去贡献。（BTW，我本人其实也是开源的受益者，因为参与开源，我有幸加入了易观，大多数企业对于开源贡献者还是比较友好的，吴晟老师的一次[分享](https://www.bilibili.com/video/BV17Q4y1N7iA)，有数据显示：87%的雇主希望招聘到具备开源能力的员工，而55%的开源业内人士表示他们可以轻松地找到一份新工作。） + +中国并不缺乏优秀的工程师，缺乏的仅仅是如何正确的认识开源，参与开源。今天的中国开源其实已经非常好了，有很多前辈以及组织在开源这个领域为我们进行铺路布道，比如开源社、ALC Beijing等，我们所缺少的，仅仅是大家的参与。有一句很老套的话：如果不是现在，那是什么时候？如果不是你，那会是谁？我是[CalvinKirs](https://github.com/CalvinKirs)，我在[DolphinScheduler](https://github.com/apache/incubator-dolphinscheduler)社区等你。 + diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\345\220\221\345\276\256\350\275\257\345\256\230\346\226\271\350\264\241\347\214\256 @types \345\214\205.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\345\220\221\345\276\256\350\275\257\345\256\230\346\226\271\350\264\241\347\214\256 @types \345\214\205.md" index 7ba3219..01e5182 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\345\220\221\345\276\256\350\275\257\345\256\230\346\226\271\350\264\241\347\214\256 @types \345\214\205.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\345\220\221\345\276\256\350\275\257\345\256\230\346\226\271\350\264\241\347\214\256 @types \345\214\205.md" @@ -1,92 +1,92 @@ -在前端社区中，TypeScript 差不多是老生常谈的主题了。这不仅反映了 TypeScript 的流行度，也反映了它的学习上手成本。今天我们不来探讨 TypeScript 本身。而是记录一下我艰难地发布一个 [@types](https://www.npmjs.com/package/@types/tuya-panel-kit) 包的历程。 - -## a year ago - - - -上图是我在掘金的第一篇文章 [优雅地使用 TypeScript 开发 React Native 应用](https://juejin.cn/post/6844903843155689486) 中的一条素质问答。问题就是有些库不是 TS 写的，也没提供类型声明该怎么办。从图中可见我当时的解决方法都是不可复用且不利他的。但这就是我这一年来处理该问题的常规手段。 - -![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/04f411da146740aab8f620337a592850~tplv-k3u1fbpfcp-watermark.image) - -## DefinitelyTyped - -像是 Node 有 NPM，Java 有 Maven，TypeScript 也有它的另一半，那就是号称 GitHub review 数量之最的 [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) 项目。 - -![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d503ee17f0ab45068a0d50a4d6f6034a~tplv-k3u1fbpfcp-watermark.image) - -在 TypeScript 大规模应用之前，社区已经有超过 90% 的顶级 JavaScript 库，或基于 Flow 编写的库（React 系）。如果没有 DefinitelyTyped 项目，这些库想要提供类型支持，无疑只有完全重构代码。这既不现实也没必要。 - -> 鉴于 DefinitelyTyped 的作用，我们说 DefinitelyTyped 让 TypeScript 再次伟大也不为过。 - -DefinitelyTyped 目前是由微软官方维护的开源项目，参与的方式和 Homebrew 差不多，都是基于 GitHub 的工作流: - -1. fork [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) 到自己的账号下 -2. 添加自己的包并编写类型声明 -3. 提交 PR -4. 官方 review 并合并发布到 NPM - -## 艰辛的贡献历程 - -1、检查是否已存在同名的包： - -```sh -npm info @types/tuya-panel-kit -``` - -2、安装 dts-gen： - -```sh -npm install -g dts-gen -``` - -3、生成新包 - -```sh -dts-gen --dt --name tuya-panel-kit --template module -``` - -4、格式化代码 - -```sh -npm run prettier -- --write types/tuya-panel-kit/**/*.ts -``` - -这一步务必要执行，因为 DefinitelyTyped 十分严格，格式不对过不了 CI。过不了 CI，就只配合机器人对话： - -![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/140adf442a17460aa845aef8e4b8ac18~tplv-k3u1fbpfcp-watermark.image) - -5、dtslint - -```sh -yarn lint tuya-panel-kit -``` - -这一步是最让人头大的一步，Definitely 的规则可谓严苛，真就对的起它的 SLOGAN： - -> The repository for high quality TypeScript type definitions - -我梳理了一下成功路上的绊脚石： - -1、 [Cannot find module 'csstype' when npm run lint package-name](https://github.com/DefinitelyTyped/DefinitelyTyped/issues/24788) - -这是一个流程 BUG，如果你的包依赖了 react，你需要执行 `cd types/react && npm install` 和 `cd ~/.dts/typescript-installs/3.2/ && npm install` - -2、如果你的包依赖了别的外部库，需要添加到 [microsoft/DefinitelyTyped-tools](https://github.com/microsoft/DefinitelyTyped-tools/pull/165/files) 项目中，否则 CI 不给过。 - -3、你的类型声明可能有很多不符合 dtslint 的标准，我看到有的包是在 `tslint.json` 中配置禁用掉部分规则，但是我做了尝试后被人工拒绝了。 - -![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fafa598fac2e4015ab496cc15fd94496~tplv-k3u1fbpfcp-watermark.image) - -然后我尝试在顶部加入 `// tslint:disable:max-line-length` 禁用规则，在说明原因后通过了 Review。就在发稿时，最新 PR 却因为一个禁用规则，被要求修改： - -![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/21a0b43a6f464c47a1b94a5fc7ed619f~tplv-k3u1fbpfcp-watermark.image) - -## 规范的重要性 - -刚开始时，这种严苛漫长的 review 流程着实让我头大。但在提过 4 个 PR 都被合并后，我发现 review 的人关心的是你为什么要这么写，是不是有什么不得已的苦衷，是否符合高质量的要求。 - -在参与 DefinitelyTyped 的协作中，我越来越发现规范的重要。如此体量的项目，如果没有严格有效的规范约束，势必会被开发者抛弃。那我们来看看 DefinitelyTyped 中是如何约束的： - -1. [dtslint](https://github.com/microsoft/dtslint) ：微软专门写的用来检验类型声明文件的工具。正是因为它，我做了大量优化工作。 -2. 机器人 🤖（dt-mergebot、dt-review-bot、typescript-bot-watchdog）：在你的代码通过所有规范之前，都是这些机器人在和你交互。大家感兴趣的话，之后我会单独出一篇解析的文章 -3. 尽职尽责的维护：虽然有时 review 速度明显很慢（可能因为国外疫情）。但是这些维护者真的是尽职尽责的 review 你的代码。机器再厉害也只是一个减少工作量的工具。我们应该致敬的还是这些为社区默默奉献的人。 +在前端社区中，TypeScript 差不多是老生常谈的主题了。这不仅反映了 TypeScript 的流行度，也反映了它的学习上手成本。今天我们不来探讨 TypeScript 本身。而是记录一下我艰难地发布一个 [@types](https://www.npmjs.com/package/@types/tuya-panel-kit) 包的历程。 + +## a year ago + + + +上图是我在掘金的第一篇文章 [优雅地使用 TypeScript 开发 React Native 应用](https://juejin.cn/post/6844903843155689486) 中的一条素质问答。问题就是有些库不是 TS 写的，也没提供类型声明该怎么办。从图中可见我当时的解决方法都是不可复用且不利他的。但这就是我这一年来处理该问题的常规手段。 + +![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/04f411da146740aab8f620337a592850~tplv-k3u1fbpfcp-watermark.image) + +## DefinitelyTyped + +像是 Node 有 NPM，Java 有 Maven，TypeScript 也有它的另一半，那就是号称 GitHub review 数量之最的 [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) 项目。 + +![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d503ee17f0ab45068a0d50a4d6f6034a~tplv-k3u1fbpfcp-watermark.image) + +在 TypeScript 大规模应用之前，社区已经有超过 90% 的顶级 JavaScript 库，或基于 Flow 编写的库（React 系）。如果没有 DefinitelyTyped 项目，这些库想要提供类型支持，无疑只有完全重构代码。这既不现实也没必要。 + +> 鉴于 DefinitelyTyped 的作用，我们说 DefinitelyTyped 让 TypeScript 再次伟大也不为过。 + +DefinitelyTyped 目前是由微软官方维护的开源项目，参与的方式和 Homebrew 差不多，都是基于 GitHub 的工作流: + +1. fork [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) 到自己的账号下 +2. 添加自己的包并编写类型声明 +3. 提交 PR +4. 官方 review 并合并发布到 NPM + +## 艰辛的贡献历程 + +1、检查是否已存在同名的包： + +```sh +npm info @types/tuya-panel-kit +``` + +2、安装 dts-gen： + +```sh +npm install -g dts-gen +``` + +3、生成新包 + +```sh +dts-gen --dt --name tuya-panel-kit --template module +``` + +4、格式化代码 + +```sh +npm run prettier -- --write types/tuya-panel-kit/**/*.ts +``` + +这一步务必要执行，因为 DefinitelyTyped 十分严格，格式不对过不了 CI。过不了 CI，就只配合机器人对话： + +![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/140adf442a17460aa845aef8e4b8ac18~tplv-k3u1fbpfcp-watermark.image) + +5、dtslint + +```sh +yarn lint tuya-panel-kit +``` + +这一步是最让人头大的一步，Definitely 的规则可谓严苛，真就对的起它的 SLOGAN： + +> The repository for high quality TypeScript type definitions + +我梳理了一下成功路上的绊脚石： + +1、 [Cannot find module 'csstype' when npm run lint package-name](https://github.com/DefinitelyTyped/DefinitelyTyped/issues/24788) + +这是一个流程 BUG，如果你的包依赖了 react，你需要执行 `cd types/react && npm install` 和 `cd ~/.dts/typescript-installs/3.2/ && npm install` + +2、如果你的包依赖了别的外部库，需要添加到 [microsoft/DefinitelyTyped-tools](https://github.com/microsoft/DefinitelyTyped-tools/pull/165/files) 项目中，否则 CI 不给过。 + +3、你的类型声明可能有很多不符合 dtslint 的标准，我看到有的包是在 `tslint.json` 中配置禁用掉部分规则，但是我做了尝试后被人工拒绝了。 + +![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fafa598fac2e4015ab496cc15fd94496~tplv-k3u1fbpfcp-watermark.image) + +然后我尝试在顶部加入 `// tslint:disable:max-line-length` 禁用规则，在说明原因后通过了 Review。就在发稿时，最新 PR 却因为一个禁用规则，被要求修改： + +![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/21a0b43a6f464c47a1b94a5fc7ed619f~tplv-k3u1fbpfcp-watermark.image) + +## 规范的重要性 + +刚开始时，这种严苛漫长的 review 流程着实让我头大。但在提过 4 个 PR 都被合并后，我发现 review 的人关心的是你为什么要这么写，是不是有什么不得已的苦衷，是否符合高质量的要求。 + +在参与 DefinitelyTyped 的协作中，我越来越发现规范的重要。如此体量的项目，如果没有严格有效的规范约束，势必会被开发者抛弃。那我们来看看 DefinitelyTyped 中是如何约束的： + +1. [dtslint](https://github.com/microsoft/dtslint) ：微软专门写的用来检验类型声明文件的工具。正是因为它，我做了大量优化工作。 +2. 机器人 🤖（dt-mergebot、dt-review-bot、typescript-bot-watchdog）：在你的代码通过所有规范之前，都是这些机器人在和你交互。大家感兴趣的话，之后我会单独出一篇解析的文章 +3. 尽职尽责的维护：虽然有时 review 速度明显很慢（可能因为国外疫情）。但是这些维护者真的是尽职尽责的 review 你的代码。机器再厉害也只是一个减少工作量的工具。我们应该致敬的还是这些为社区默默奉献的人。 diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\345\274\200\346\272\220\346\234\211\351\255\224\345\212\233-DolphinScheduler\345\222\214\346\210\221\347\232\204\345\274\200\346\272\220\345\216\206\347\250\213.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\345\274\200\346\272\220\346\234\211\351\255\224\345\212\233-DolphinScheduler\345\222\214\346\210\221\347\232\204\345\274\200\346\272\220\345\216\206\347\250\213.md" index 67376a3..d71393e 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\345\274\200\346\272\220\346\234\211\351\255\224\345\212\233-DolphinScheduler\345\222\214\346\210\221\347\232\204\345\274\200\346\272\220\345\216\206\347\250\213.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\345\274\200\346\272\220\346\234\211\351\255\224\345\212\233-DolphinScheduler\345\222\214\346\210\221\347\232\204\345\274\200\346\272\220\345\216\206\347\250\213.md" @@ -1,5 +1,5 @@ ## 开源有魔力-DolphinScheduler和我的开源历程 - + 鲍亮（leonbao），目前在易观数科大数据平台，负责平台建设工作，开源爱好者，DolphinScheduler PPMC， 一个有梦想的程序员。 ### 开源的思考 @@ -7,7 +7,7 @@ “What's your Legacy？” 易观的大家长Edward在一次季度总结中曾提到这样一句话，引发了我对于legacy的思考：写出一个让世界上更多人使用的软件，这也许是大多数程序员的初心和梦想，而能让这种想法实现的就是开源。站在2021年的里程碑旁回首过去，DolphinScheduler已经在这条路上奔跑了2年。就像电影里的镜头一样，阿甘坚持不懈跑步，周围聚集了越来越多的同行者，越来越多的人加入到开发者队伍中，开源的魔力正在让我们的梦想照进现实。新年伊始，我想回忆一下我们的开源之路。 2017年底，易观的千帆项目每天数百亿条数据，月活6.2亿，上万个任务需要处理近7PB的数据，用的调度系统，却年久失修，遇到问题就焦头烂额，对于新的需求也是束手无策，所以更换调度系统势在必行。众所周知，互联网公司用得最多的就是开源产品，我们调研了市面上主流的开源调度，比如oozie、Azkaban、Airflow等开源调度还有几个商业调度，均不能很好满足我们好用、易用的目标，所以站在众多开源产品的肩膀上，我们确定了以无中心为设计思想的架构。践行易观”数据能力平民化”的理念，最开始的时候我们就决定将此项目开源，故而将业务系统彻底与调度解耦，这也是最初设计的一个重要思想。 - + DS每个功能、每个流程的诞生都伴随着团队内的一场场激烈的思想碰撞、一次次不分昼夜的战斗。为了更快实现整个流程和验证产品的有效性，我们使用了最简单的数据库轮询方案，这也为提升并发量和减少资源消耗带来了不小的挑战，这两点和扩展性的优化也是DS将来最主要的任务。同时，也让我们认识到开源的魔力所在，只依靠一个小圈子做软件会产生局限性，有更多的开发者和思想交汇，产品才能更好得发展。 当第一个版本出来以后，产品名字确定为易调度（EasyScheduler），CTO郭大侠曾提出理念”开箱即用”，简而言之就是一个“易“字，另一方面，在易观的企业文化中，“易”也可以拆分成日月两字，象征着变化即永恒。经过一系列的测试，又历经3个月时间，终于把千帆的任务都转移到易调度里面。后面又从各大朋友圈里找了一些种子用户验证产品的功能。2019年3月，经过一系列重构，发布了第一个开源版本1.0，并在github上开放所有源代码。 @@ -15,15 +15,15 @@ ### 开放源代码=开源？ 开放源代码=开源？在了解ASF以前，我一直都是这么认为的。但其实，开源的目的不仅仅是能让更多人用上好的产品，更重要的是让更多的人来提高和完善这个调度系统，让它变得更易用，更好用，正所谓“独行快，众行远“。 - + 在开放源代码以后的一段时间内，我们发现一个问题：并没有多少开发者加入，也没有新的代码和新的思想出现。后来各种不放弃的执着让我们遇到了Apache Kylin现在的VP史少峰老师，史老师给我们引荐了我们现在的Mentor陈亮老师和Champion - 吴晟老师，Apache SkyWalking Founder。在一个阳光明媚的下午，吴晟老师给我们普及了apache 相关知识，为我们打开了开源世界的新大门。”Community > Code”，决策透明才能让更多人加入，进而形成一个公平、平等、精英治理的社区。我们确定了新的目标：加入apache，建立apache way的社区。 - + 加入apache当然没有那么容易，每个人对于apache way的理解也都不一样，在对项目的重构和升级过程中，大家又加入到充满激情的战斗中，纷纷在微信群里提出很多想法，这让我们认识到以前社区没有更多的开发者和思想，就是因为决策不透明。2019年8月底，经过前期准备，DS终于顺利进入孵化器，成为apache的孵化项目。 ### 我和社区的进步 在一年多的孵化期间，我们走过很多弯路，也学到了很多宝贵的经验，社区也取得了很大的进步。为了更好了解apache，我个人读了很多书，学习了其他项目的代码，了解了其他社区的构建方式，这让我受益匪浅。社区也是一样，从最开始的第一个版本需要4个月发出，到现在基本上每个月都会发一个版本；从最开始的不知道怎么使用邮件列表到现在的大事小情都想通过邮件列表来通知和讨论；从最开始的迷惑于license，到现在对各种license都略知一二。。。 - + 个人和社区都在不断发展，这一点正如ASF member姜宁老师的比喻：“在武林中立一个山头，带一群人成长“。每次通过邮件列表、issue、pull request的交流都像是在和不同的高手过招，在这个过程中，每个人都能学到新的招数，加深自己的内功。到目前为止，社区也贡献了很多有价值的功能，小到各种bug的fix、文档的注释, 大到各种重构、github action、k8s等等。 ### 呼唤更多同行者 diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\346\204\237\350\260\242Apache DolphinScheduler\357\274\214\350\256\251\346\210\221\347\232\204\351\235\222\346\230\245\346\260\270\344\270\215\350\244\252\350\211\262.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\346\204\237\350\260\242Apache DolphinScheduler\357\274\214\350\256\251\346\210\221\347\232\204\351\235\222\346\230\245\346\260\270\344\270\215\350\244\252\350\211\262.md" index 466dd11..9903215 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\346\204\237\350\260\242Apache DolphinScheduler\357\274\214\350\256\251\346\210\221\347\232\204\351\235\222\346\230\245\346\260\270\344\270\215\350\244\252\350\211\262.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\346\204\237\350\260\242Apache DolphinScheduler\357\274\214\350\256\251\346\210\221\347\232\204\351\235\222\346\230\245\346\260\270\344\270\215\350\244\252\350\211\262.md" @@ -1,80 +1,80 @@ -# 感谢Apache DolphinScheduler，让我的青春永不褪色 - -## 个人介绍 -我是李岗，是一名开源的爱好者和实践者，是Apache DolphinScheduler(incubator)的初始提交者和PPMC，也是Apache Local Community Beijing(ALC-Beijing)的member。 - -很开心、很庆幸自己可以成为开源领域的一员，更希望自己在未来不断地对开源持续探索、持续实践、持续分享，最终在开源领域贡献出自己的力量。 - -## 心路历程 - -一篇暴击心灵的文章、一场震撼人心的演讲都有可能成功让我们对开源产生好奇，产生兴趣，甚至一见钟情； - -另一方面，开源软件也在不断地改变我们的生活和工作，每一次开源软件的使用都可能让我惊叹开源软件的魅力，不知不觉我们就已经种下了一颗希望的种子，希望自己有一天也可以进入到开源领域，希望自己写的代码，做出的贡献可以影响到全世界更多的人。 - -当这些充满希望、充满梦想的种子在我们心中开始发芽的时候，总有一天他会呼唤着我们行动起来，加入到开源领域。 - -与很多开源爱好者相比，我是幸运的，在2017年的时候，为了更好地支撑易观千帆产品，公司需要自研一个分布式的任务调度系统来调度自身的任务，而易观的企业文化就是独立、勇敢、乐观、开放，那我们就决定做一个开源的系统，把代码开放出去，让更多的企业去使用，自此我就开始了自己的开源之旅。 - -万丈高楼平地起，从项目启动的那一刻，我们就确定了开源的目标，也从那一刻，开源的种子也种在了每个人的心中，它是一个使命，也是所有人的共识和承诺。 - -分秒必争，使命必达，所有人都整装待发，2019年3月，我们迎来了第一批的外部种子用户，正式发布第一个开源版本1.0.0。后续又逐步推出了1.0.1，1.0.2,1.0.3版本。 - -开源的种子已经种下，只有破土而出，才能扎根于大地，我们又开始了新的征程，我们要进入到全球最大的基金会，也就是Apache基金会。 - -目标是坚定地，征程却是充满了挑战，所幸最终我们始终坚持，迎来了曙光，迎来了2019年8月29日DolphinScheduler成功过入到Apache孵化器的消息。当看到邮件里不断地出现+1,+1,+1的时候，一切的付出都变为了收获，一切的汗水都化为了成长。 - - ## 开源能力 - -如果自己进入到开源领域是幸运的，那么当我首次从吴晟老师那里听到Apache Way的理念时，我一直在为Apache之道惊叹不已，我希望自己在未来可以去探索，去实践。 - -进入到Apache孵化器后，第一个里程碑就是要发布Apache Release，我自告奋勇充当了第一次的Release Manager，对于我印象最深的就是进行license的合规检查： - -“什么是二进制依赖和源码依赖，如何根据二进制依赖和源码依赖列出license?” - -“如何添加源码依赖？哪些license可以用于源码依赖？” - -“前端字体和图标是否符合license许可？” - -.......... - -因为Apache有着完善的法律框架和社会治理框架，对于license和商标有着近乎严苛的要求，在release的时候会进行非常仔细地检查，一开始真的没有太多的概念，而这些又特别的重要，否则就无法发版出来。我们的第一次发版就用了将近4个月的时间。 - -这里可以放一个链接(https://apache.org/legal/resolved.html#highlevel)，如果大家之前也没有接触过，可以看一下，我想就可以体会出我当时的心情。 - -经历过第一次Apache Release，自己也更加体会到了Apache之道的独特魅力，精英治理、社区驱动、共识决策、透明开放都深深的吸引着我，也正是这种吸引让我继续前行。 - -2020年2月，当我在apache community的dev邮件列表里看到ALC Beijing要成立的消息时， - -就开始回想自己的apache之路，有迷茫、有困惑、有挑战、有喜悦，它既是一段充满挑战的修行，也是一段浪漫的开源之旅。ALC Beijing的成立点燃了我内心的另外一盏灯，自己不仅仅是要做apache开源软件的参与者和贡献者，也希望可以成为一名Apache开源文化传播者。自己也特别有幸可以成为ALC Beijing的成员，在这里也收获了很多，因为在这里有很多的开源前辈，并且他们都非常热心，我们在2020的年终会议上也坚定了使命：帮助更多国内优秀的开源项目进入到Apache基金会，我们要让国内更多的项目走出去，走向全世界。 - -## 开源分享 - -Apache基金会是一个大家庭，非常的平等，非常的包容，我也希望可以把自己对开源的体会分享出去，传递给更多希望进入到开源的爱好者，在这里特别让我感触的是，我在南京开源供应链峰会开源-教育分论坛上进行的一次分享，我对教育有一种特别的情结，教育是伟大而神圣的事业，教育是为天地立心，为生民立命，为往圣继绝学，为万世开太平。我仿佛看到了冥冥之中的那一丝牵引，教育，开源，两个让我魂牵梦绕，荡气回肠的梦想，让我找到了一种新的责任，新的使命。 - -2020年自己也参与到了Outreachy活动，成为了一名mentor,我会与远在海外的实习生异步沟通，我们在slack交流，在邮件列表交流，我希望在这个短暂的实习旅途里他们不仅仅可以提升代码技能，也可以体会到开源异步协作，积累开源沟通技巧! - -教育，开源这两个响亮的名字再一次响彻我的心中，我推开窗户，抬头望了一下蔚蓝的天空，眼睛盯着蔚蓝天空的白云深处，我想我已经找到了让我飞翔和驰骋的地方。 - -## 开源总结 - -参与到开源项目是很好的去提升自己技术和架构能力的途径，因为Apache的开源项目都是公开透明的，在这里不仅是代码公开透明，技术方案讨论、决策也都是公开透明的，我们都可以从github的issue和邮件列表里看到。所以只要我们持续的参与开源项目，无论是从技术广度和深度都会与不错的提升。 - -除去技术，更多的是在社区里如何讨论，如何决策，因为这里遵循着共识的机制，能不投票就不要投票，所以我们会发现很多时候对于方案的推进会相对较慢，但是它的优势是方案的讨论会更加的全面，这里其实就相当于Peer Review，我们都在通过邮件去表达想法，它一定是更加的全面和优质的，那么共识其实就是在这里找到一个平衡，从而更加稳定的去推动项目健康的向前发展。 - -因为社区的本质是人，好的代码，好的架构，好的文档都是由每一位贡献者完成的，我们在通过协作的模式去改变着这个community. - -感谢易观，感谢CTO郭炜老师，让我可以幸运的成为一名全职的开源工程师。 - -感谢我们的导师吴晟老师、史少锋老师、陈亮老师、Furkan Kamaci老师和Kevin Ratnasekera老师，感谢导师们对我们的耐心指导和每一次Apache Release的细心检查。 - -感谢每一位使用过DS的用户、每一位参与过DS社区贡献的伙伴，感谢你们愿意牺牲自己宝贵的时间与我们一同前行！感谢姜宁老师、李建盛老师、孙金城老师和娟神以及所有指导和帮助过我的各位开源大咖和贡献者。 - -太多的感谢汇成一句话，感谢所有的开源爱好者组成了一个平等、开放、精英、共识的大家庭，可以让我们一起修行、一起成长、让我们在忙碌之余依然有着诗和远方。 - -## 共同期许 - -坚持自己的理想，追逐自己的梦想，并且探索自己独立的思想的时候，我们的青春就已经开始了，希望你与开源的遇见是青春的开始，或者是青春的延续！ - -我特别喜欢关于教育的一句话，教育是一棵树摇动着一棵树，一个灵魂感动着一个灵魂，其实开源也是如此，当我们作为新手时，社区会给我们提供很多帮助，而当我们不断地贡献，我们会获取到社区的信任，然后自己有了影响力，我们又开始去帮助更多的新加入开源的爱好者，这其实也是在不断地传递开源精神，传播知识和技能。 - -我也真心祝愿我们所有的开源爱好者都可以通过开源创造出一个属于自己的故事，这个故事关于独立、关于开放、关于挑战，我们选择了做一名斗士，挑战全新的异步协作模式、挑战自己的英语、挑战自己的演讲、挑战自己的写作，甚至我们会把开源当作一辈子的职业，我相信再过了5年，10年，我们一定感谢那个曾经的自己，当我们慕然回首，一定会对当初的那个自己说一句："谢谢你，我的开源，我的青春！" +# 感谢Apache DolphinScheduler，让我的青春永不褪色 + +## 个人介绍 +我是李岗，是一名开源的爱好者和实践者，是Apache DolphinScheduler(incubator)的初始提交者和PPMC，也是Apache Local Community Beijing(ALC-Beijing)的member。 + +很开心、很庆幸自己可以成为开源领域的一员，更希望自己在未来不断地对开源持续探索、持续实践、持续分享，最终在开源领域贡献出自己的力量。 + +## 心路历程 + +一篇暴击心灵的文章、一场震撼人心的演讲都有可能成功让我们对开源产生好奇，产生兴趣，甚至一见钟情； + +另一方面，开源软件也在不断地改变我们的生活和工作，每一次开源软件的使用都可能让我惊叹开源软件的魅力，不知不觉我们就已经种下了一颗希望的种子，希望自己有一天也可以进入到开源领域，希望自己写的代码，做出的贡献可以影响到全世界更多的人。 + +当这些充满希望、充满梦想的种子在我们心中开始发芽的时候，总有一天他会呼唤着我们行动起来，加入到开源领域。 + +与很多开源爱好者相比，我是幸运的，在2017年的时候，为了更好地支撑易观千帆产品，公司需要自研一个分布式的任务调度系统来调度自身的任务，而易观的企业文化就是独立、勇敢、乐观、开放，那我们就决定做一个开源的系统，把代码开放出去，让更多的企业去使用，自此我就开始了自己的开源之旅。 + +万丈高楼平地起，从项目启动的那一刻，我们就确定了开源的目标，也从那一刻，开源的种子也种在了每个人的心中，它是一个使命，也是所有人的共识和承诺。 + +分秒必争，使命必达，所有人都整装待发，2019年3月，我们迎来了第一批的外部种子用户，正式发布第一个开源版本1.0.0。后续又逐步推出了1.0.1，1.0.2,1.0.3版本。 + +开源的种子已经种下，只有破土而出，才能扎根于大地，我们又开始了新的征程，我们要进入到全球最大的基金会，也就是Apache基金会。 + +目标是坚定地，征程却是充满了挑战，所幸最终我们始终坚持，迎来了曙光，迎来了2019年8月29日DolphinScheduler成功过入到Apache孵化器的消息。当看到邮件里不断地出现+1,+1,+1的时候，一切的付出都变为了收获，一切的汗水都化为了成长。 + + ## 开源能力 + +如果自己进入到开源领域是幸运的，那么当我首次从吴晟老师那里听到Apache Way的理念时，我一直在为Apache之道惊叹不已，我希望自己在未来可以去探索，去实践。 + +进入到Apache孵化器后，第一个里程碑就是要发布Apache Release，我自告奋勇充当了第一次的Release Manager，对于我印象最深的就是进行license的合规检查： + +“什么是二进制依赖和源码依赖，如何根据二进制依赖和源码依赖列出license?” + +“如何添加源码依赖？哪些license可以用于源码依赖？” + +“前端字体和图标是否符合license许可？” + +.......... + +因为Apache有着完善的法律框架和社会治理框架，对于license和商标有着近乎严苛的要求，在release的时候会进行非常仔细地检查，一开始真的没有太多的概念，而这些又特别的重要，否则就无法发版出来。我们的第一次发版就用了将近4个月的时间。 + +这里可以放一个链接(https://apache.org/legal/resolved.html#highlevel)，如果大家之前也没有接触过，可以看一下，我想就可以体会出我当时的心情。 + +经历过第一次Apache Release，自己也更加体会到了Apache之道的独特魅力，精英治理、社区驱动、共识决策、透明开放都深深的吸引着我，也正是这种吸引让我继续前行。 + +2020年2月，当我在apache community的dev邮件列表里看到ALC Beijing要成立的消息时， + +就开始回想自己的apache之路，有迷茫、有困惑、有挑战、有喜悦，它既是一段充满挑战的修行，也是一段浪漫的开源之旅。ALC Beijing的成立点燃了我内心的另外一盏灯，自己不仅仅是要做apache开源软件的参与者和贡献者，也希望可以成为一名Apache开源文化传播者。自己也特别有幸可以成为ALC Beijing的成员，在这里也收获了很多，因为在这里有很多的开源前辈，并且他们都非常热心，我们在2020的年终会议上也坚定了使命：帮助更多国内优秀的开源项目进入到Apache基金会，我们要让国内更多的项目走出去，走向全世界。 + +## 开源分享 + +Apache基金会是一个大家庭，非常的平等，非常的包容，我也希望可以把自己对开源的体会分享出去，传递给更多希望进入到开源的爱好者，在这里特别让我感触的是，我在南京开源供应链峰会开源-教育分论坛上进行的一次分享，我对教育有一种特别的情结，教育是伟大而神圣的事业，教育是为天地立心，为生民立命，为往圣继绝学，为万世开太平。我仿佛看到了冥冥之中的那一丝牵引，教育，开源，两个让我魂牵梦绕，荡气回肠的梦想，让我找到了一种新的责任，新的使命。 + +2020年自己也参与到了Outreachy活动，成为了一名mentor,我会与远在海外的实习生异步沟通，我们在slack交流，在邮件列表交流，我希望在这个短暂的实习旅途里他们不仅仅可以提升代码技能，也可以体会到开源异步协作，积累开源沟通技巧! + +教育，开源这两个响亮的名字再一次响彻我的心中，我推开窗户，抬头望了一下蔚蓝的天空，眼睛盯着蔚蓝天空的白云深处，我想我已经找到了让我飞翔和驰骋的地方。 + +## 开源总结 + +参与到开源项目是很好的去提升自己技术和架构能力的途径，因为Apache的开源项目都是公开透明的，在这里不仅是代码公开透明，技术方案讨论、决策也都是公开透明的，我们都可以从github的issue和邮件列表里看到。所以只要我们持续的参与开源项目，无论是从技术广度和深度都会与不错的提升。 + +除去技术，更多的是在社区里如何讨论，如何决策，因为这里遵循着共识的机制，能不投票就不要投票，所以我们会发现很多时候对于方案的推进会相对较慢，但是它的优势是方案的讨论会更加的全面，这里其实就相当于Peer Review，我们都在通过邮件去表达想法，它一定是更加的全面和优质的，那么共识其实就是在这里找到一个平衡，从而更加稳定的去推动项目健康的向前发展。 + +因为社区的本质是人，好的代码，好的架构，好的文档都是由每一位贡献者完成的，我们在通过协作的模式去改变着这个community. + +感谢易观，感谢CTO郭炜老师，让我可以幸运的成为一名全职的开源工程师。 + +感谢我们的导师吴晟老师、史少锋老师、陈亮老师、Furkan Kamaci老师和Kevin Ratnasekera老师，感谢导师们对我们的耐心指导和每一次Apache Release的细心检查。 + +感谢每一位使用过DS的用户、每一位参与过DS社区贡献的伙伴，感谢你们愿意牺牲自己宝贵的时间与我们一同前行！感谢姜宁老师、李建盛老师、孙金城老师和娟神以及所有指导和帮助过我的各位开源大咖和贡献者。 + +太多的感谢汇成一句话，感谢所有的开源爱好者组成了一个平等、开放、精英、共识的大家庭，可以让我们一起修行、一起成长、让我们在忙碌之余依然有着诗和远方。 + +## 共同期许 + +坚持自己的理想，追逐自己的梦想，并且探索自己独立的思想的时候，我们的青春就已经开始了，希望你与开源的遇见是青春的开始，或者是青春的延续！ + +我特别喜欢关于教育的一句话，教育是一棵树摇动着一棵树，一个灵魂感动着一个灵魂，其实开源也是如此，当我们作为新手时，社区会给我们提供很多帮助，而当我们不断地贡献，我们会获取到社区的信任，然后自己有了影响力，我们又开始去帮助更多的新加入开源的爱好者，这其实也是在不断地传递开源精神，传播知识和技能。 + +我也真心祝愿我们所有的开源爱好者都可以通过开源创造出一个属于自己的故事，这个故事关于独立、关于开放、关于挑战，我们选择了做一名斗士，挑战全新的异步协作模式、挑战自己的英语、挑战自己的演讲、挑战自己的写作，甚至我们会把开源当作一辈子的职业，我相信再过了5年，10年，我们一定感谢那个曾经的自己，当我们慕然回首，一定会对当初的那个自己说一句："谢谢你，我的开源，我的青春！" diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\346\212\225\347\250\277\350\257\264\346\230\216.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\346\212\225\347\250\277\350\257\264\346\230\216.md" index d3d8209..0ad8aa1 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\346\212\225\347\250\277\350\257\264\346\230\216.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\346\212\225\347\250\277\350\257\264\346\230\216.md" @@ -1,22 +1,22 @@ -开源指北 1.0 即将上线，为了让更多开发者、开源小白更好的了解如何参与开源，欢迎有亲身参与过优秀开源项目的贡献者们在此分享自己的开源经验/故事 - -#### 投稿要求 -1. 你投稿的故事内需包含以下内容： -- 如何接触/了解到这个开源项目 -- 为什么决定参与贡献 -- 参与后的收获或提升（技术上或者生活上） -- 除以上内容之外，也欢迎为开源小白写上一句鼓励的话语（可选填，非必要内容） - -2. 投稿方式： -- 快捷入口>>[点我投稿故事](https://gitee.com/gitee-community/opensource-guide/new/master/%E5%BC%80%E6%BA%90%E6%95%85%E4%BA%8B) - -3. 注意 -- 标题需包含项目名，后缀为“.md ”，例如：子知鱼否与[开源/开源项目名]的故事.md -- 故事字数：不少于200 字 -- 广告、灌水文章不予收录 -- 开源指北 & Gitee 具有故事宣传、使用权 - -#### 参与奖励 -1. 故事被收录（合并PR）后，你将获得 Gitee 马克杯一份 -![输入图片说明](https://images.gitee.com/uploads/images/2021/0115/145253_2c255404_1899542.png "陶瓷杯.png") +开源指北 1.0 即将上线，为了让更多开发者、开源小白更好的了解如何参与开源，欢迎有亲身参与过优秀开源项目的贡献者们在此分享自己的开源经验/故事 + +#### 投稿要求 +1. 你投稿的故事内需包含以下内容： +- 如何接触/了解到这个开源项目 +- 为什么决定参与贡献 +- 参与后的收获或提升（技术上或者生活上） +- 除以上内容之外，也欢迎为开源小白写上一句鼓励的话语（可选填，非必要内容） + +2. 投稿方式： +- 快捷入口>>[点我投稿故事](https://gitee.com/gitee-community/opensource-guide/new/master/%E5%BC%80%E6%BA%90%E6%95%85%E4%BA%8B) + +3. 注意 +- 标题需包含项目名，后缀为“.md ”，例如：子知鱼否与[开源/开源项目名]的故事.md +- 故事字数：不少于200 字 +- 广告、灌水文章不予收录 +- 开源指北 & Gitee 具有故事宣传、使用权 + +#### 参与奖励 +1. 故事被收录（合并PR）后，你将获得 Gitee 马克杯一份 +![输入图片说明](https://images.gitee.com/uploads/images/2021/0115/145253_2c255404_1899542.png "陶瓷杯.png") 2. 所有被收录的故事将会同步至即将上线的「开源指北」Pages 内，更有机会获得 Gitee x OSCHINA 官方微博、微信公众号等渠道推荐，让更多人可以看到你的故事。 \ No newline at end of file diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\350\246\201\346\207\202\345\276\227\350\210\215\345\276\227\347\232\204UMS\344\270\216JAP\347\232\204\346\225\205\344\272\213.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\350\246\201\346\207\202\345\276\227\350\210\215\345\276\227\347\232\204UMS\344\270\216JAP\347\232\204\346\225\205\344\272\213.md" index 10624f0..39b6364 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\350\246\201\346\207\202\345\276\227\350\210\215\345\276\227\347\232\204UMS\344\270\216JAP\347\232\204\346\225\205\344\272\213.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\350\246\201\346\207\202\345\276\227\350\210\215\345\276\227\347\232\204UMS\344\270\216JAP\347\232\204\346\225\205\344\272\213.md" @@ -1,25 +1,25 @@ -## 为什么决定参与贡献 -> 1. 2020 注定是不平凡的一年, 疫情让我有更多的空余时间; -> 2. 为了给自己身上增加一点光环; -> 3. 平时每次做新项目项目都需要搞一套用户管理系统, 虽然可以搬砖, 但也繁琐, 想着正好有空, 何不自己写一套用户管理脚手架, 省的以后搬砖; 就这样有了我的开源项目[UMS](https://gitee.com/pcore/UMS ). - -#### 项目1: [UMS](https://gitee.com/pcore/UMS ) 项目: https://gitee.com/pcore/UMS -> 用户管理脚手架集成：用户密码登录、手机登录、支持所有 JustAuth 支持的第三方授权登录、验证码、基于 RBAC 的访问权限控制功能, 支持多租户、JWT、SLF4J-MDC、签到等功能。 -> 你只需要实现业务端的几个接口 **用户服务, 短信发送服务, 获取角色权限服务, JWT(可以配置是否开启)服务** 几个 API 接口就可以实现上述功能. -> 可通过属性配置高度自定义, UMS 是非侵入式的, 与业务高度解耦; 只需要专注于自己的业务逻辑。 - -#### 项目2: [JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 项目: https://gitee.com/pcore/just-auth-spring-security-starter -> Spring security 与 JustAuth 集成: 支持所有 justAuth 支持的第三方登录， -> [JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 项目已加入 [JustAuth](https://gitee.com/justauth ) 大家庭. - -## 参与后的收获或提升 -> 参与开源后认识了很多小伙伴, 有参与 [UMS](https://gitee.com/pcore/UMS ) 和 [JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 开源的, -> 有使用 [UMS](https://gitee.com/pcore/UMS ) 和 [JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 的小伙伴, -> 以及加入了 [JustAuth](https://gitee.com/justauth ) 这个大家庭. -> 开源表面上看只有付出没有回报, 其实通过开源潜移默化的会提升自己的技术与视野, 还有机会与朋友圈, 本人也因为 [UMS](https://gitee.com/pcore/UMS ) -> 项目认识了一个小伙伴, 加入了他的创业公司. 说了这么多就一句话: 我为人人, 人人为我. - -## 如何接触/了解到这个开源项目 -> 通过第二个项目[JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 认识了 **GVP** 项目 [JustAuth](https://gitee.com/justauth ) 的作者, 也加入 [JustAuth](https://gitee.com/justauth ) 大家庭, [JustAuth](https://gitee.com/justauth ) 作者今天刚推出了新的开源项目 [JAP](https://gitee.com/fujieid/jap) 我也成为其中的一员, 希望 2021 年 [JAP](https://gitee.com/fujieid/jap) 成为又一个 **GVP** 项目. - +## 为什么决定参与贡献 +> 1. 2020 注定是不平凡的一年, 疫情让我有更多的空余时间; +> 2. 为了给自己身上增加一点光环; +> 3. 平时每次做新项目项目都需要搞一套用户管理系统, 虽然可以搬砖, 但也繁琐, 想着正好有空, 何不自己写一套用户管理脚手架, 省的以后搬砖; 就这样有了我的开源项目[UMS](https://gitee.com/pcore/UMS ). + +#### 项目1: [UMS](https://gitee.com/pcore/UMS ) 项目: https://gitee.com/pcore/UMS +> 用户管理脚手架集成：用户密码登录、手机登录、支持所有 JustAuth 支持的第三方授权登录、验证码、基于 RBAC 的访问权限控制功能, 支持多租户、JWT、SLF4J-MDC、签到等功能。 +> 你只需要实现业务端的几个接口 **用户服务, 短信发送服务, 获取角色权限服务, JWT(可以配置是否开启)服务** 几个 API 接口就可以实现上述功能. +> 可通过属性配置高度自定义, UMS 是非侵入式的, 与业务高度解耦; 只需要专注于自己的业务逻辑。 + +#### 项目2: [JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 项目: https://gitee.com/pcore/just-auth-spring-security-starter +> Spring security 与 JustAuth 集成: 支持所有 justAuth 支持的第三方登录， +> [JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 项目已加入 [JustAuth](https://gitee.com/justauth ) 大家庭. + +## 参与后的收获或提升 +> 参与开源后认识了很多小伙伴, 有参与 [UMS](https://gitee.com/pcore/UMS ) 和 [JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 开源的, +> 有使用 [UMS](https://gitee.com/pcore/UMS ) 和 [JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 的小伙伴, +> 以及加入了 [JustAuth](https://gitee.com/justauth ) 这个大家庭. +> 开源表面上看只有付出没有回报, 其实通过开源潜移默化的会提升自己的技术与视野, 还有机会与朋友圈, 本人也因为 [UMS](https://gitee.com/pcore/UMS ) +> 项目认识了一个小伙伴, 加入了他的创业公司. 说了这么多就一句话: 我为人人, 人人为我. + +## 如何接触/了解到这个开源项目 +> 通过第二个项目[JustAuth-security](https://gitee.com/pcore/just-auth-spring-security-starter ) 认识了 **GVP** 项目 [JustAuth](https://gitee.com/justauth ) 的作者, 也加入 [JustAuth](https://gitee.com/justauth ) 大家庭, [JustAuth](https://gitee.com/justauth ) 作者今天刚推出了新的开源项目 [JAP](https://gitee.com/fujieid/jap) 我也成为其中的一员, 希望 2021 年 [JAP](https://gitee.com/fujieid/jap) 成为又一个 **GVP** 项目. + ## 2021 加油! \ No newline at end of file diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\350\275\273\347\274\226\347\250\213\344\270\216CRMEB\346\211\223\351\200\232\347\211\210\347\232\204\346\225\205\344\272\213.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\350\275\273\347\274\226\347\250\213\344\270\216CRMEB\346\211\223\351\200\232\347\211\210\347\232\204\346\225\205\344\272\213.md" index eb3a98e..686799e 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\350\275\273\347\274\226\347\250\213\344\270\216CRMEB\346\211\223\351\200\232\347\211\210\347\232\204\346\225\205\344\272\213.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\350\275\273\347\274\226\347\250\213\344\270\216CRMEB\346\211\223\351\200\232\347\211\210\347\232\204\346\225\205\344\272\213.md" @@ -1,6 +1,6 @@ -> 第一次听CRMEB这个名字还是一个朋友说用这个开源仓库为客户定制二开了一个项目，赚了多少多少钱，这多少让我有些嫉妒。 -刚听到这个名字时十分好奇，是CRM客户关系管理系统吗？但为什么小程序商城可以用这个来定制开发？怀着这样的一个好奇心，去搜索引擎搜索，去Gitee搜索开源项目，一看Star量已达5k之高，再看代码质量以及UI设计确实做的非常棒，看官方的简介是将客户关系管理与社交电商营销系统深度集成的一款开源系统，打通了H5端和小程序端数据互通的问题，确实很有吸引力！ - -基于这样的一个机遇，自己手里的一些商业项目也转型用到了这个开源仓库，在使用过程中也遇到一些小的bug，在帮客户解决这些bug的时候就顺手将处理的代码提交给了开源作者，惊喜的是作者竟然真的收录我提交的代码，这让我收获了满满的成就感，本来个人的技术是偏于后端PHP的，对前后端分离技术实践较少，但庆幸的是这套开源系统是基于前后端分离开发，在使用过程中多少是有一些障碍，正是因为这些障碍，让我不断的学习新技术，去了解前端非常优秀的vuejs框架，自己在前端技术上有了质的提升，这套系统确实减少了我重复造轮子的工作量，也让我学习了很多！ - +> 第一次听CRMEB这个名字还是一个朋友说用这个开源仓库为客户定制二开了一个项目，赚了多少多少钱，这多少让我有些嫉妒。 +刚听到这个名字时十分好奇，是CRM客户关系管理系统吗？但为什么小程序商城可以用这个来定制开发？怀着这样的一个好奇心，去搜索引擎搜索，去Gitee搜索开源项目，一看Star量已达5k之高，再看代码质量以及UI设计确实做的非常棒，看官方的简介是将客户关系管理与社交电商营销系统深度集成的一款开源系统，打通了H5端和小程序端数据互通的问题，确实很有吸引力！ + +基于这样的一个机遇，自己手里的一些商业项目也转型用到了这个开源仓库，在使用过程中也遇到一些小的bug，在帮客户解决这些bug的时候就顺手将处理的代码提交给了开源作者，惊喜的是作者竟然真的收录我提交的代码，这让我收获了满满的成就感，本来个人的技术是偏于后端PHP的，对前后端分离技术实践较少，但庆幸的是这套开源系统是基于前后端分离开发，在使用过程中多少是有一些障碍，正是因为这些障碍，让我不断的学习新技术，去了解前端非常优秀的vuejs框架，自己在前端技术上有了质的提升，这套系统确实减少了我重复造轮子的工作量，也让我学习了很多！ + 开源是一件非常有意义的事情，正因为这个开源项目给了我很大的启发，我自己也在着手开发一个开源项目，希望把自己多年来积累的经验融入到这个开源项目，帮助更多人，也满足了自己在技术世界遨游的小梦想！ \ No newline at end of file diff --git "a/\345\274\200\346\272\220\346\225\205\344\272\213/\351\233\252\345\261\261\345\207\214\347\213\220\344\270\216\345\274\200\346\272\220\346\214\207\345\214\227\347\232\204\346\225\205\344\272\213.md" "b/\345\274\200\346\272\220\346\225\205\344\272\213/\351\233\252\345\261\261\345\207\214\347\213\220\344\270\216\345\274\200\346\272\220\346\214\207\345\214\227\347\232\204\346\225\205\344\272\213.md" index 2882c1e..c96bdea 100644 --- "a/\345\274\200\346\272\220\346\225\205\344\272\213/\351\233\252\345\261\261\345\207\214\347\213\220\344\270\216\345\274\200\346\272\220\346\214\207\345\214\227\347\232\204\346\225\205\344\272\213.md" +++ "b/\345\274\200\346\272\220\346\225\205\344\272\213/\351\233\252\345\261\261\345\207\214\347\213\220\344\270\216\345\274\200\346\272\220\346\214\207\345\214\227\347\232\204\346\225\205\344\272\213.md" @@ -1,152 +1,152 @@ -## 我与开源指北的故事 - -### 前言 - -#### 关于我 - -我是`雪山凌狐`，一位希望对这个世界做点贡献的开源爱好者。擅长 python、易语言等的开发和教学。目前致力于帮助更多的小白开发者或业余爱好者踏入编程的大门，有自己的编程教学网站。在国外留学的时候，就有接触到开源的思想，对此很是认可，虽然目前自己的开源项目经验还不够充足，但仍在不断努力中。我希望能通过我的故事，影响到屏幕前的你，鼓起勇气加入到开源的行列中，为开源世界再抹上新的一束光。 - -#### 关于开源指北项目 - -`开源指北`是由 Gitee 官方发起的电子书编写项目，因为一直有在开发者们中听到 **「我有想参与开源，但我不知道怎么做」** 这样的声音，网上搜索相关的资料也是五花八门、不成体系的，于是 Gitee 也以开源的形式，邀请众多开源爱好者一起分享经验，分享自己对开源的认识和参与开源实践的经历，为那些想参与开源的开发者们提供一个丰富详实的操作指南，让更多开发者认识开源、参与开源、爱上开源。 - -作为一份给开源新手的保姆级开源百科，`开源指北`力求严谨、详实，由爱好者拟稿编写，再由业界专家组审校完成，是业界不可多得的一份中文开源百科书，亦或许成为你未来学习开源路上不可不读的书籍之一。 - -点击学习开源指北：[开源指北](https://gitee.com/gitee-community/opensource-guide) - -### 邂逅开源指北 - -我与`开源指北`的故事，始于 2020 年的 10 月底，那时候正巧在 Gitee 弄我自己的项目，突然看到 Gitee 的一个悬浮图片广告出现在角落（还好我没开悬浮广告的屏蔽工具，不然要跟这个项目擦肩而过了哈哈），写的大概内容是：《开源指北》电子书，邀请广大开发者、开源爱好者、开源社区来共同编写。还有精美好礼哦！ - -### 为什么决定参与贡献 - -期初我对于这类广告还是不怎么在意的，毕竟是官方的项目嘛，我的开源经验也不足，或许我写的东西入不了官方的法眼（官方：我有那么凶神恶煞么？）。不过当时有点时间，对于这样的项目还是有点兴趣的，想着以后别的大神写好了要不来观摩学习一下？于是戳开了悬浮广告链接。我没有想到的是，就是这么个简单的决定，改变了我未来的人生之路。 - -这也是我第一次去查看一个还没写好的开源电子书的项目，首先他们的协作形式就很值得我学习。那就是在 Issues 中写上一个个章节的内容和大纲供人认领，然后在具体协作时，通过 Gitee 独特的轻量 PR 的形式（也就是无需先 Fork 项目即可提交 PR）来进行稿件的提交。 - -我呢估计也是个 README 的颜控，接下来看到的是开源指北精美的 README 文件，当然要细细的品读一番。 - -接下来，我就看到了这么一段对参与编写者的要求： - -![参与编写者要求](https://images.gitee.com/uploads/images/2021/0117/135029_c93ca9b3_1277510.png "image-20210117101655413.png") - -我虽然认可开源理念，但确实感觉自己还没拥有太多的开源项目协作经验，所以第一点或许是不满足的。但是我发现，第二点我满足呀！找资料和编写文档的能力还是在的嘛。毕竟也是写过众多教案的人，对于要把一个复杂的事情给小白讲清楚，这一点我还是有信心的。 - -接下来我去看了一下编写奖励： - -![编写奖励](https://images.gitee.com/uploads/images/2021/0117/135109_5981e394_1277510.png "image-20210117102033342.png") - -哇，还有证书，并且是官方证书，还能署名贡献者！还有周边T恤诶！（最一开始的确是冲着证书和T恤去的哈哈）虽然这个奖励成本并不算很高，但是可以帮助到开源新手这一点可跟我想要致力于帮助到更多的开发者的想法太契合了！ - -于是我开始到 Issues 里面看，我能写什么章节。选择的时候也有些害怕，怕里面要写的内容都需要非常专业的经验才能编写的话，那我可真就是爱莫能助了。找着找着，发现有一个章节感觉自己能写得来：[尝试参与开源：提交第一个 Issue](https://gitee.com/gitee-community/opensource-guide/issues/I1TTV7)。我想，写好一个章节就好，在精而不贪多，于是就决定写这个了！ - -在 Issues 中报名之后，很快得到了官方的回应，可以开始编写了！于是加了 `Gitee小助手` 的微信号，意外之喜是，小助手相当的热情，让我觉得这是一个充满活力的企业，我想这一定是很有发展前景的，于是更坚定了我一定要好好把认领的章节给写好，帮助到后面的朋友的心。 - -### 编写之路漫漫 - -#### 编写准备 - -根据我的教学经验，我认为一个好的教程手册，应该致力于让读者看得懂，记得牢，而不是作者的自嗨。因此我在编写时也努力让自己的表述更加平实，让没有基础或者基础薄弱的朋友也不至于听不明白，从而放弃。 - -之前我说过，我对于开源的经验还不算特别的充足，因此为了避免我的内容权威性不足，我开始查阅资料，我选择写的是 `如何提交一个 Issue` 的章节，于是我把关于 Issue 对应的一些有价值的资料都看了个遍，同时，也参考了一下 Github 对于 Issue 帮助文档的英文资料。对于一些比较有价值的资料，我还反复看了两三遍。 - -由于这是一个有关操作指导的章节，跟具体的操作是脱不了关系的。于是我在 Gitee 建了一个自己的测试项目，针对找的资料在 Gitee 上一一测试比对，并将检查出的 Gitee 跟资料中的不同之处标出，避免最后编写的内容与 Gitee 上的实际使用体验不符。 - -![Gitee测试项目](https://images.gitee.com/uploads/images/2021/0117/135151_2f25f98a_1277510.png "image-20210117133535739.png") - -#### 初尝甜头 - -充分的了解让我对于这块的知识有了更多的把握，初始工作准备了 2~3 天后，我终于开始动笔了。首先需要完成的便是官方建议的大纲中建议的小节内容。 - -这里我编写的原则是在参考资料的基础上，一些概念解释或表述会基于自己对于 Issue 的理解来展开，尽可能让人快速理解这是一个什么东西，以及如何快速使用。 - -编写完成后，我开始提交我的第一稿稿件（因为担心到初稿截止日了没提交的不算数了，所以先提交第一稿再说），这时，我对于 PR 协作也是没太多经验的，不过想着总要跟仓库所有者讲明白我这次提交了什么，下次准备写啥来方便人家审核吧，于是就提了这么一个初稿 PR：[!30 【轻量级 PR】：update 第三部分——尝试参与开源/提交第一个 Issue.md.第一稿，后续还有补充，详见扩展信息](https://gitee.com/gitee-community/opensource-guide/pulls/30) - -![第一个PR](https://images.gitee.com/uploads/images/2021/0117/135236_bd749e58_1277510.png "image-20210117114636492.png") - -没想到，PR 说明内容竟成为之前提交过 PR 的作者里面最详实的，还触发了官方的隐藏奖励，官方直接在编写群里表扬了我： - -![触发隐藏奖励](https://images.gitee.com/uploads/images/2021/0117/135308_f229edb9_1277510.png "image-20210117115256768.png") - -一个开源爱好者的快乐就是这么简单，一个简单的肯定，足以让他激发更大的热情。这次，Gitee 官方的热情真的让我受宠若惊，于是我决定，后面的内容也要尽快完善完整，决不能让嗷嗷待哺的 Gitee 等久了。 - -#### 完善补充 - -于是我利用工作之余的时间，继续完善补充内容，在编写的过程中，遇到的一些关于在 Gitee 中使用 Issue 的疑问（网上找不到答案，官方的文档也没写的那种），还得到了 Gitee 工作人员的耐心解答和截图支持，在此对他们表示感谢。几天后，新鲜出炉，内容详实的共 5 稿初稿，终于在第一阶段编写的截止日期前完成了。同时这份初稿也成为了后来专家组审校的过程中，一刀未剪，一稿通过的初稿，在此特别感谢专家组的肯定。 - -在编写完自己认领的章节的同时，我也在思考是否能为《开源指北》做更多的事情，比如是否可以根据编写规范，给其他已经编写好的内容改改错别字，通顺下语句或者优化排版等等。 - -说干就干！利用工作之余的时间，我将当时已经提交合并的所有章节内容都看了一遍，通读别的大神的作品学习的同时，修改了许多小细节内容。毕竟朋友们都说，我的性格适合做需要细心的活嘛。通过通力协作，我有了很大的成长和提高。 - -#### 阅读我主编的章节 - -如果你看到这里对我编写的内容感兴趣，欢迎到这里阅读我主要编写的章节： - -[第 6 小节：提交第一个 Issue](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%AC%AC%E4%B8%89%E9%83%A8%E5%88%86%EF%BC%9A%E5%B0%9D%E8%AF%95%E5%8F%82%E4%B8%8E%E5%BC%80%E6%BA%90/%E7%AC%AC%206%20%E5%B0%8F%E8%8A%82%EF%BC%9A%E6%8F%90%E4%BA%A4%E7%AC%AC%E4%B8%80%E4%B8%AA%20Issue.md) - -### 参与后的收获或提升 - -#### 技术精进 - -在技术方面，通过全程参与开源项目，对于整体项目流程有了很细致的了解。 - -同时为了写好自己认领的章节，我也对 Issue 相关的内容做了详细的理论调研。 - -单单是这样还不够，我还在 Gitee 建了个自己的仓库，对于学到的理论知识，都一一在仓库中实际测试之后，才会写到自己认领的章节中，对自己负责，也对未来阅读这本书籍的开源爱好者们负责。 - -即使现在在编写完成这个章节的内容几个月之后，我还是清晰的记得当初学过和记录过的那些知识要点，它就好像树根一样，深深的扎根在我的脑海里了，这对我未来持续参与开源贡献，是非常有帮助的。 - -感谢这样的经历，又让我成长了许多。 - -#### 广交新友 - -**线上** - -真的非常喜欢开放包容的开源社区的氛围，至少 Gitee 的`开源指北`社区是这样的，有问题，大家摆事实讲道理，评论都是一大段一大段的，跟别人进行思想的碰撞其实是一件很爽的事情。因为发一条评论是经过深思熟虑的，需要好好组织语言来表达自己的观点，因此感觉发的每条技术评论都是文思泉涌的。这对于需要讨论的技术问题的进一步明确，甚至达成共识，非常有帮助。 - -在咱们编写小分队的微信群中，也结识了许多志同道合的小伙伴，许多开源大佬，未来我还需要多多向他们学习，向他们看齐，多为开源社区做贡献。 - -**线下** - -2020 年 12 月 27 号下午，深圳国际开源谷开源中国办公室举办了年度的 `Gitee Day` 线下活动，多次跟小助手说我要去你们办公的地方看看的我报名参与了此次活动，并有幸结实了一干开源大佬。 - -![Gitee Day 1](https://images.gitee.com/uploads/images/2021/0117/135639_bcc762e2_1277510.png "image-20210117123912367.png") - -活动结束，还有幸参与了 Gitee 大家庭和开源分享嘉宾大佬们的晚宴，这对我来说真的是很珍贵的经历和宝贵的财富。晚宴上，我致力的教学布道的事情也得到了大佬们的认可和肯定，这对我来说是莫大的鼓励。 - -![Gitee Day 2](https://images.gitee.com/uploads/images/2021/0117/140033_0d359644_1277510.jpeg "image-20210117123930028.jpg") - -我梦想着，未来在开源大佬的席位上，也有我的一席之地吧。 - -#### 奖品满载而归 - -Gitee 真是一个不吝啬发奖品的好公司，由于我的积极贡献，前前后后获得了超多 Gitee 发的礼物，包括精致的证书、T恤、马克杯、鼠标垫、手机挂环、数据线、精美笔记本、双肩背包、实用手提包等等，搞得 `Gitee小助手` 都在说：你要凑个全套周边吗？ - -![T恤](https://images.gitee.com/uploads/images/2021/0117/140112_5d07dcb4_1277510.jpeg "image-20210117124529354.jpg") - -![双肩背包](https://images.gitee.com/uploads/images/2021/0117/140126_88806c64_1277510.jpeg "image-20210117124551892.jpg") - -![证书](https://images.gitee.com/uploads/images/2021/0117/140141_14b080ec_1277510.png "image-20210117124619480.png") - -![精美笔记本](https://images.gitee.com/uploads/images/2021/0117/140156_6dd035e9_1277510.png "image-20210117124625835.png") - -### 写给想参与开源的你 - -故事的最后，让我来给想参与开源的你说说心里话。 - -**“开源，用你的力量来帮助到更多的人。”** - -对于我接触到的生活工作圈子来说，参与开源贡献的人是比较少的，很多都是企业级别开发的项目，有着较高的保密需求，因此企业内的项目私有化的占比较大。但我看好开源社区，看好开源文化。如何在未来引领更多新的开发者进入开源的世界，为开源，为世界作出一点自己新的贡献，是我未来努力发展的方向。 - -这个世界未来发展的技术和力量一定是大家一点一滴筑成的。开源协作给了你一个很好的机会，跟全球开发者一道让这个世界变得更美好。当你和社区的努力给成千上万的人带来实质性的帮助的时候，那种成就感是无与伦比的。 - -而看完我的故事后，不要怕，赶紧去行动起来，参与到开源贡献当中，相信你会有不一样的技术收获。 - -![哈佛学习金字塔](https://images.gitee.com/uploads/images/2021/0117/140229_324697ff_1277510.png "image-20210117132020298.png") - -不要担心自己的技术和贡献分享出去之后只是为别人做了嫁衣，`哈佛学习金字塔`告诉你，当你学到知识，最终实现`转教别人/立即应用`的程度时，你属于主动学习，知识的吸收效率是最高的。做出贡献，不仅是对项目做出了帮助，还练习了你编写代码的能力，训练了你与人协作的能力，对你的个人成长性极高。 - -因此，不要吝啬对开源社区做出的奉献，这个世界很多东西都是守恒的，你做出了贡献，开源世界终将回馈于你。 - -加油吧朋友！我在开源世界里等待你的到来！ - +## 我与开源指北的故事 + +### 前言 + +#### 关于我 + +我是`雪山凌狐`，一位希望对这个世界做点贡献的开源爱好者。擅长 python、易语言等的开发和教学。目前致力于帮助更多的小白开发者或业余爱好者踏入编程的大门，有自己的编程教学网站。在国外留学的时候，就有接触到开源的思想，对此很是认可，虽然目前自己的开源项目经验还不够充足，但仍在不断努力中。我希望能通过我的故事，影响到屏幕前的你，鼓起勇气加入到开源的行列中，为开源世界再抹上新的一束光。 + +#### 关于开源指北项目 + +`开源指北`是由 Gitee 官方发起的电子书编写项目，因为一直有在开发者们中听到 **「我有想参与开源，但我不知道怎么做」** 这样的声音，网上搜索相关的资料也是五花八门、不成体系的，于是 Gitee 也以开源的形式，邀请众多开源爱好者一起分享经验，分享自己对开源的认识和参与开源实践的经历，为那些想参与开源的开发者们提供一个丰富详实的操作指南，让更多开发者认识开源、参与开源、爱上开源。 + +作为一份给开源新手的保姆级开源百科，`开源指北`力求严谨、详实，由爱好者拟稿编写，再由业界专家组审校完成，是业界不可多得的一份中文开源百科书，亦或许成为你未来学习开源路上不可不读的书籍之一。 + +点击学习开源指北：[开源指北](https://gitee.com/gitee-community/opensource-guide) + +### 邂逅开源指北 + +我与`开源指北`的故事，始于 2020 年的 10 月底，那时候正巧在 Gitee 弄我自己的项目，突然看到 Gitee 的一个悬浮图片广告出现在角落（还好我没开悬浮广告的屏蔽工具，不然要跟这个项目擦肩而过了哈哈），写的大概内容是：《开源指北》电子书，邀请广大开发者、开源爱好者、开源社区来共同编写。还有精美好礼哦！ + +### 为什么决定参与贡献 + +期初我对于这类广告还是不怎么在意的，毕竟是官方的项目嘛，我的开源经验也不足，或许我写的东西入不了官方的法眼（官方：我有那么凶神恶煞么？）。不过当时有点时间，对于这样的项目还是有点兴趣的，想着以后别的大神写好了要不来观摩学习一下？于是戳开了悬浮广告链接。我没有想到的是，就是这么个简单的决定，改变了我未来的人生之路。 + +这也是我第一次去查看一个还没写好的开源电子书的项目，首先他们的协作形式就很值得我学习。那就是在 Issues 中写上一个个章节的内容和大纲供人认领，然后在具体协作时，通过 Gitee 独特的轻量 PR 的形式（也就是无需先 Fork 项目即可提交 PR）来进行稿件的提交。 + +我呢估计也是个 README 的颜控，接下来看到的是开源指北精美的 README 文件，当然要细细的品读一番。 + +接下来，我就看到了这么一段对参与编写者的要求： + +![参与编写者要求](https://images.gitee.com/uploads/images/2021/0117/135029_c93ca9b3_1277510.png "image-20210117101655413.png") + +我虽然认可开源理念，但确实感觉自己还没拥有太多的开源项目协作经验，所以第一点或许是不满足的。但是我发现，第二点我满足呀！找资料和编写文档的能力还是在的嘛。毕竟也是写过众多教案的人，对于要把一个复杂的事情给小白讲清楚，这一点我还是有信心的。 + +接下来我去看了一下编写奖励： + +![编写奖励](https://images.gitee.com/uploads/images/2021/0117/135109_5981e394_1277510.png "image-20210117102033342.png") + +哇，还有证书，并且是官方证书，还能署名贡献者！还有周边T恤诶！（最一开始的确是冲着证书和T恤去的哈哈）虽然这个奖励成本并不算很高，但是可以帮助到开源新手这一点可跟我想要致力于帮助到更多的开发者的想法太契合了！ + +于是我开始到 Issues 里面看，我能写什么章节。选择的时候也有些害怕，怕里面要写的内容都需要非常专业的经验才能编写的话，那我可真就是爱莫能助了。找着找着，发现有一个章节感觉自己能写得来：[尝试参与开源：提交第一个 Issue](https://gitee.com/gitee-community/opensource-guide/issues/I1TTV7)。我想，写好一个章节就好，在精而不贪多，于是就决定写这个了！ + +在 Issues 中报名之后，很快得到了官方的回应，可以开始编写了！于是加了 `Gitee小助手` 的微信号，意外之喜是，小助手相当的热情，让我觉得这是一个充满活力的企业，我想这一定是很有发展前景的，于是更坚定了我一定要好好把认领的章节给写好，帮助到后面的朋友的心。 + +### 编写之路漫漫 + +#### 编写准备 + +根据我的教学经验，我认为一个好的教程手册，应该致力于让读者看得懂，记得牢，而不是作者的自嗨。因此我在编写时也努力让自己的表述更加平实，让没有基础或者基础薄弱的朋友也不至于听不明白，从而放弃。 + +之前我说过，我对于开源的经验还不算特别的充足，因此为了避免我的内容权威性不足，我开始查阅资料，我选择写的是 `如何提交一个 Issue` 的章节，于是我把关于 Issue 对应的一些有价值的资料都看了个遍，同时，也参考了一下 Github 对于 Issue 帮助文档的英文资料。对于一些比较有价值的资料，我还反复看了两三遍。 + +由于这是一个有关操作指导的章节，跟具体的操作是脱不了关系的。于是我在 Gitee 建了一个自己的测试项目，针对找的资料在 Gitee 上一一测试比对，并将检查出的 Gitee 跟资料中的不同之处标出，避免最后编写的内容与 Gitee 上的实际使用体验不符。 + +![Gitee测试项目](https://images.gitee.com/uploads/images/2021/0117/135151_2f25f98a_1277510.png "image-20210117133535739.png") + +#### 初尝甜头 + +充分的了解让我对于这块的知识有了更多的把握，初始工作准备了 2~3 天后，我终于开始动笔了。首先需要完成的便是官方建议的大纲中建议的小节内容。 + +这里我编写的原则是在参考资料的基础上，一些概念解释或表述会基于自己对于 Issue 的理解来展开，尽可能让人快速理解这是一个什么东西，以及如何快速使用。 + +编写完成后，我开始提交我的第一稿稿件（因为担心到初稿截止日了没提交的不算数了，所以先提交第一稿再说），这时，我对于 PR 协作也是没太多经验的，不过想着总要跟仓库所有者讲明白我这次提交了什么，下次准备写啥来方便人家审核吧，于是就提了这么一个初稿 PR：[!30 【轻量级 PR】：update 第三部分——尝试参与开源/提交第一个 Issue.md.第一稿，后续还有补充，详见扩展信息](https://gitee.com/gitee-community/opensource-guide/pulls/30) + +![第一个PR](https://images.gitee.com/uploads/images/2021/0117/135236_bd749e58_1277510.png "image-20210117114636492.png") + +没想到，PR 说明内容竟成为之前提交过 PR 的作者里面最详实的，还触发了官方的隐藏奖励，官方直接在编写群里表扬了我： + +![触发隐藏奖励](https://images.gitee.com/uploads/images/2021/0117/135308_f229edb9_1277510.png "image-20210117115256768.png") + +一个开源爱好者的快乐就是这么简单，一个简单的肯定，足以让他激发更大的热情。这次，Gitee 官方的热情真的让我受宠若惊，于是我决定，后面的内容也要尽快完善完整，决不能让嗷嗷待哺的 Gitee 等久了。 + +#### 完善补充 + +于是我利用工作之余的时间，继续完善补充内容，在编写的过程中，遇到的一些关于在 Gitee 中使用 Issue 的疑问（网上找不到答案，官方的文档也没写的那种），还得到了 Gitee 工作人员的耐心解答和截图支持，在此对他们表示感谢。几天后，新鲜出炉，内容详实的共 5 稿初稿，终于在第一阶段编写的截止日期前完成了。同时这份初稿也成为了后来专家组审校的过程中，一刀未剪，一稿通过的初稿，在此特别感谢专家组的肯定。 + +在编写完自己认领的章节的同时，我也在思考是否能为《开源指北》做更多的事情，比如是否可以根据编写规范，给其他已经编写好的内容改改错别字，通顺下语句或者优化排版等等。 + +说干就干！利用工作之余的时间，我将当时已经提交合并的所有章节内容都看了一遍，通读别的大神的作品学习的同时，修改了许多小细节内容。毕竟朋友们都说，我的性格适合做需要细心的活嘛。通过通力协作，我有了很大的成长和提高。 + +#### 阅读我主编的章节 + +如果你看到这里对我编写的内容感兴趣，欢迎到这里阅读我主要编写的章节： + +[第 6 小节：提交第一个 Issue](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%AC%AC%E4%B8%89%E9%83%A8%E5%88%86%EF%BC%9A%E5%B0%9D%E8%AF%95%E5%8F%82%E4%B8%8E%E5%BC%80%E6%BA%90/%E7%AC%AC%206%20%E5%B0%8F%E8%8A%82%EF%BC%9A%E6%8F%90%E4%BA%A4%E7%AC%AC%E4%B8%80%E4%B8%AA%20Issue.md) + +### 参与后的收获或提升 + +#### 技术精进 + +在技术方面，通过全程参与开源项目，对于整体项目流程有了很细致的了解。 + +同时为了写好自己认领的章节，我也对 Issue 相关的内容做了详细的理论调研。 + +单单是这样还不够，我还在 Gitee 建了个自己的仓库，对于学到的理论知识，都一一在仓库中实际测试之后，才会写到自己认领的章节中，对自己负责，也对未来阅读这本书籍的开源爱好者们负责。 + +即使现在在编写完成这个章节的内容几个月之后，我还是清晰的记得当初学过和记录过的那些知识要点，它就好像树根一样，深深的扎根在我的脑海里了，这对我未来持续参与开源贡献，是非常有帮助的。 + +感谢这样的经历，又让我成长了许多。 + +#### 广交新友 + +**线上** + +真的非常喜欢开放包容的开源社区的氛围，至少 Gitee 的`开源指北`社区是这样的，有问题，大家摆事实讲道理，评论都是一大段一大段的，跟别人进行思想的碰撞其实是一件很爽的事情。因为发一条评论是经过深思熟虑的，需要好好组织语言来表达自己的观点，因此感觉发的每条技术评论都是文思泉涌的。这对于需要讨论的技术问题的进一步明确，甚至达成共识，非常有帮助。 + +在咱们编写小分队的微信群中，也结识了许多志同道合的小伙伴，许多开源大佬，未来我还需要多多向他们学习，向他们看齐，多为开源社区做贡献。 + +**线下** + +2020 年 12 月 27 号下午，深圳国际开源谷开源中国办公室举办了年度的 `Gitee Day` 线下活动，多次跟小助手说我要去你们办公的地方看看的我报名参与了此次活动，并有幸结实了一干开源大佬。 + +![Gitee Day 1](https://images.gitee.com/uploads/images/2021/0117/135639_bcc762e2_1277510.png "image-20210117123912367.png") + +活动结束，还有幸参与了 Gitee 大家庭和开源分享嘉宾大佬们的晚宴，这对我来说真的是很珍贵的经历和宝贵的财富。晚宴上，我致力的教学布道的事情也得到了大佬们的认可和肯定，这对我来说是莫大的鼓励。 + +![Gitee Day 2](https://images.gitee.com/uploads/images/2021/0117/140033_0d359644_1277510.jpeg "image-20210117123930028.jpg") + +我梦想着，未来在开源大佬的席位上，也有我的一席之地吧。 + +#### 奖品满载而归 + +Gitee 真是一个不吝啬发奖品的好公司，由于我的积极贡献，前前后后获得了超多 Gitee 发的礼物，包括精致的证书、T恤、马克杯、鼠标垫、手机挂环、数据线、精美笔记本、双肩背包、实用手提包等等，搞得 `Gitee小助手` 都在说：你要凑个全套周边吗？ + +![T恤](https://images.gitee.com/uploads/images/2021/0117/140112_5d07dcb4_1277510.jpeg "image-20210117124529354.jpg") + +![双肩背包](https://images.gitee.com/uploads/images/2021/0117/140126_88806c64_1277510.jpeg "image-20210117124551892.jpg") + +![证书](https://images.gitee.com/uploads/images/2021/0117/140141_14b080ec_1277510.png "image-20210117124619480.png") + +![精美笔记本](https://images.gitee.com/uploads/images/2021/0117/140156_6dd035e9_1277510.png "image-20210117124625835.png") + +### 写给想参与开源的你 + +故事的最后，让我来给想参与开源的你说说心里话。 + +**“开源，用你的力量来帮助到更多的人。”** + +对于我接触到的生活工作圈子来说，参与开源贡献的人是比较少的，很多都是企业级别开发的项目，有着较高的保密需求，因此企业内的项目私有化的占比较大。但我看好开源社区，看好开源文化。如何在未来引领更多新的开发者进入开源的世界，为开源，为世界作出一点自己新的贡献，是我未来努力发展的方向。 + +这个世界未来发展的技术和力量一定是大家一点一滴筑成的。开源协作给了你一个很好的机会，跟全球开发者一道让这个世界变得更美好。当你和社区的努力给成千上万的人带来实质性的帮助的时候，那种成就感是无与伦比的。 + +而看完我的故事后，不要怕，赶紧去行动起来，参与到开源贡献当中，相信你会有不一样的技术收获。 + +![哈佛学习金字塔](https://images.gitee.com/uploads/images/2021/0117/140229_324697ff_1277510.png "image-20210117132020298.png") + +不要担心自己的技术和贡献分享出去之后只是为别人做了嫁衣，`哈佛学习金字塔`告诉你，当你学到知识，最终实现`转教别人/立即应用`的程度时，你属于主动学习，知识的吸收效率是最高的。做出贡献，不仅是对项目做出了帮助，还练习了你编写代码的能力，训练了你与人协作的能力，对你的个人成长性极高。 + +因此，不要吝啬对开源社区做出的奉献，这个世界很多东西都是守恒的，你做出了贡献，开源世界终将回馈于你。 + +加油吧朋友！我在开源世界里等待你的到来！ + diff --git "a/\347\233\256\345\275\225.md" "b/\347\233\256\345\275\225.md" index 674c24d..2edcf56 100644 --- "a/\347\233\256\345\275\225.md" +++ "b/\347\233\256\345\275\225.md" @@ -1,49 +1,46 @@ -### 第一部分--初识开源 -* [第 1 小节：什么是开源](第一部分：初识开源/第%201%20小节：什么是开源.md) -* [第 2 小节：开源与个人技术成长](第一部分：初识开源/第%202%20小节：开源与个人技术成长.md) -* [第 3 小节：如何判断一个项目是否是开源的](第一部分：初识开源/第%203%20小节：如何判断一个项目是否是开源的.md) -* [第 4 小节：关于开源基金会](第一部分：初识开源/第%204%20小节关于开源基金会.md) -* [第 5 小节：有关开源的常见误区](第一部分：初识开源/第%205%20小节：有关开源的常见误区.md) -* [第 6 小节：常见文件认识](第一部分：初识开源/第%206%20常见文件认识.md) -* [第 7 小节：企业视角看待开源](第一部分：初识开源/第%207%20小节：企业视角看待开源.md) -* [第 8 小节：开源发展趋势](第一部分：初识开源/第%208%20小节：开源发展趋势.md) - -### 第二部分--学习和使用开源项目 -* [第 1 小节：如何找到适合自己学习和使用的开源项目](第二部分：学习和使用开源项目/第%201%20小节：如何找到适合自己学习和使用的开源项目.md) -* [第 2 小节：开源项目的源代码该怎么读](第二部分：学习和使用开源项目/第%202%20小节开源项目的源代码该怎么读.md) -* [第 3 小节：认识开源许可证](第二部分：学习和使用开源项目/第%203%20小节认识开源许可证.md) -* [第 4 小节：开源中的赞赏文化](第二部分：学习和使用开源项目/第%204%20小节开源中的赞赏文化.md) -* [第 5 小节：如何找到最强开源项目](第二部分：学习和使用开源项目/第%205%20小节如何找到最强开源项目.md) - -### 第三部分--尝试参与开源 -* [第 1 小节：开源项目中的不同角色](第三部分：尝试参与开源/第%201%20小节：开源项目中的不同角色.md) -* [第 2 小节：个人为什么要参与开源贡献](第三部分：尝试参与开源/第%202%20小节：个人为什么要参与开源贡献.md) -* [第 3 小节：企业为什么要参与开源](第三部分：尝试参与开源/第%203%20小节：企业为什么要参与开源.md) -* [第 4 小节：可以用哪些方式参与开源](第三部分：尝试参与开源/第%204%20小节：可以用哪些方式参与开源.md) -* [第 5 小节：如何找到适合的项目进行贡献](第三部分：尝试参与开源/第%205%20小节：如何找到适合的项目进行贡献.md) -* [第 6 小节：提交第一个 Issue](第三部分：尝试参与开源/第%206%20小节：提交第一个%20Issue.md) -* [第 7 小节：提交第一个 Pull Request](第三部分：尝试参与开源/第%207%20小节：提交第一个%20Pull%20Request.md) -* [第 8 小节：如何成为一个项目的核心贡献者](第三部分：尝试参与开源/第%208%20小节：如何成为一个项目的核心贡献者.md) -* [第 9 小节：开源项目的贡献准则和贡献者公约](第三部分：尝试参与开源/第%209%20小节：开源项目的贡献准则和贡献者公约.md) - -### 第四部分--启动自己的开源项目 -* [第 1 小节：有了开源的想法后从何开始](第四部分：启动自己的开源项目/第%201%20小节：有了开源的想法后从何开始.md) -* [第 2 小节：为开源项目建立良好的基础](第四部分：启动自己的开源项目/第%202%20小节：为开源项目建立良好的基础.md) -* [第 3 小节：开源许可证的应用](第四部分：启动自己的开源项目/第%203%20小节：开源许可证的应用.md) -* [第 4 小节：为自己的开源项目建立贡献准则](第四部分：启动自己的开源项目/第%204%20小节：为自己的开源项目建立贡献准则.md) -* [第 5 小节：开源项目的维护和管理](第四部分：启动自己的开源项目/第%205%20小节：开源项目的维护和管理.md) -* [第 6 小节：CONTRIBUTING 编写](第四部分：启动自己的开源项目/第%206%20小节：CONTRIBUTING%20编写.md) - -### 第五部分--开源治理 -* [第 1 小节：个人维护和建立社区，两者如何选择？](第五部分：开源治理/第%201%20小节：个人维护和建立社区，两者如何选择.md) -* [第 2 小节：打造开源社区](第五部分：开源治理/第%202%20小节：打造开源社区.md) -* [第 3 小节：开源项目的常见治理架构](第五部分：开源治理/第%203%20小节：开源项目的常见治理架构.md) -* [第 4 小节：确保开源代码质量的几个要点](第五部分：开源治理/第%204%20小节：确保开源代码质量的几个要点.md) - -### 第六部分--其他问题 -* [第 1 小节：怎样在本职工作和开源项目间做好平衡](第六部分：其他问题/第%201%20小节：怎样在本职工作和开源项目间做好平衡.md) -* [第 2 小节：关于开源项目的商业化](第六部分：其他问题/第%202%20小节：关于开源项目的商业化.md) - - - - +### 第一部分--初识开源 +* [第 1 小节：什么是开源](第一部分：初识开源/第%201%20小节：什么是开源.md) +* [第 2 小节：开源与个人技术成长](第一部分：初识开源/第%202%20小节：开源与个人技术成长.md) +* [第 3 小节：如何判断一个项目是否是开源的](第一部分：初识开源/第%203%20小节：如何判断一个项目是否是开源的.md) +* [第 4 小节：关于开源基金会](第一部分：初识开源/第%204%20小节关于开源基金会.md) +* [第 5 小节：有关开源的常见误区](第一部分：初识开源/第%205%20小节：有关开源的常见误区.md) +* [第 6 小节：常见文件认识](第一部分：初识开源/第%206%20常见文件认识.md) +* [第 7 小节：企业视角看待开源](第一部分：初识开源/第%207%20小节：企业视角看待开源.md) +* [第 8 小节：开源发展趋势](第一部分：初识开源/第%208%20小节：开源发展趋势.md) + +### 第二部分--学习和使用开源项目 +* [第 1 小节：如何找到适合自己学习和使用的开源项目](第二部分：学习和使用开源项目/第%201%20小节：如何找到适合自己学习和使用的开源项目.md) +* [第 2 小节：开源项目的源代码该怎么读](第二部分：学习和使用开源项目/第%202%20小节开源项目的源代码该怎么读.md) +* [第 3 小节：认识开源许可证](第二部分：学习和使用开源项目/第%203%20小节认识开源许可证.md) +* [第 4 小节：开源中的赞赏文化](第二部分：学习和使用开源项目/第%204%20小节开源中的赞赏文化.md) +* [第 5 小节：如何找到最强开源项目](第二部分：学习和使用开源项目/第%205%20小节如何找到最强开源项目.md) + +### 第三部分--尝试参与开源 +* [第 1 小节：开源项目中的不同角色](第三部分：尝试参与开源/第%201%20小节：开源项目中的不同角色.md) +* [第 2 小节：个人为什么要参与开源贡献](第三部分：尝试参与开源/第%202%20小节：个人为什么要参与开源贡献.md) +* [第 3 小节：企业为什么要参与开源](第三部分：尝试参与开源/第%203%20小节：企业为什么要参与开源.md) +* [第 4 小节：可以用哪些方式参与开源](第三部分：尝试参与开源/第%204%20小节：可以用哪些方式参与开源.md) +* [第 5 小节：如何找到适合的项目进行贡献](第三部分：尝试参与开源/第%205%20小节：如何找到适合的项目进行贡献.md) +* [第 6 小节：提交第一个 Issue](第三部分：尝试参与开源/第%206%20小节：提交第一个%20Issue.md) +* [第 7 小节：提交第一个 Pull Request](第三部分：尝试参与开源/第%207%20小节：提交第一个%20Pull%20Request.md) +* [第 8 小节：如何成为一个项目的核心贡献者](第三部分：尝试参与开源/第%208%20小节：如何成为一个项目的核心贡献者.md) +* [第 9 小节：开源项目的贡献准则和贡献者公约](第三部分：尝试参与开源/第%209%20小节：开源项目的贡献准则和贡献者公约.md) + +### 第四部分--启动自己的开源项目 +* [第 1 小节：有了开源的想法后从何开始](第四部分：启动自己的开源项目/第%201%20小节：有了开源的想法后从何开始.md) +* [第 2 小节：为开源项目建立良好的基础](第四部分：启动自己的开源项目/第%202%20小节：为开源项目建立良好的基础.md) +* [第 3 小节：开源许可证的应用](第四部分：启动自己的开源项目/第%203%20小节：开源许可证的应用.md) +* [第 4 小节：为自己的开源项目建立贡献准则](第四部分：启动自己的开源项目/第%204%20小节：为自己的开源项目建立贡献准则.md) +* [第 5 小节：开源项目的维护和管理](第四部分：启动自己的开源项目/第%205%20小节：开源项目的维护和管理.md) +* [第 6 小节：CONTRIBUTING 编写](第四部分：启动自己的开源项目/第%206%20小节：CONTRIBUTING%20编写.md) + +### 第五部分--开源治理 +* [第 1 小节：个人维护和建立社区，两者如何选择？](第五部分：开源治理/第%201%20小节：个人维护和建立社区，两者如何选择.md) +* [第 2 小节：打造开源社区](第五部分：开源治理/第%202%20小节：打造开源社区.md) +* [第 3 小节：开源项目的常见治理架构](第五部分：开源治理/第%203%20小节：开源项目的常见治理架构.md) +* [第 4 小节：确保开源代码质量的几个要点](第五部分：开源治理/第%204%20小节：确保开源代码质量的几个要点.md) + +### 第六部分--其他问题 +* [第 1 小节：怎样在本职工作和开源项目间做好平衡](第六部分：其他问题/第%201%20小节：怎样在本职工作和开源项目间做好平衡.md) +* [第 2 小节：关于开源项目的商业化](第六部分：其他问题/第%202%20小节：关于开源项目的商业化.md) + diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\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 05f7442..f842c3f 100644 --- "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\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" @@ -49,7 +49,7 @@ 下面提供一个 icon 的设计，供大家参考。 -- [开源和开放设计 - Make Icons Witch Sketch](https://www.jianshu.com/p/e3de4fbd105f) +- [开源和开放设计 - Make Icons Witch Sketch](https://www.jianshu.com/p/e3de4fbd105f) ### 开源文档 @@ -79,13 +79,13 @@ ![输入图片说明](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 等一系列操作系统必备软件。 随着推动自由软件发展和成熟的愿景日益强烈，理查德·斯托曼意识到仅通过编写和分享 GNU 代码是远远不够的。于是，在 1985 年创建了自由软件基金会（Free Software Foundation，简称 FSF），其主要工作是运行 GNU 计划，开发更多的自由软件。同时，FSF 还创建了保护 GNU 和其他自由软件项目的法律和制度框架，提出了与 CopyRight 理念针锋相对的 CopyLeft（许可复制权）理念，其表现形式为 GPL，即公共许可证（General Pubic License）。 -### Linux +### Linux 1991 年，林纳斯·托瓦兹（Linus Torvalds）公开发布了一个类 UNIX 操作系统内核 —— Linux，并接受 CopyLeft 理念。从 Linux 0.12 版本起，Linux 内核开始采用 GPL 许可证的新版权声明。虽然 Linux 内核并不是 GNU 计划的一部分，但由于 HURD 内核进展缓慢，使得 Linux 得到广泛关注并得以快速发展。GNU 与 Linux 的发展，可以说是相辅相成，因此 我们通常把使用 Linux 内核并且大量使用 GNU 组件的操作系统发行版称为 GNU/Linux。 @@ -97,17 +97,14 @@ ### 自由软件和开源软件 - 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 正因如此，自由软件运动和开源软件运动有着密不可分的关系，两者的根本差别在于它们看待世界的方法。开源软件运动的理念更倾向于解决实际问题，既抓住了私有软件的痛点，又实现了与商业的融合。 - ### 开源、Git和代码托管平台 前面提到，开源软件是允许自由复制和重新分发的，那么分散的开发者之间是如何协作的呢？尤其是 Linux 这样依靠全世界热心的志愿者参与的项目。其实早年（1991-2002 年间）世界各地的志愿者是通过 diff 的方式把源代码补丁发给 Linus，然后由 Linus 本人通过手工方式合并代码。直到 2002 年，Linux 项目组才开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。 @@ -138,7 +135,6 @@ 开源与我们息息相关，即便你不写代码，我们也期望大家能够参与开源（**强烈建议**）！愿你在开源领域乘风破浪，所向无前！ - ## 参考资料 - [The Open Source Definition](https://opensource.org/osd) diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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" index 733d8e7..9bf63ce 100644 --- "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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" @@ -173,7 +173,7 @@ ## 参考资料 -- [开源的 7 大理念](https://blog.csdn.net/kaiyuanshe/article/details/99670198) +- [开源的 7 大理念](https://blog.csdn.net/kaiyuanshe/article/details/99670198) ## 本部分内容贡献者 [Holdonbei](https://gitee.com/Holdonbei)、[bryan31](https://gitee.com/bryan31)、[雪山凌狐](https://gitee.com/xueshanlinghu)、[杨子江](https://gitee.com/nodexy)、[阿基米东](https://gitee.com/luhuadong)、[taotieren](https://gitee.com/taotieren)、[WhitePaper](https://gitee.com/whitepaper233)、[西狩](https://gitee.com/lihuimingxs) diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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.md" "b/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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.md" index c153b48..4db2be0 100644 --- "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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.md" +++ "b/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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.md" @@ -12,7 +12,7 @@ 闭源在保护机密和隐私方面发挥了重要作用，但由于参与成员的限制性，不能像开源项目那样集思广益，因此，项目的迭代速度一般会慢于开源项目。此外，也正是因为参与群体范围较小，闭源项目的维护管理、标准化难度会小于开源项目。 -## 什么是开源 (Open Source) +## 什么是开源 (Open Source) 开源软件是开源的主要表现形式。在第 1 小节中，相信你已经对开源有所了解，下面我们来回顾一下开源的定义：开源软件是一种 **技术和立场中立**的**使用许可证约束**的**开放源代码** 的软件。 @@ -56,12 +56,12 @@ - [Business Source License 1.1](https://mariadb.com/bsl11/) - [FAIR SOURCE LICENSE](https://fair.io/) - [The Commons Clause.](https://commonsclause.com/) -- [Anti-996 License](https://github.com/996icu/996.ICU/blob/master/LICENSE_CN) +- [Anti-996 License](https://github.com/996icu/996.ICU/blob/master/LICENSE_CN) ## 参考资料 - [Android为何是“半开源操作系统” ？](https://www.zhihu.com/question/21189880) -- [微软 VS Code“半开源”的操作属实不地道](https://www.v2ex.com/t/598322) +- [微软 VS Code“半开源”的操作属实不地道](https://www.v2ex.com/t/598322) ### 本部分内容贡献者 [ZeroAurora](https://gitee.com/ZeroAurora233)、[雪山凌狐](https://gitee.com/xueshanlinghu)、[ORH](https://gitee.com/orh)、[阿基米东](https://gitee.com/luhuadong)、[XYCode](https://gitee.com/XYCode-XYC)、[西狩](https://gitee.com/lihuimingxs) \ No newline at end of file diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 4 \345\260\217\350\212\202\357\274\232\345\205\263\344\272\216\345\274\200\346\272\220\345\237\272\351\207\221\344\274\232.md" index ac22922..bfe615f 100644 --- "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 4 \345\260\217\350\212\202\357\274\232\345\205\263\344\272\216\345\274\200\346\272\220\345\237\272\351\207\221\344\274\232.md" @@ -40,7 +40,6 @@ Apache 软件基金会和自由软件基金会之类的基金会甚至为监管 > > Linux 基金会还监管大型的协作项目，包括 Xen 项目、Kinetic 开放存储项目和核心基础设施项目（Core infrastructure Initiative），项目贡献者来自大型商业机构，包括谷歌、IBM、英特尔、思科和惠普。 - ### 3. 开放原子开源基金会 ![开放原子开源基金会 Logo](https://images.gitee.com/uploads/images/2020/1204/190225_2ad60ba9_5694891.png "屏幕截图.png") @@ -54,13 +53,13 @@ Apache 软件基金会和自由软件基金会之类的基金会甚至为监管 ![Eclipse 基金会 Logo](https://images.gitee.com/uploads/images/2020/1204/184138_28edf92b_5406987.jpeg "3.jpeg") > Eclipse 基金会成立于 2004 年，旨在支持一个软件开发开源社区，以便构建、部署和管理软件。最知名的项目是 Eclipse 开发环境，但基金会还支持另外大约 200 个处于不同成熟阶段的项目，包括商业智能和报表工具以及物联网等项目。 -> +> > Eclipse 基金会委员会的代表来自各大科技公司，包括谷歌、IBM、甲骨文和 SAP、爱立信。 -> +> ### 5. 云原生计算基金会（CNCF） -![云原生计算基金会（CNCF）Logo](https://images.gitee.com/uploads/images/2020/1204/185019_43cb87e5_5406987.png "CNCF.png") +![云原生计算基金会（CNCF）Logo](https://images.gitee.com/uploads/images/2020/1204/185019_43cb87e5_5406987.png "CNCF.png") > CNCF 是一个开源软件基金会，致力于使云原生计算具有普遍性和可持续性。云原生计算使用开源软件技术栈将应用程序部署为微服务，将每个部分打包到自己的容器中，并动态编排这些容器以优化资源利用率。 CNCF 最知名的项目是 Kubernetes ，是世界上最受欢迎的容器编排平台之一。 @@ -74,7 +73,7 @@ Apache 软件基金会和自由软件基金会之类的基金会甚至为监管 ### 7. OpenStack 基金会 -![OpenStack 基金会Logo](https://images.gitee.com/uploads/images/2020/1204/185706_6c3d4653_5406987.jpeg "6.jpeg") +![OpenStack 基金会Logo](https://images.gitee.com/uploads/images/2020/1204/185706_6c3d4653_5406987.jpeg "6.jpeg") > 不像上述基金会，OpenStack 基金会一门心思扑在一个项目上：它致力于 OpenStack 云操作系统的开发、发布和采用。 > @@ -84,17 +83,13 @@ Apache 软件基金会和自由软件基金会之类的基金会甚至为监管 ![软件自由管理委员会Logo](https://images.gitee.com/uploads/images/2020/1204/185728_2a4fd21a_5406987.jpeg "7.jpeg") - - > 虽然无论规模还是知名度，软件自由管理委员会（Software Freedom Conservancy）都不如 Apache 软件基金会，但这是另一家为开源项目提供大本营和服务的基金会。它目前管理着 33 个项目，包括几个一下子就能辨认出来的项目，比如 BusyBox、Git、Samba 和 Wine。 > > 软件自由管理委员会还运作一个 GPL 合规项目，该项目旨在执行 GPL。它目前在帮助出钱出力，支持指控 *VMware* 涉嫌违反 GPL 的诉讼。 ### 9. 自由软件基金会 -![自由软件基金会Logo](https://images.gitee.com/uploads/images/2020/1204/185744_24f8e47b_5406987.jpeg "8.jpeg") - - +![自由软件基金会Logo](https://images.gitee.com/uploads/images/2020/1204/185744_24f8e47b_5406987.jpeg "8.jpeg") > 自由软件基金会是一家重要的开源软件基金会，却有点不一样：它比其他任何项目更关注软件自由。1985 年，该基金会由开源领域的传奇人物 Richard Stallman 创办，其目标是实现下列内容： > @@ -102,9 +97,7 @@ Apache 软件基金会和自由软件基金会之类的基金会甚至为监管 ### 10. 开放源码组织 -![开放源码组织Logo](https://images.gitee.com/uploads/images/2020/1204/185756_8c42cddf_5406987.jpeg "9.jpeg") - - +![开放源码组织Logo](https://images.gitee.com/uploads/images/2020/1204/185756_8c42cddf_5406987.jpeg "9.jpeg") > 开放源码组织（Open Source Initiative）的涉足领域与自由软件基金会一样，原因在于它的初衷是支持整个软件运动，而不是支持任何某一个项目。但是相比自由软件基金会关注的重心是软件“自由”，开放源码组织谈论的却是开源软件，旨在实现下列目标： > diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\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 179041d..0a46789 100644 --- "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\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" @@ -54,7 +54,6 @@ OSI 网络体系结构（Open Systems Interconnection）是由国际标准化组 ### 开源项目不能转为闭源 - 认识开源首先的一点是要认识各种开源许可证，不同开源许可证对待开源转闭源有不同的规定： * LGPL、GPL、MPL 这类许可证禁止开源软件转为闭源软件。 @@ -115,7 +114,6 @@ OSI 网络体系结构（Open Systems Interconnection）是由国际标准化组 ### 开源项目必须用英文命名标识符吗？ - 虽然很多开发者早已知道多数常用编程语言支持中文命名标识符并付诸实践，但仍然常见“如果项目开源的话还是要用英文命名”的说法。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. @@ -158,9 +156,9 @@ OSI 网络体系结构（Open Systems Interconnection）是由国际标准化组 ## 参考资料 -- [走出误区 正确认识开源](https://searchvirtual.techtarget.com.cn/10-20427/) +- [走出误区 正确认识开源](https://searchvirtual.techtarget.com.cn/10-20427/) -- [What is open source?](https://opensource.com/resources/what-open-source) +- [What is open source?](https://opensource.com/resources/what-open-source) ### 本部分内容贡献者 [YFun](https://gitee.com/trytoget)、[吴烜](https://gitee.com/zhishi)、[菜菜STWhite](https://gitee.com/daaaaaaaaaaa)、[雪山凌狐](https://gitee.com/xueshanlinghu)、[和耳朵](https://gitee.com/he-erduo)、[jack960330](https://gitee.com/jack960330)、[哦是吗](https://gitee.com/yougood6)、[taotieren](https://gitee.com/taotieren)、[Sooxin](https://gitee.com/hellosooxin)、[西狩](https://gitee.com/lihuimingxs) \ No newline at end of file diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 6 \345\260\217\350\212\202\357\274\232\345\270\270\350\247\201\346\226\207\344\273\266\350\256\244\350\257\206.md" "b/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 6 \345\260\217\350\212\202\357\274\232\345\270\270\350\247\201\346\226\207\344\273\266\350\256\244\350\257\206.md" index 72f686f..13a29cf 100644 --- "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 6 \345\260\217\350\212\202\357\274\232\345\270\270\350\247\201\346\226\207\344\273\266\350\256\244\350\257\206.md" +++ "b/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 6 \345\260\217\350\212\202\357\274\232\345\270\270\350\247\201\346\226\207\344\273\266\350\256\244\350\257\206.md" @@ -23,7 +23,7 @@ - **CONTRIBUTING**：指导参与者如何对项目做出贡献，CONTRIBUTING 中表述了项目需要什么类型的贡献，社区或者本项目的作业流程。 - **LICENSE**：开源许可证文件，开源项目通过编写开源许可文件，声明项目使用的开源协议。 - **NOTICE**：用来存放 License 定义的法律声明文件。 -- **README**：项目介绍说明文件，通常 README 会表述项目的用处、发起原因、快速使用等。 +- **README**：项目介绍说明文件，通常 README 会表述项目的用处、发起原因、快速使用等。 需要注意的是，上述文件仅作为项目开源的指导性文件，属于约定俗成的开源项目规范，并非强制要求，请根据自身需求选择使用相应的文件。当然，你也可以按照自己的想法制定自己的项目规范，只要能够帮助项目在开源过程中的能够很好的管理、开发和维护，能够保障项目相关权利，它就是一份良好的项目规范。 @@ -128,7 +128,6 @@ - ***.deb**: deb 文件是 Debian 发行版创建的软件包格式文件，在基于 Debian 的发行版中使用。 - ***.rpm**: rpm 文件是 Redhat 发行版创建的软件包格式文件，在基于 Redhat 的发行版中使用。 - ## 小结 通过以上描述，大家可能会发现很多文件格式都有见过。没错！常见的各类文件格式不仅存在于开源项目中，在日常生活中也随处可见。不同文件格式有着不同的作用，标准的文件格式使得我们可以快速分辨文件用途，也能够帮助我们更好地了解开源项目。 diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 7 \345\260\217\350\212\202\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 7 \345\260\217\350\212\202\357\274\232\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 5f663e7..c44a6b6 100644 --- "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 7 \345\260\217\350\212\202\357\274\232\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\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 7 \345\260\217\350\212\202\357\274\232\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" @@ -62,7 +62,6 @@ 5. 主动开源并不意味着社区就能接纳，需要长期有大量的回馈代码才能建立信誉及影响力，公司内的社区管理人员才能得到锻炼和培养。但是，社区管理人员个人知名度的提升会增加被猎头公司挖走的风险。 6. 软件在开发过程中或完成之后，如果出现同类开源软件，该如何处理？ - ## 企业参与开源的动机 总的来说，企业参与开源项目的动机主要有以下几个： @@ -79,7 +78,7 @@ 2.降低维护成本： 如果一个企业开始在本地的分支做缺陷修复、增加新的功能，然而却没有将这些代码提交到上游的开源项目中，那么很快维护本地的分支，将成为该公司的一个成本噩梦。将上游作为优先的提交缺陷修复和增加新功能是最为明智的做法，因为这样的维护成本最低； 3.项目影响力： 在一个开源的项目中，新的特性或功能来自社区的贡献，那么这些贡献就会影响到项目的走向，如果你认为为项目所贡献的新功能对于贵司非常的重要，那么你应该去安排积极的贡献者对这些功能进行开发和实现。通过贵司的贡献，自然而然就可以影响到项目的走向； - + 4.有利可图：商本逐利，无可厚非。一方面，对现有开源项目的贡献可以让企业在降低维护成本的同时促进相关业务的发展，获取利润；另一方面，开源本公司的个别项目吸引全球各地的开发者共同维护，借助开源的优势扩大该项目在本行业的影响力，扩大市场占有率，在保持项目开源继续发展的前提下，通过附加其他手段来获取丰厚的利润回报。 ### 本部分内容贡献者 diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 8 \345\260\217\350\212\202\357\274\232\345\274\200\346\272\220\345\217\221\345\261\225\350\266\213\345\212\277.md" "b/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 8 \345\260\217\350\212\202\357\274\232\345\274\200\346\272\220\345\217\221\345\261\225\350\266\213\345\212\277.md" index eb6dcc4..a070157 100644 --- "a/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 8 \345\260\217\350\212\202\357\274\232\345\274\200\346\272\220\345\217\221\345\261\225\350\266\213\345\212\277.md" +++ "b/\347\254\254\344\270\200\351\203\250\345\210\206\357\274\232\345\210\235\350\257\206\345\274\200\346\272\220/\347\254\254 8 \345\260\217\350\212\202\357\274\232\345\274\200\346\272\220\345\217\221\345\261\225\350\266\213\345\212\277.md" @@ -28,7 +28,6 @@ > > 根据统计，2017 年我国最大的开源代码托管平台 Gitee 的活跃用户数已经超过 200 万，增速超过 100％。集聚的各类开源项目接近 300 万个，增速超过 170％，企业用户数从 2017 年的初的 403 家增加到了年末的 2 万余家，付费月均增长达到 33％。近三年托管在开源中国的我国开源软件数量呈现逐年上升趋势，截至 2018 年 2 月，开源中国共收录了 9055 个我国本土开源软件。 - **开源平台** 随着开源在国内生根落地，开源平台的队伍也不断壮大。开源平台是指提供开源技术分享服务的线上平台，主要包括开源镜像站、开源仓库、开源博客。 @@ -43,7 +42,7 @@ - [全球有哪些比较好的开源网站？](https://www.zhihu.com/question/20743719) - [开源世界，开源中国，这些开源网站，你都知道吗？](https://www.bilibili.com/read/cv5414164/) -- [现在有哪些开源多用户博客系统？？](https://www.zhihu.com/question/21836419) +- [现在有哪些开源多用户博客系统？？](https://www.zhihu.com/question/21836419) **开源组织** @@ -51,7 +50,7 @@ 此外，实际上，开源组织并不仅仅包含各类开源基金会，很多国际知名的企业组织都是主要的开源贡献者，对开源发展做出了巨大贡献。比如：Alibaba、Baidu、Google、Linkedin、Microsoft、华为等。如果你想要了解更多开源组织，请参考以下资料： -- [开源中国-公司开源导航](https://www.oschina.net/company) +- [开源中国-公司开源导航](https://www.oschina.net/company) **开源项目** @@ -79,7 +78,7 @@ 2020 年，AYALA GOLDSTEIN 通过收集开源软件信息，并对其进行分析，分析结果表明：67%的开放源代码选择了更为宽松的开源协议。这意味着开源者在创建开源项目时，会选择相对自由的方式去分享，心态上显得更加开放。下面附上原文链接： -- [Open Source Licenses: Trends and Predictions](https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-trends-and-predictions) +- [Open Source Licenses: Trends and Predictions](https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-trends-and-predictions) ### 开源生态趋势 @@ -91,7 +90,6 @@ 「开源+」时代是指，依托开源项目基础，组建自己的服务、业务、团队等（在开源许可认证内），减少了很多维护成本。 - - 开源+ IT 服务提供商：在每种情况下，都应对软件需求进行单独评估–使用开源软件有很多充分的理由。使用闭源软件时可能产生的优势，例如通常仅适用于专有软件的进一步开发或支持，可以通过与有能力的 IT 服务提供商合作，为开源带来巨大优势。拥有合适的软件和出色的 IT 资源的公司处于创造最佳数字未来的理想位置。 IT 服务提供商或内部 IT 团队可以接管各个定制，开发和支持，而不仅限于一种软件。在选择 IT 合作伙伴时，建议不仅要注意技术能力，还要考虑项目管理和实施的方法，变更管理质量以及 IT 服务提供商的文化和思维方式。 开源软件代表了一种新的技术产生方式。顶尖的高校研究成果很多都是以开源形式发布的，顶尖公司（如谷歌）的技术架构中，每套系统基本都有其对应的开源项目。 @@ -137,7 +135,6 @@ **商用软件的优缺点描述** - | | 商用软件 | 描述 | |---|---|---| |优点 |单一供应商|通常商业软件包括“一站式购物”体验，即单个供应商可以提供你所需的所有应用程序和工具。微软就是一个很好的例子，它销售操作系统、数据库、办公软件等各种应用软件、还有开发工具等等。相比之下，开源软件却比较零碎。| @@ -151,7 +148,7 @@ | |供应商锁定 | “一站式购物”导致，你的企业最终可能会过度依赖于供应商，被锁定在一个封闭的系统中。| | |替换很难 | 害怕浪费钱迫使企业会继续使用那些可能无法完全满足他们利益的产品。切换到竞争或替代软件的困难包括担心必须从头再来，更换一个软件，再培训人员等其他原因。| -> 参考 [各有利弊，开源和商业软件应该怎么选？](https://blog.csdn.net/belalds/article/details/88026244) +> 参考 [各有利弊，开源和商业软件应该怎么选？](https://blog.csdn.net/belalds/article/details/88026244) ### 开源的商业化 @@ -184,8 +181,7 @@ - [浅谈开源软件的发展（一）：开源软件简史](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) ### 本部分内容贡献者 diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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 0a0c5e9..5e0036c 100644 --- "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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" @@ -44,7 +44,7 @@ 2. 职业软技能 开源的属性是开放的，因此开源社区的参与者数量会比平时工作要大得多。面对庞大的开源社区，需要更加有效的沟通和管理。这也是大家常说“开源实质上是一个管理问题”，。 - + 3. 参与大型团队，丰富简历 工作经验在求职中尤为重要，单纯的编程经验是不够的，你得知道怎么作为团队的一部分，和其他人一起合作；当然你可以通过课程或在工作中获得技能与经验，如果在没有合适机会的情况下，开源项目将提供绝佳的机会；成为贡献者，你不需要被这些公司雇佣，就能和这些优秀的团队一起工作；所有开源贡献都是公开的，它们可以证明你已掌握的技能和已完成的项目；例如：摄影师在寻找新客户时会展示他们的作品集，GitHub 和 Gitee 就是你的作品集。 diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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 c218cdb..dc3d806 100644 --- "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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" @@ -32,7 +32,7 @@ 短期回报是指通过开源短期内获取既得利益的行为。企业能够通过开源占领市场份额，获得更大的市场利益，比如：对外发放品牌授权、对外提供咨询和服务费用。此外，企业还可以通过吸引开源项目参与者，集思广益，反哺到自己闭源版本的项目，降低技术升级的成本。 ##### 项目质量提升、加快项目进度： - + 谷歌首席科学家杰夫·迪恩（Jeff Dean）指出，传统的软件研发实在是太慢了，通常是一个程序员花上几个月写完代码，然后上会讨论，再根据其他人的意见进行相应的修改。 相比之下，如果采用开源的协作开发形式，谷歌开发人员能够实时与科学界进行协作，谷歌之外的人才也能够参与 TensorFlow 源代码的编写，而机器学习技术的共享能够广泛吸引更多的技术人才完善 TensorFlow 系统。这样， TensorFlow 的开发进度就大大加快了。 diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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 fb12276..b6bf18e 100644 --- "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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" @@ -3,7 +3,7 @@ 在该项目中，除了 Linux Kernel 2.4 万开发者之外，还有很多其他的参与者。 -那么参与开源项目常用有那些参与方式呢？ +那么参与开源项目常用有那些参与方式呢？ ### 1. 直接参与开源项目的开发 @@ -32,7 +32,7 @@ ### 4. 参与开源项目的测试和 Demo 编写工作 -参与开源项目的版本测试并提交 Bug、参与完善项目的测试用例来提升测试覆盖度、完善 Demo 使用等都是参与开源项目的重要方式。 +参与开源项目的版本测试并提交 Bug、参与完善项目的测试用例来提升测试覆盖度、完善 Demo 使用等都是参与开源项目的重要方式。 ### 5. 参与开源项目推广 @@ -46,11 +46,11 @@ 有很多商业公司就是开源项目的发起者或者主要参与者。 -比如 Linux Kernel 中，代码贡献最多的是 Intel，其次是华为。华为同时也是 OpenHarmony 发起者。这些商业公司参与到开源项目中的人员，同时都是开源项目的参与者。 +比如 Linux Kernel 中，代码贡献最多的是 Intel，其次是华为。华为同时也是 OpenHarmony 发起者。这些商业公司参与到开源项目中的人员，同时都是开源项目的参与者。 ## 基于 Git 参与开源项目的方式 -Git 是开源的版本控制系统，GitHub 和 Gitee 都采用 Git 进行管理，在上面有着大量的开源项目。 +Git 是开源的版本控制系统，GitHub 和 Gitee 都采用 Git 进行管理，在上面有着大量的开源项目。 * GitHub 开源项目参与方式 @@ -61,7 +61,7 @@ GitHub 采用 Pull Requests 方式，可以快速的参与到开源项目中。 1. Fork 到自己的项目中 2. 在自己的项目上进行修改，提交。 3. 将自己项目 Pull Requests 到原始项目中。 -4. 原仓库作者进行审核，同意后进行合并。完成代码提交。 +4. 原仓库作者进行审核，同意后进行合并。完成代码提交。 * Gitee 开源项目参与方式 @@ -71,12 +71,10 @@ Gitee 创新地采用了 Gitee Pull Request Lite（Gitee 轻量级 PR），不 对于常见的「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)。 diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\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 c714289..cee6691 100644 --- "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 5 \345\260\217\350\212\202\357\274\232\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" @@ -58,7 +58,6 @@ OK，刚才我们用通俗易懂的类比向大家说明了什么叫「适合」 - 选择在工作和学习中使用比较多，比较熟悉的项目。这样你在动手修改它的代码之前就已经对它有了充分的了解，至少你是熟悉这个项目的各类使用方式和接口。 - 各个模块耦合性比较低的项目，比如组件库、工具库，容易找到入手点。如前端所使用的 Element UI ，Antd UI 组件库。组件库的耦合性较低，向组件库增加或修改某一个组件也较为方便。同时工具库也是一个不错的选择，新增或修改某一个功能也较为容易。相反，模块之间耦合性比较大的项目可能就不太合适，比如各种大型的框架，这类开源项目耦合性较高。 - ### 参与项目贡献的方法 - 成为 Contributor，参与项目代码维护与功能迭代； diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 6 \345\260\217\350\212\202\357\274\232\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" "b/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 6 \345\260\217\350\212\202\357\274\232\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" index c09f5d5..cc7b516 100644 --- "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 6 \345\260\217\350\212\202\357\274\232\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" +++ "b/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 6 \345\260\217\350\212\202\357\274\232\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" @@ -11,8 +11,6 @@ Issue 的翻译大致为**议题**、**问题**。 而根据 Gitee 官方的建议，项目相关的技术问题、缺陷报告、建议等信息都可以通过 Issue 进行发布。 - - ### 什么情况下需要提交 Issue 那么什么情况下需要提交 Issue 呢？ @@ -30,7 +28,7 @@ Issue 的翻译大致为**议题**、**问题**。 3. **讨论版 BBS** 可以完全将 Issue 模块当做你的仓库的私人论坛、私人社区来使用。围绕你的项目，你可以做如下的事情： - + * 提出你下一阶段想要添加的功能，请大家集思广益，这样会非常有利于知识和技术的沉淀，即使是当时没有参加讨论的开发者，事后也可以通过该 Issue 了解进行此功能设计的前因后果。 * 其他人有事想对作者询问、探讨，或咨询如何使用 * 其他人想要作者添加点新功能，提出来跟作者讨论讨论 @@ -43,8 +41,6 @@ Issue 的翻译大致为**议题**、**问题**。 * 对于你自己来说，可以使用 Issue 来发布待办清单，给自己提开发任务或 Bug，开帖找大家探讨项目下一步的发展方向等等。当然，你也可以用它来提出一些跟仓库内容无关的事情，这也是允许的。 * 如果你想要提 Issue 的仓库不是你自己的，而是他人的的时候，Issue 就是一个很好的多人协作系统。比如发现了别人项目的 Bug 的时候；比如想要别人添加某个新功能的时候；比如有使用上的困难，需要求助作者使用步骤的时候，你都可以给别人的仓库提出 Issue。同时，如果你是一个热心的开发者，你也可以帮助原作者回答一些别人提出的 Issue，这样的行为可以极大地帮助原作者分担压力哦。不要觉得自己是在做临时免费工，解答的过程中你的知识和技术也会得到巩固和提高，有时还能结交到许多志同道合的好朋友哦。我助人，人亦助我。 - - ### 一个好的 Issue 应该写些什么 那么一个好的 Issue 应该写点什么呢？ @@ -83,12 +79,8 @@ Issue 的翻译大致为**议题**、**问题**。 ```markdown ### 该问题是怎么引起的？ - - ### 重现步骤 - - ### 报错信息 ``` @@ -116,8 +108,6 @@ Issue 的翻译大致为**议题**、**问题**。 好了，当你完成 Issue 主体内容的填写之后，快去提交给作者吧！ - - ### Issue 案例（有价值和无价值） 下面我们来看几个 Issue 的案例。 @@ -164,8 +154,6 @@ Issue 的翻译大致为**议题**、**问题**。 因此，Issue 的精准表述是能获得良好协作的基础，提 Issue 也是一种很好的练习表达的方式。 - - ### Issue 的进阶使用 掌握了 Issue 的基础使用之后，作为一个优秀的开发者，我们还可以掌握一些进阶的知识，它能让你压榨干净 Issue 的每一分价值。 @@ -197,13 +185,13 @@ Issue 的翻译大致为**议题**、**问题**。 先进入企业面板，进入所在企业： ![先进入企业面板，进入所在企业](https://images.gitee.com/uploads/images/2020/1104/121905_7de2c1b7_1277510.png "image-20201103211346712.png") - + 右上角新建项目可以新建： - + ![右上角新建项目可以新建](https://images.gitee.com/uploads/images/2020/1104/121940_60a50a92_1277510.png "image-20201103211512199.png") - + 查看新建的项目： - + ![查看新建的项目](https://images.gitee.com/uploads/images/2020/1104/122018_2ef66098_1277510.png "image-20201103211600514.png") * **里程碑**：里程碑是某功能或某个时间段的一堆问题的集合。比如我们要写一本书，一个章节如果设置为一个里程碑，那这个章节里面的每一个小节我们就可以分别提多个 Issue，最后将这些 Issue 关联到这个章节的里程碑中，方便管理，可以很容易看到整个章节的完成进度。我们可以根据自己的需要，来使用里程碑的功能。下面是一些使用里程碑功能的例子[1]： @@ -317,10 +305,6 @@ Gitee 支持的提交方式有（比如我们需要关闭的 Issue 编号为 24 > 请注意，设置未勾选状态时，方括号之间会有一个空格`[ ]`，不要漏掉了。 - - - - ### 参考资料 [1] [https://guides.github.com/features/issues/](https://guides.github.com/features/issues/) diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 7 \345\260\217\350\212\202\357\274\232\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Pull Request.md" "b/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 7 \345\260\217\350\212\202\357\274\232\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Pull Request.md" index 1b68d0b..aadf91f 100644 --- "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 7 \345\260\217\350\212\202\357\274\232\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Pull Request.md" +++ "b/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 7 \345\260\217\350\212\202\357\274\232\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Pull Request.md" @@ -8,14 +8,12 @@ merge pull request的流程相对简单，是通过两个自己项目的repo进行的阐述，需要补充权限说明，code review，approve，CI机制等 ``` - #### 什么是 Pull Request 这个是由 GitHub 提出的概念。根据 GitHub 的官方文档，Pull Request 是一种通知机制，它可以告知仓库的其他开发者，你推送了一个仓库新分支。 通过Pull Request ，你可以和仓库的协作者一起讨论和审查提交的代码，审查通过后，就可以提交到仓库的主分支中。 Pull Request 本质上是一种协同工作的机制，可以进行基于网络的多人提交，审核机制，审核通过后，就可以合并到主分支中。 - #### 提交 Pull Request 的步骤 第一步，你需要 Fork 别人的仓库。也就是复制别人的仓库到你自己的仓库中。 @@ -26,7 +24,6 @@ Pull Request 本质上是一种协同工作的机制，可以进行基于网络 第三步，在提交中，描述提交本地提交的说明。 - #### 实际操作一下 ##### Gitee @@ -76,7 +73,7 @@ Pull Request 本质上是一种协同工作的机制，可以进行基于网络 1. 在 GitHub 上建立两个帐号 A 和 B。 2. 使用 A 帐号，创建项目 pull_request_demo - + 3. 在本地提交 README.md ``` diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 8 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 8 \345\260\217\350\212\202\357\274\232\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 8560f55..21841b1 100644 --- "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 8 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 8 \345\260\217\350\212\202\357\274\232\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" @@ -48,7 +48,6 @@ 如果以上几点你都具备了，恭喜你，你已经基本达到了应有的水平。最后的一件事情就是，你不能总是照着别人已经做好的事情做搬砖的事情。那么如何才能将贡献的内容注入自己的灵魂？把你的思维和想法分享给大家，让大家也能从你贡献的内容中有所收获，有所领悟，那么就需要你不断的学习新的东西，技术更新非常之快，那么就需要我们对于自己专业的领域有更多自己的看法，这样才会有更多的创新思路，才会让我们这个领域有更多可发展和延伸的道路。 - ## 如何成为一个项目的核心贡献者（补充） 1.要顾全的大局 diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 9 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 9 \345\260\217\350\212\202\357\274\232\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 ff1b6d8..39fa8ec 100644 --- "a/\347\254\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 9 \345\260\217\350\212\202\357\274\232\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\254\344\270\211\351\203\250\345\210\206\357\274\232\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\347\254\254 9 \345\260\217\350\212\202\357\274\232\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" @@ -9,7 +9,6 @@ ## 贡献准则 - 有助于创建积极环境的行为包括但不限于： - 措辞体贴，友好和耐心 diff --git "a/\347\254\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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 9965472..6da6d39 100644 --- "a/\347\254\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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" @@ -57,10 +57,7 @@ GVP 是 Gitee 官方综合评定出的优秀开源项目的展示平台，GVP ### Gitee 指数 Gitee 为每个开源项目都设置了「Gitee 指数」作为判断开源项目优秀程度的辅助参考。综合五个不同维度的得分，进而产生一个最终的 Gitee 指数，Gitee 指数越高，说明该项目越值得学习和使用。 -![](https://images.gitee.com/uploads/images/2021/0104/104817_073e4ef5_5694891.png) - - - +![](https://images.gitee.com/uploads/images/2021/0104/104817_073e4ef5_5694891.png) ## 如何在 GitHub 上找到合适的开源项目 @@ -112,7 +109,6 @@ Gitee 为每个开源项目都设置了「Gitee 指数」作为判断开源项 更多搜索语法相关内容，请查阅 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 趋势榜，更容易找到适合自己学习和使用的优质项目。 diff --git "a/\347\254\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 3 \345\260\217\350\212\202\357\274\232\350\256\244\350\257\206\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201.md" index 9f1bbda..ee02195 100644 --- "a/\347\254\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 3 \345\260\217\350\212\202\357\274\232\350\256\244\350\257\206\345\274\200\346\272\220\350\256\270\345\217\257\350\257\201.md" @@ -1,6 +1,5 @@ # 第 3 小节：认识开源许可证 - ## 一、什么是开源许可证（License） 开源许可证是一种法律许可。通过它，版权拥有人明确允许，用户可以免费地使用、修改、共享版权软件。 @@ -9,7 +8,6 @@ 版权法默认禁止共享， **也就是说，没有许可证的软件，就等同于保留版权** 。虽然开源了，但用户只能查看源码，无法使用，否则就会侵犯版权。所以如果选择开源一款软件，必须明确地授予用户开源许可证。 - ## 二、开源许可证的种类 目前，国际公认的开源许可证共有 [100 多种](https://opensource.org/licenses/alphabetical)。它们的共同特征是，都允许用户免费地使用、修改、共享源码，但是都有各自的使用条件。 @@ -27,7 +25,6 @@ | :---------------------------------------------------------- | ------------------------------------------------------------ | | 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.宽松式许可证 @@ -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 协议约束的判断规则也存在争议。 待补充 - - - ### 六、怎么选择开源许可证？ 可查看开源指北中 [**启动自己的开源项目/开源许可证的应用**](./第4部分——启动自己的开源项目/第%203%20小节：开源许可证的应用.md) 部分 @@ -231,8 +221,6 @@ Common 许可证有一些细节性的规定值得参考: ![img](https://www.ruanyifeng.com/blogimg/asset/201105/bg2011050101.png) - - --- ### 参考资料 diff --git "a/\347\254\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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 c256927..2bcea44 100644 --- "a/\347\254\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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\254\344\272\214\351\203\250\345\210\206\357\274\232\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/\347\254\254 4 \345\260\217\350\212\202\357\274\232\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" @@ -23,8 +23,6 @@ 还有就是目前赞赏文化已然收到了了社会上主流文化的认可和科技公司的推崇。赞赏文化是计算机科学领域的一种文化现象，源自对黑客精神的敬仰及对智慧成果的共享的感恩。不过，它的发展也不排除利益驱动。一方面是个人对自己影响力的打造，还有一方面是公司极端对招聘、向市场投放自己产品的需求。还有一个原因那就是其它媒体文化的感染，说到这就可以追溯到早期的 BBS，再到贴吧、知乎，以及后起之秀抖音、快手和 B 站。这是每一个参与者对内容及创作人的鼓励和肯定，累计到一起的行为习惯带动了开源事业更好的发展。 - - ### 赞赏文化的意义 赞赏文化发展到现在，这种能够积极促进程序员交流、项目推进的文化已经受到了广大程序员群体的认可。很多黑客贡献代码的初衷首先就是个人价值。 @@ -43,6 +41,3 @@ [lijiacheng](https://gitee.com/Baron_Lee)、[YZRDEG](https://gitee.com/YZRDEG)、[ORH](https://gitee.com/orh)、[taotieren](https://gitee.com/taotieren) - - - diff --git "a/\347\254\254\344\272\224\351\203\250\345\210\206\357\274\232\345\274\200\346\272\220\346\262\273\347\220\206/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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\254\344\272\224\351\203\250\345\210\206\357\274\232\345\274\200\346\272\220\346\262\273\347\220\206/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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 1d32d2e..410165d 100644 --- "a/\347\254\254\344\272\224\351\203\250\345\210\206\357\274\232\345\274\200\346\272\220\346\262\273\347\220\206/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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\254\344\272\224\351\203\250\345\210\206\357\274\232\345\274\200\346\272\220\346\262\273\347\220\206/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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" @@ -43,7 +43,6 @@ 尽管社区的组织形式不尽相同，但是一般都会有核心决策团体或者管理委员会来从技术和项目管理的角度履行管理者的权力。甚至有些社区组织结构非常接近于公司的产品开发，从而保证其协同效率。 - ## 个人维护 VS 建设社区 从上面的描述中可以看出，个人维护更加适合初期学习开源项目维护的朋友，积累沟通协作的经验，深入理解开源文化和开源世界。 diff --git "a/\347\254\254\344\272\224\351\203\250\345\210\206\357\274\232\345\274\200\346\272\220\346\262\273\347\220\206/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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\254\344\272\224\351\203\250\345\210\206\357\274\232\345\274\200\346\272\220\346\262\273\347\220\206/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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 8a89d50..e457553 100644 --- "a/\347\254\254\344\272\224\351\203\250\345\210\206\357\274\232\345\274\200\346\272\220\346\262\273\347\220\206/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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\254\344\272\224\351\203\250\345\210\206\357\274\232\345\274\200\346\272\220\346\262\273\347\220\206/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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" @@ -12,7 +12,6 @@ 应该选择哪一种模式了呢？每个模式都有优点，也有缺点。如果是非公司开源项目，可以在开始的时候简单定义基本的流程。例如，你可以将某些预期的行为定义清楚，贡献的流程是如何的，或者项目是如何启动的，等等。如果是公司开源的项目，在启动之前，应该做一些讨论，如公司将会如何维护项目，随着项目的发展，决策该如何定夺。可以公开的解释一下，开源之后，公司是否还继续参与贡献，还是完全由社区决定，等等。没有最优的答案，一切在于出自内心的选择。 - ### Node.js 的自由贡献规则 1.Node.js 核心库：Node.js 核心代码库在 https://github.com/nodejs/node。你可以尝试通过提 PR 与 Issue 的形式为核心代码库做贡献。 @@ -21,7 +20,6 @@ 3.Node.js 生态圈：即使你对核心库与工作组的东西不感兴趣，也可以通过参与生态建设的方式做出贡献，例如参加 Node.js 的布道，出席社区聚会等等。 - ### BDFL 治理模型 - #### 总览 1. 项目由仁慈的独裁者领导，并由社区管理。也就是说，社区积极地为项目的日常维护做出了贡献，但是仁慈的独裁者划定了总体战略方针。如有分歧，则保留最后决定权。解决社区内部的争端并确保项目能够以协调的方式进行，这是仁慈的独裁者的工作。反过来，通过积极的参与和贡献来指导仁慈的独裁者的决定是社区的工作。 @@ -34,21 +32,16 @@ - #### 社区治理方向 当项目的团队还比较小的时候，而且用户的社区也比较小，这时仁慈的独裁者会按照传统的自上而下的方式来做出所有的决策。然而，随着社区的增长，这会变得越来越困难，很少有人能够完全理解所要解决问题的所有细节，因此，他们可能会对在不怎么专业的领域所做出的决定不是太有把握。随着项目规模和范围的扩大，人们对于不能有十足把握的模块也会增长，那么作为项目的带头人，就无法做到面面俱到。基于如上原因，一个颇为高效率的独裁者会慢慢转变为协调者，或者叫做仲裁者，他们通常情况下，不会在辩论当中站队，Linux Torvalds曾经说过，“我宁愿看到的场面是有 15 个人为一个问题而争执的面红耳赤，而不愿意看到 15 个人分成两支队伍，每支队伍都只和自己观点相近的人说话。 - - ### 三种治理架构对应的模板，供参考： - ``` 需补充以下三种案例的模版或规则 ``` - - BDFL 模式模版 - 精英模式模版 - Node.js 的自由贡献规则 - ## 参考 - [1] [Benevolent Dictator Governance Model](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) diff --git "a/\347\254\254\345\205\255\351\203\250\345\210\206\357\274\232\345\205\266\344\273\226\351\227\256\351\242\230/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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\254\345\205\255\351\203\250\345\210\206\357\274\232\345\205\266\344\273\226\351\227\256\351\242\230/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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 901bef7..f6c3208 100644 --- "a/\347\254\254\345\205\255\351\203\250\345\210\206\357\274\232\345\205\266\344\273\226\351\227\256\351\242\230/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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\254\345\205\255\351\203\250\345\210\206\357\274\232\345\205\266\344\273\226\351\227\256\351\242\230/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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 的企业或者企业员工或全职开源者。 - - 开源不是工作，开源更多的是一种对自我能力、自我影响力或自我约束力的升华。在写这篇文章之前，我专门向多位开源圈的大佬请教过这个问题，大佬们给我的答案大部分意思都一样，总结一下就是：**学会规划自己的时间，要明确工作是工作，开源是开源，开源一定是牺牲自己的业余时间去做的**。 ## 工作能带给我们什么？ @@ -23,15 +21,12 @@ 个人能力锻炼和提升： - 1. 专业技术能力； 2. 架构设计和模块化思维能力； 3. 团队精神和协作能力； 4. 文档习惯和写作能力； 5. 需求理解能力； - - 精神生活丰富有趣味： 1. 参与大型团队，比肩业内大佬； @@ -40,7 +35,6 @@ 4. 偶有项目奖励，内心喜不自禁； 5. 个性创新不断，行业视角更广； - 关于这部分详细内容，请参考 [开源与个人技术成长](../第 1 部分——初识开源/开源与个人技术成长.md)、[个人为什么要参与开源贡献](../第 3 部分——尝试参与开源/个人为什么要参与开源贡献.md) - 提升专业技术能力 @@ -49,7 +43,6 @@ - 丰富阅历、拓宽知识面 - 结识更多领域的专家 - ## 亲身经历 在这儿，我不妨先给大家分享一些我的亲身经历： @@ -132,7 +125,7 @@ OK，言归正传，书接上文。我们应该怎么办？应该怎么做到两 该条建议也是“如何平衡本职工作和开源项目”的最重要的，因为是 **和你切身利益相关** 。 -友情提示， **不要存在侥幸心理** +友情提示， **不要存在侥幸心理** ## 总结 @@ -144,7 +137,6 @@ OK，言归正传，书接上文。我们应该怎么办？应该怎么做到两 4. 家人的支持 5. 开源的选题 - ## 结语 这篇文章是我在工作之外，利用自己的业余时间，前前后后构思了好久才写完的。内容可能不尽人意，各位看官暂且一阅，欢迎指正欢迎交流。 diff --git "a/\347\254\254\345\205\255\351\203\250\345\210\206\357\274\232\345\205\266\344\273\226\351\227\256\351\242\230/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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\254\345\205\255\351\203\250\345\210\206\357\274\232\345\205\266\344\273\226\351\227\256\351\242\230/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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 3a985c8..376b25d 100644 --- "a/\347\254\254\345\205\255\351\203\250\345\210\206\357\274\232\345\205\266\344\273\226\351\227\256\351\242\230/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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\254\345\205\255\351\203\250\345\210\206\357\274\232\345\205\266\344\273\226\351\227\256\351\242\230/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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" @@ -8,7 +8,7 @@ 开源项目到底是基于什么开源协议对外开放？ -当你看到这个章节的时候相信你对以上话题有了一定的认知和了解 +当你看到这个章节的时候相信你对以上话题有了一定的认知和了解 ### 开源和商业化的理解 @@ -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,21 +69,19 @@ 部分成功的商业化开源项目 - ``` 需补充商业化前的背景，商业化后的发展情况。 ``` - -> Red Hat +> Red Hat Red Hat Enterprise Linux 是 Red Hat 公司的 Linux 发行版，面向商业市场，包括大型机。 -> MySQL +> MySQL MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，属于 Oracle 旗下产品。 -> MariaDB +> MariaDB MariaDB 数据库管理系统是 MySQL 的一个分支，主要由开源社区在维护，采用 GPL 授权许可。MariaDB 的目的是完全兼容 MySQL，包括 API 和命令行，使之能轻松成为 MySQL 的代替品。 @@ -96,7 +89,7 @@ MariaDB 数据库管理系统是 MySQL 的一个分支，主要由开源社区 OceanBase 是由蚂蚁集团完全自主研发的金融级分布式关系数据库，始创于 2010 年。OceanBase 具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准和主流关系数据库、低成本等特点。 -> React +> React 用于构建用户界面的 JavaScript 库 @@ -117,8 +110,6 @@ antd 是基于 Ant Design 设计体系的 React UI 组件库，主要用于研 大名鼎鼎的虚幻 4 游戏引擎。拥有独创的蓝图系统，降低了游戏开发门槛。渲染效果逼真，甚至被大量用于电影和 CG 渲染。虚幻商场提供了大量预设资源，降低了游戏开发成本。且虚幻引擎本身的使用是完全免费的，在发行产品（使用虚幻 4 引擎制作的包括但不限于游戏的商业发行产品）开始商业化运营，且总营收超过 1000000 美金后才开始支付 5% 的分成费用，使独立游戏开发者能够投入更多精力到游戏开发之中，而不必担心引擎授权费问题。正是由于这些优点，使虚幻 4 成为了最为著名和使用最为广泛的游戏引擎之一。 - - 还有很多很多开源项目走向了商业化…… [langengel](https://gitee.com/langengel)、[阿基米东](https://gitee.com/luhuadong)、[YZRDEG](https://gitee.com/YZRDEG)、[雪山凌狐](https://gitee.com/xueshanlinghu)、[WhitePaper](https://gitee.com/whitepaper233)、[taotieren](https://gitee.com/taotieren)、[Hong.T](https://gitee.com/dcoder)、[zeroTwozeroTwo](https://gitee.com/zerotwozerotwo) \ No newline at end of file diff --git "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 1 \345\260\217\350\212\202\357\274\232\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" "b/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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 a7f8634..1aea1bc 100644 --- "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 1 \345\260\217\350\212\202\357\274\232\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" +++ "b/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 1 \345\260\217\350\212\202\357\274\232\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" @@ -137,6 +137,5 @@ 如果开源项目分值数太少，可以和开源课程、自媒体、公众号、短视频、写书等结合在一起，既可以为项目加分又可以传播开源项目知识，增加开源项目的流量访问，同时也贡献了自己的一份开源力量。 - ### 本部分内容贡献者 [bryan31](https://gitee.com/bryan31)、[雪山凌狐](https://gitee.com/xueshanlinghu)、[阿基米东](https://gitee.com/luhuadong)、[OSrcD](https://gitee.com/OpenDevel)、[沈唁](https://gitee.com/sy-records)、[taotieren](https://gitee.com/taotieren)、[WhitePaper](https://gitee.com/whitepaper233) \ No newline at end of file diff --git "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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 09a9dd4..49fa7db 100644 --- "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 2 \345\260\217\350\212\202\357\274\232\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" @@ -13,7 +13,6 @@ 另外，朗朗上口的名称也会让人跟容易记忆。这可能有关语言学，但是很多成功的项目表明，使用双音节，辅音+元音，会有很好的效果！ - 再缩小范围，就是技术群体喜欢的科幻、魔幻作品，比如星球大战、漫威、哈利波特、迪士尼等等。我尝试在下面列出一些已有的和我想到的例子： | 项目名称 | 项目类型 | 原意 | @@ -25,7 +24,6 @@ | Tomcat | Web 服务管理器 | 经典的汤姆猫 | | SkyWalking | 观察性分析、应用性能管理 | 天空行走，非常形象 | - 相比还有很多优秀的项目，都有这种让人过目不忘的名称，欢迎继续补充。 ### 如何打造一个优秀的 README @@ -46,7 +44,6 @@ README 应该包含哪些内容： - 参与贡献方式：指引开发者们如何参与到项目中协同完善整个开源项目； - 开源协议：开源协议类型指引。 - 也可以参考成熟的开源项目以及同类型开源项目中的 README 的内容。 ### 为项目撰写文档 @@ -77,7 +74,6 @@ README 应该包含哪些内容： ### 开源项目的代码质量要求 - 一个认真打造的开源项目，肯定是希望有其他用户来使用，更希望有更多外部贡献者能参与进来的。那么评价一个开源项目好不好，代码的质量就是非常重要的衡量指标了。 代码质量是程序员的基本功，说到这个话题，首先自然是需要去翻阅经典的专著了，《重构》、《设计模式》、《代码整洁之道》是程序员必备的手边书。 diff --git "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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 62f9a75..9ebee89 100644 --- "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 3 \345\260\217\350\212\202\357\274\232\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" @@ -33,8 +33,6 @@ - 解决联盟存在互诉漏洞，也就是 A 想诉 B，A 授权 C，由 C 可以诉 B 的问题。 - 比 Apache License 更友好一些，Apache License 要求列出每个修改文件，其实很多项目做不到这一点，所以 MulanPSL 直接取消了这项要求。 - - #### 快速选择 国内大神阮一峰根据乌克兰程序员 Paul Bagwell 的开源许可证选择分析图翻译的一份 [中文版本](http://www.ruanyifeng.com/blogimg/asset/201105/free_software_licenses.png)，是我目前见过的最通俗易懂的解析，因为语法支持的问题，用以下代码大致表示为： @@ -57,7 +55,7 @@ 是否需要对源码的 | | | 修改之处，提供说 | 衍生软件的广告， | 明文档？ GPL 是否可以用你的名 Apache - ----- No ----- ----- Yes ----- 字促销？ + ----- No ----- ----- Yes ----- 字促销？ | | ----- No ----- ----- Yes ----- | | | | | | | | diff --git "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 5 \345\260\217\350\212\202\357\274\232\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\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 5 \345\260\217\350\212\202\357\274\232\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 f45c74a..0f558fd 100644 --- "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 5 \345\260\217\350\212\202\357\274\232\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\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 5 \345\260\217\350\212\202\357\274\232\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" @@ -33,7 +33,6 @@ 7、社区联合推广。可以尝试与其他社区互动，联合组织上文提到的各种线上或线下活动，以便相互促进。选择联合社区时，优先考虑与本项目在生态上的可集成性、互操作性、兼容性较强的项目社区，且不限于开源项目社区，也可以考虑本地化的知名或热门技术社区。总的原则是目标群体聚集的社区，一般都是比较好的潜在联合对象。 - ### 项目被提交 Issue 时应该怎么做？ 当我们的开源项目上线之后，后期是需要维护和版本迭代的。Issue 是记录各类 Bug、需求的方式，也是开发者之间非常重要的的交流工具。参与者可以通过各种状态的 Issue，看到针对各种问题或者需求的详细内容，也可以通过提交 Comment 的方式参与沟通讨论。 Issue 的数量、打开和关闭的比例以及针对 Issue 的处理是否及时等，这些都成为衡量一个开源项目是否健康且受欢迎的重要指标。 diff --git "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 6 \345\260\217\350\212\202\357\274\232CONTRIBUTING \347\274\226\345\206\231.md" "b/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 6 \345\260\217\350\212\202\357\274\232CONTRIBUTING \347\274\226\345\206\231.md" index dad7a87..685ede7 100644 --- "a/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 6 \345\260\217\350\212\202\357\274\232CONTRIBUTING \347\274\226\345\206\231.md" +++ "b/\347\254\254\345\233\233\351\203\250\345\210\206\357\274\232\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/\347\254\254 6 \345\260\217\350\212\202\357\274\232CONTRIBUTING \347\274\226\345\206\231.md" @@ -4,8 +4,6 @@ > ​ CONTRIBUTING 文件用来告诉人们如何对项目做出贡献. - - ## CONTRIBUTING 如何编写 在 **CONTRIBUTING** 文件中会含有下面这些主题的内容（可能不完整, 请各位读者进行补充） @@ -21,8 +19,6 @@ 7. 分支处理的约定 8. 合并 PR 的形式 - - ### 例子 ```md @@ -39,7 +35,7 @@ 提出新功能有些项目使用 Issues 的 Feature 标签进行管理, 有些则通过邮件的形式统一收集. 在收集后项目内人员会进行确认开发, 一般的将确认开发的功能会放入下一个版本的任务列表 ## 如何设置开发环境并运行测试 -如果是通过 Git 管理可以从 `git clone xxx` 开始编写, 将开发环境的配置信息, IDE 的设置等信息配置文档编写. +如果是通过 Git 管理可以从 `git clone xxx` 开始编写, 将开发环境的配置信息, IDE 的设置等信息配置文档编写. ## 变更日志填写规则 1. 使用现在时态 diff --git "a/\347\274\226\345\206\231\345\274\225\345\257\274-1.0.md" "b/\347\274\226\345\206\231\345\274\225\345\257\274-1.0.md" index 1e54615..850c8fc 100644 --- "a/\347\274\226\345\206\231\345\274\225\345\257\274-1.0.md" +++ "b/\347\274\226\345\206\231\345\274\225\345\257\274-1.0.md" @@ -7,13 +7,12 @@ 那么，开源的问题为什么不用开源的方式去解决呢？于是现在有了这样一个仓库，我们邀请广大开发者、开源爱好者、开源社区等与我们一起编写这本 **《开源指北》** ，分享自己对开源的认识和参与开源实践的经历，为那些想参与开源的开发者们提供一个丰富详实的操作指南，让更多开发者认识开源、参与开源、爱上开源。 #### :tw-27a1: 快速引导 -1. 查看[目录](/%E7%9B%AE%E5%BD%95.md) ，了解本次电子书需编写的章节内容 -2. 查看[内容编写进度](https://gitee.com/Selected-Activities/opensource-guide/board?issue_type_id=261607)，若感兴趣的章节处于“待编写”的状态，则可在[目录](/%E7%9B%AE%E5%BD%95.md)中点击该章节 ，评论 「id+预计完成时间」领取编写任务，工作人员更改编写状态，回复“已确定”则可开始编写；若处于“待补充”状态，可直接点击【编辑】按钮，通过[轻量级 PR ](https://gitee.com/help/articles/4291)的方式对内容进行补充； -详情请查看>>[编写指南](/编写指南.md) -3. 加入编写社群，提交领取章节，获取活动实时信息，抽取惊喜好礼 -添加 Gitee 小助手（gitee2013），备注「1024」，拉你入群 -![输入图片说明](https://images.gitee.com/uploads/images/2020/0712/212657_b00725ef_1899542.png "150-小助手微信.png") - +1. 查看[目录](/%E7%9B%AE%E5%BD%95.md) ，了解本次电子书需编写的章节内容 +2. 查看[内容编写进度](https://gitee.com/Selected-Activities/opensource-guide/board?issue_type_id=261607)，若感兴趣的章节处于“待编写”的状态，则可在[目录](/%E7%9B%AE%E5%BD%95.md)中点击该章节 ，评论 「id+预计完成时间」领取编写任务，工作人员更改编写状态，回复“已确定”则可开始编写；若处于“待补充”状态，可直接点击【编辑】按钮，通过[轻量级 PR ](https://gitee.com/help/articles/4291)的方式对内容进行补充； +详情请查看>>[编写指南](/编写指南.md) +3. 加入编写社群，提交领取章节，获取活动实时信息，抽取惊喜好礼 +添加 Gitee 小助手（gitee2013），备注「1024」，拉你入群 +![输入图片说明](https://images.gitee.com/uploads/images/2020/0712/212657_b00725ef_1899542.png "150-小助手微信.png") #### :tw-1f4cc: 《开源指北》制作流程 @@ -33,7 +32,6 @@ * 最佳实践/案例 - #### :tw-1f64b: 参与编写者要求 我们的初衷是希望能够通过这个文档为刚接触开源的伙伴们普及开源基础知识，提供参与开源过程的经验分享，我们欢迎任何热爱开源的开发者或组织社区加入编写，如果你符合以下的任意条件，即可加入我们的编写队伍。 @@ -43,40 +41,38 @@ * 没有特别丰富的开源实践经验，但有较强的的信息检索与过滤能力，能提供详实的参考资料。 #### :tw-1f4dd: 如何参与编写 -* 想要直接参与编写？点击查看[编写指南](/%E7%BC%96%E5%86%99%E6%8C%87%E5%8D%97.md)。 +* 想要直接参与编写？点击查看[编写指南](/%E7%BC%96%E5%86%99%E6%8C%87%E5%8D%97.md)。 * 想要围观？欢迎你在评论区留下你宝贵的意见。 - -#### :tw-1f4b0: 通过活动你可以获得 -* 一次亲身参与开源项目的经历，并成为 Gitee 官方开源电子文档编写成员（将在开源指北电子书“编写成员”栏署名，并颁发纸质证书） - -* 所有参与者（提交了符合规则的 PR）都可参与抽奖，抽取 Deepin 背包、企业级智能组网路由器、Gitee 皮质桌垫、七牛云抱枕等惊喜好礼。 - -* 所有编写者（符合规则的 PR 并被评审团合并）都可获得纪念 T 恤一件 - - -#### :tw-1f466: 审校专家团队 -为保证电子文档的内容更有参考价值，Gitee 内容组特别邀请了几位技术专家担任本次的审校人员（以下名单按首字母排序）： - -**代立冬** -易观大数据平台总监，负责每日数百亿条数据处理链条的架构设计，技术选型，技术攻关等工作。十分热爱开源，是大数据任务调度 - Apache DolphinScheduler 的 PPMC & Committer，也活跃于各个大数据开源社区。 - -**潘娟** -京东数科高级DBA，Apache ALC Beijing member， Apache ShardingSphere PMC 主要负责京东数科分布式数据库开发、数据库运维自动化平台开发等工作。曾负责京东数科数据库自动化平台设计与开发，现专注于Apache ShardingSphere分布式数据库中间件生态的架构及研发。主要在分布式数据库、开源、分布式架构等相关领域进行探索。多次受邀参加数据库&架构领域的相关会议并进行分享交流。 - -**卫剑钒** -开源“圣经”《大教堂与集市》中文版译者，国际信息系统安全认证专家（CISSP），目前就职于某大型金融机构，从事信息科技管理工作。曾发表过《开源的7大理念》、《从契约精神谈MIT协议》、《copyright的真正含义是什么》、《步进式解读Apache许可证》、《使用Apache协议的是自由软件吗》等文章。 - -**张亮** + +#### :tw-1f4b0: 通过活动你可以获得 +* 一次亲身参与开源项目的经历，并成为 Gitee 官方开源电子文档编写成员（将在开源指北电子书“编写成员”栏署名，并颁发纸质证书） + +* 所有参与者（提交了符合规则的 PR）都可参与抽奖，抽取 Deepin 背包、企业级智能组网路由器、Gitee 皮质桌垫、七牛云抱枕等惊喜好礼。 + +* 所有编写者（符合规则的 PR 并被评审团合并）都可获得纪念 T 恤一件 + +#### :tw-1f466: 审校专家团队 +为保证电子文档的内容更有参考价值，Gitee 内容组特别邀请了几位技术专家担任本次的审校人员（以下名单按首字母排序）： + +**代立冬** +易观大数据平台总监，负责每日数百亿条数据处理链条的架构设计，技术选型，技术攻关等工作。十分热爱开源，是大数据任务调度 - Apache DolphinScheduler 的 PPMC & Committer，也活跃于各个大数据开源社区。 + +**潘娟** +京东数科高级DBA，Apache ALC Beijing member， Apache ShardingSphere PMC 主要负责京东数科分布式数据库开发、数据库运维自动化平台开发等工作。曾负责京东数科数据库自动化平台设计与开发，现专注于Apache ShardingSphere分布式数据库中间件生态的架构及研发。主要在分布式数据库、开源、分布式架构等相关领域进行探索。多次受邀参加数据库&架构领域的相关会议并进行分享交流。 + +**卫剑钒** +开源“圣经”《大教堂与集市》中文版译者，国际信息系统安全认证专家（CISSP），目前就职于某大型金融机构，从事信息科技管理工作。曾发表过《开源的7大理念》、《从契约精神谈MIT协议》、《copyright的真正含义是什么》、《步进式解读Apache许可证》、《使用Apache协议的是自由软件吗》等文章。 + +**张亮** 京东数科数字技术中心架构专家，Apache ShardingSphere，ElasticJob 创始人。热爱开源，擅长以 Java 为主分布式架构，推崇优雅代码。 目前主要精力投入在将分布式数据库中间件 Apache ShardingSphere 打造为业界一流的金融级数据解决方案之上。 -Apache ShardingSphere 是京东主导的首个 Apache 软件基金会顶级项目，也是 Apache 软件基金会首个分布式数据库中间件。曾出版书籍《未来架构——从服务化到云原生》。 - -（其他审校人员待公布） - +Apache ShardingSphere 是京东主导的首个 Apache 软件基金会顶级项目，也是 Apache 软件基金会首个分布式数据库中间件。曾出版书籍《未来架构——从服务化到云原生》。 + +（其他审校人员待公布） + #### :tw-1f3e1: 支持社区 ![输入图片说明](https://images.gitee.com/uploads/images/2020/1109/111440_42e3a169_1899542.png "支持社区-11-9.png") - ### License diff --git "a/\347\274\226\345\206\231\346\214\207\345\215\227.md" "b/\347\274\226\345\206\231\346\214\207\345\215\227.md" index 8b3300f..0c33605 100644 --- "a/\347\274\226\345\206\231\346\214\207\345\215\227.md" +++ "b/\347\274\226\345\206\231\346\214\207\345\215\227.md" @@ -21,7 +21,7 @@ ### 参与流程 ![输入图片说明](https://images.gitee.com/uploads/images/2020/0910/171310_88ee84ac_5694891.png "屏幕截图.png") -**具体操作指引** +**具体操作指引** 1. 从目录中选择自己想要参与编写的部分后，前往 [Issue 页面](https://gitee.com/gitee-community/opensource-guide/board?issue_type_id=261607) 进行内容认领。 @@ -52,14 +52,12 @@ 该部分内容仅接受 **符合主题且对已有内容进行补充** 的 PR。 - * 📔 已完成 该部分内容已经完成，但还没有经过审校专家团队进行审核。 该部分仅接受 **原则性错误修改/额外信息补充** 的 PR。 - * ✅ 已审核 该部分内容已经完成，并经过了审校专家团队的审核。 diff --git "a/\347\274\226\345\206\231\350\247\204\350\214\203.md" "b/\347\274\226\345\206\231\350\247\204\350\214\203.md" index a99a5c1..2c808c8 100644 --- "a/\347\274\226\345\206\231\350\247\204\350\214\203.md" +++ "b/\347\274\226\345\206\231\350\247\204\350\214\203.md" @@ -1,203 +1,202 @@ -标准的格式是优质内容的基础，制定本规范的目的是统一文档内容中的中英文文字规范，提升内容的严谨度和美观度。 - -### 空格 - -#### 中英文之间需要增加空格 - -正确： ->*在 LeanCloud 上，数据存储是围绕* `AVObject` 进行的。 - -错误： -> *在LeanCloud上，数据存储是围绕*`AVObject`进行的。 - -> *在 LeanCloud上，数据存储是围绕*`AVObject` 进行的。 - -完整的正确用法： - ->*在 LeanCloud 上，数据存储是围绕* `AVObject` 进行的。每个 `AVObject` 都包含了与 JSON 兼容的 key-value 对应的数据。数据是 schema-free 的，你不需要在每个 `AVObject` 上提前指定存在哪些键，只要直接设定对应的 key-value 即可。 - -例外：「豆瓣FM」等产品名词，按照官方所定义的格式书写。 - -#### 中文与数字之间需要增加空格 - -正确： ->*今天出去买菜花了 5000 元。* - -错误： ->*今天出去买菜花了 5000元。* - ->*今天出去买菜花了5000元。* - -#### 数字与单位之间无需增加空格 -正确： ->*我家的光纤入户宽带有 10Gbps，SSD 一共有 10TB。* - -错误： ->*我家的光纤入户宽带有 10 Gbps，SSD 一共有 20 TB。* - -另外，度／百分比与数字之间不需要增加空格。 -正确： ->*今天是 233° 的高温。**新 MacBook Pro 有 15% 的 CPU 性能提升。* - -错误： ->*今天是 233 ° 的高温。**新 MacBook Pro 有 15 % 的 CPU 性能提升。* - -#### 全角标点与其他字符之间不加空格 -正确： ->*刚刚买了一部 iPhone，好开心！* - -错误： ->*刚刚买了一部 iPhone ，好开心！* - -#### 英文书写中标点符号后加空格 -正确： ->*Try Git commands right from your web browser. Featuring some of your soon-to-be favorites: branch, add, commit, merge, revert, cherry-pick, rebase!* - -错误： ->*Try Git commands right from your web browser.Featuring some of your soon-to-be favorites:branch,add,commit,merge,revert,cherry-pick,rebase!* - -#### 链接前后需增加空格 - -正确： - -> 此文档遵循 [开源指北编写规范](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%BC%96%E5%86%99%E8%A7%84%E8%8C%83.md) 要求。 - -错误： - -> 此文档遵循[开源指北编写规范](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%BC%96%E5%86%99%E8%A7%84%E8%8C%83.md) 要求。 - -> 此文档遵循 [开源指北编写规范](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%BC%96%E5%86%99%E8%A7%84%E8%8C%83.md)要求。 - -> 此文档遵循[开源指北编写规范](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%BC%96%E5%86%99%E8%A7%84%E8%8C%83.md)要求。 - -### 标点符号 - -#### 不重复使用标点符号 -正确： ->*德国队竟然战胜了巴西队！** - ->她竟然对你说「喵」？！* - -错误： ->*德国队竟然战胜了巴西队！！* - ->*德国队竟然战胜了巴西队！！！！！！！！* - ->*她竟然对你说「喵」？？！！* - ->*她竟然对你说「喵」？！？！？？！！* - -### 全角和半角 - -#### 在中文中使用全角标点 - -正确： ->*嗨！你知道嘛？今天前台的小妹跟我说「喵」了哎！* - ->*核磁共振成像（NMRI）是什么原理都不知道？JFGI！* - -错误： ->*嗨! 你知道嘛? 今天前台的小妹跟我说 "喵" 了哎!* - ->*嗨!你知道嘛?今天前台的小妹跟我说"喵"了哎!* - ->*核磁共振成像 (NMRI) 是什么原理都不知道? JFGI!* - ->*核磁共振成像(NMRI)是什么原理都不知道?JFGI!* - -#### 数字使用半角字符 - -正确： ->*这件蛋糕只卖 1000 元。* - -错误： ->*这件蛋糕只卖 １０００ 元。* - -#### 在英文中，或中文中遇到完整的英文整句、特殊名词，其內容使用半角标点 - -正确： - ->*乔布斯那句话是怎么说的？「Stay hungry, stay foolish.」* - ->*推荐你阅读《Hackers & Painters: Big Ideas from the Computer Age》，非常的有趣。* - -错误： ->*乔布斯那句话是怎么说的？「Stay hungry，stay foolish。」* - ->*推荐你阅读《Hackers＆Painters：Big Ideas from the Computer Age》，非常的有趣。* - -#### 全英文编辑环境中没有顿号（、），使用半角逗号代替 - -正确： ->*branch, add, commit, merge, revert, cherry-pick, rebase!* - -错误： ->*branch、add、commit、merge、revert、cherry-pick、rebase!* - -### 名词 -#### 专有名词使用正确的大小写 -正确： ->*使用 Gitee 登录* - ->*我们的客户有 GitHub、Foursquare、Microsoft Corporation、Google、Facebook, Inc.。* - -错误： ->*使用 gitee 登录* - ->*使用 GITEE 登录* - ->*我们的客户有 github、foursquare、microsoft corporation、google、facebook, inc.。* - ->*我们的客户有 GITHUB、FOURSQUARE、MICROSOFT CORPORATION、GOOGLE、FACEBOOK, INC.。* - ->*我们的客户有 Github、FourSquare、MicroSoft Corporation、Google、FaceBook, Inc.。* - ->*我们的客户有 gitHub、fourSquare、microSoft Corporation、google、faceBook, Inc.。* - -#### 不要使用不地道的缩写 - -正确： ->*我们需要一位熟悉 JavaScript、HTML5，至少理解一种框架（如 Backbone.js、AngularJS、React 等）的前端开发者。* - -错误： ->*我们需要一位熟悉 Js、h5，至少理解一种框架（如 backbone、angular、RJS 等）的 FED。* - -### 有序列表 - -#### 在有序列表中， 汉语数字后使用顿号，阿拉伯数字后使用半角句号。 - -正确： ->*一、xxxxxx* - ->*二、xxxxx* - ->*或* - ->*1.xxxxxx* - ->*2.xxxxxx* - -错误： ->*1、xxxxxxx* - ->*2、xxxxxx* - ->*或* - ->*一。xxxxxx* - ->*二。xxxxxx* - ->*或* - ->*一.xxxxxx* - ->*二.xxxxxxx* - - -### 参考资料 -中文文案排版指北：https://mazhuang.org/wiki/chinese-copywriting-guidelines/ - -中文技术文档的写作规范：https://github.com/ruanyf/document-style-guide - +标准的格式是优质内容的基础，制定本规范的目的是统一文档内容中的中英文文字规范，提升内容的严谨度和美观度。 + +### 空格 + +#### 中英文之间需要增加空格 + +正确： +>*在 LeanCloud 上，数据存储是围绕* `AVObject` 进行的。 + +错误： +> *在LeanCloud上，数据存储是围绕*`AVObject`进行的。 + +> *在 LeanCloud上，数据存储是围绕*`AVObject` 进行的。 + +完整的正确用法： + +>*在 LeanCloud 上，数据存储是围绕* `AVObject` 进行的。每个 `AVObject` 都包含了与 JSON 兼容的 key-value 对应的数据。数据是 schema-free 的，你不需要在每个 `AVObject` 上提前指定存在哪些键，只要直接设定对应的 key-value 即可。 + +例外：「豆瓣FM」等产品名词，按照官方所定义的格式书写。 + +#### 中文与数字之间需要增加空格 + +正确： +>*今天出去买菜花了 5000 元。* + +错误： +>*今天出去买菜花了 5000元。* + +>*今天出去买菜花了5000元。* + +#### 数字与单位之间无需增加空格 +正确： +>*我家的光纤入户宽带有 10Gbps，SSD 一共有 10TB。* + +错误： +>*我家的光纤入户宽带有 10 Gbps，SSD 一共有 20 TB。* + +另外，度／百分比与数字之间不需要增加空格。 +正确： +>*今天是 233° 的高温。**新 MacBook Pro 有 15% 的 CPU 性能提升。* + +错误： +>*今天是 233 ° 的高温。**新 MacBook Pro 有 15 % 的 CPU 性能提升。* + +#### 全角标点与其他字符之间不加空格 +正确： +>*刚刚买了一部 iPhone，好开心！* + +错误： +>*刚刚买了一部 iPhone ，好开心！* + +#### 英文书写中标点符号后加空格 +正确： +>*Try Git commands right from your web browser. Featuring some of your soon-to-be favorites: branch, add, commit, merge, revert, cherry-pick, rebase!* + +错误： +>*Try Git commands right from your web browser.Featuring some of your soon-to-be favorites:branch,add,commit,merge,revert,cherry-pick,rebase!* + +#### 链接前后需增加空格 + +正确： + +> 此文档遵循 [开源指北编写规范](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%BC%96%E5%86%99%E8%A7%84%E8%8C%83.md) 要求。 + +错误： + +> 此文档遵循[开源指北编写规范](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%BC%96%E5%86%99%E8%A7%84%E8%8C%83.md) 要求。 + +> 此文档遵循 [开源指北编写规范](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%BC%96%E5%86%99%E8%A7%84%E8%8C%83.md)要求。 + +> 此文档遵循[开源指北编写规范](https://gitee.com/gitee-community/opensource-guide/blob/master/%E7%BC%96%E5%86%99%E8%A7%84%E8%8C%83.md)要求。 + +### 标点符号 + +#### 不重复使用标点符号 +正确： +>*德国队竟然战胜了巴西队！** + +>她竟然对你说「喵」？！* + +错误： +>*德国队竟然战胜了巴西队！！* + +>*德国队竟然战胜了巴西队！！！！！！！！* + +>*她竟然对你说「喵」？？！！* + +>*她竟然对你说「喵」？！？！？？！！* + +### 全角和半角 + +#### 在中文中使用全角标点 + +正确： +>*嗨！你知道嘛？今天前台的小妹跟我说「喵」了哎！* + +>*核磁共振成像（NMRI）是什么原理都不知道？JFGI！* + +错误： +>*嗨! 你知道嘛? 今天前台的小妹跟我说 "喵" 了哎!* + +>*嗨!你知道嘛?今天前台的小妹跟我说"喵"了哎!* + +>*核磁共振成像 (NMRI) 是什么原理都不知道? JFGI!* + +>*核磁共振成像(NMRI)是什么原理都不知道?JFGI!* + +#### 数字使用半角字符 + +正确： +>*这件蛋糕只卖 1000 元。* + +错误： +>*这件蛋糕只卖 １０００ 元。* + +#### 在英文中，或中文中遇到完整的英文整句、特殊名词，其內容使用半角标点 + +正确： + +>*乔布斯那句话是怎么说的？「Stay hungry, stay foolish.」* + +>*推荐你阅读《Hackers & Painters: Big Ideas from the Computer Age》，非常的有趣。* + +错误： +>*乔布斯那句话是怎么说的？「Stay hungry，stay foolish。」* + +>*推荐你阅读《Hackers＆Painters：Big Ideas from the Computer Age》，非常的有趣。* + +#### 全英文编辑环境中没有顿号（、），使用半角逗号代替 + +正确： +>*branch, add, commit, merge, revert, cherry-pick, rebase!* + +错误： +>*branch、add、commit、merge、revert、cherry-pick、rebase!* + +### 名词 +#### 专有名词使用正确的大小写 +正确： +>*使用 Gitee 登录* + +>*我们的客户有 GitHub、Foursquare、Microsoft Corporation、Google、Facebook, Inc.。* + +错误： +>*使用 gitee 登录* + +>*使用 GITEE 登录* + +>*我们的客户有 github、foursquare、microsoft corporation、google、facebook, inc.。* + +>*我们的客户有 GITHUB、FOURSQUARE、MICROSOFT CORPORATION、GOOGLE、FACEBOOK, INC.。* + +>*我们的客户有 Github、FourSquare、MicroSoft Corporation、Google、FaceBook, Inc.。* + +>*我们的客户有 gitHub、fourSquare、microSoft Corporation、google、faceBook, Inc.。* + +#### 不要使用不地道的缩写 + +正确： +>*我们需要一位熟悉 JavaScript、HTML5，至少理解一种框架（如 Backbone.js、AngularJS、React 等）的前端开发者。* + +错误： +>*我们需要一位熟悉 Js、h5，至少理解一种框架（如 backbone、angular、RJS 等）的 FED。* + +### 有序列表 + +#### 在有序列表中， 汉语数字后使用顿号，阿拉伯数字后使用半角句号。 + +正确： +>*一、xxxxxx* + +>*二、xxxxx* + +>*或* + +>*1.xxxxxx* + +>*2.xxxxxx* + +错误： +>*1、xxxxxxx* + +>*2、xxxxxx* + +>*或* + +>*一。xxxxxx* + +>*二。xxxxxx* + +>*或* + +>*一.xxxxxx* + +>*二.xxxxxxx* + +### 参考资料 +中文文案排版指北：https://mazhuang.org/wiki/chinese-copywriting-guidelines/ + +中文技术文档的写作规范：https://github.com/ruanyf/document-style-guide + 中华人民共和国国家标准《党政机关公文格式》（GB/T 9704-2012）[7.3.3] \ No newline at end of file -- Gitee