本仓库已迁移至 tanjunchen/cloud-native-travel，欢迎大家关注新仓库，与大家一起分享探索云原生趣事。
开源社区又称开放源代码社区，一般由拥有共同兴趣爱好的人所组成，根据相应的开源软件许可证协议公布软件源代码的网络平台，同时也为网络成员提供一个自由学习交流的空间。由于开放源码软件主要被散布在全世界的编程者所开发，开源社区就成了他们沟通交流的必要途径，因此开源社区在推动开源软件发展的过程中起着巨大的作用。【百度百科】
在如今的软件设计，架构及开发中，开源扮演着越来越重要的角色。作为开发工程师，服务器、数据库、各种编程语言和框架的源代码，我们可以随时利用这些开源技术实现自己的业务要求。方便且免费地使用这些技术，当然离不开上述各种技术的开源，当今世界，这是一个开源的时代，所以，我们应该主动拥抱开源，工作之余了解与学习开源社区那些事。
其实，开源社区已经存在许久啦，但是对于我和一些人来说，可能比较新奇，所以本文介绍了一些开源社区的概念、如何参与社区、为什么要参与社区？开源社区很多，找到适合自己的才是最好的。
CNCF 基金会、kubernetes、Istio、Apache 软件基金会、Apache 项目列表
这里简单地列出了几个条件：
- 社区/项目方向是否符合你的期望/兴趣。比如希望更多关注在后端领域，那很多前端方向的开源项目就可以放弃。
- 社区/项目的技术栈是否与你匹配，匹配的技术栈可以使你以更快的速度熟悉代码。技术栈包括编程语言、采用的框架或者库等。
- 社区接纳新人的友好程度。这对于初入开源，而且并不以开源为生的新人来说，是非常重要的。对于新人来说，开源的贡献活动并不能带给他们任何短期可见的回报，因此需要友好的社区来给予他们正面的反馈，使得贡献活动进入一个良性循环。友好程度，有很多地方可以反映，比如项目是否有清晰易懂的贡献指南，是否具有完善的 CI/CD 支持，是否有完善的晋升路线（新贡献者 -> Reviewer -> Commiter -> Maintainer），是否可以简单直接地直接接触到项目的维护人员，有完善的答疑渠道等方面。不过要注意，友好程度跟项目的受欢迎程度是两回事，受欢迎（Star 多）的项目未必有一个友好的社区。一个额外的小建议，刚开始参与开源时，不要选择公司开源的开源项目进行贡献。公司开源的项目通常会不如社区驱动的开源项目友好。
- 是否是使用过或者熟悉的开源项目。一个好的贡献者也是一个好的用户。如果之前就有使用过的开源项目，会免去熟悉的过程。
最后，在我看来，选择的优先级是：[1] > [3] > [4] > [2]。因为方向无论如何是最重要的，在确定方向后，社区的友好程度应该是更加值得考虑的，这也是我在接触开源以后才发现的。最后，是技术栈的熟悉程度。个人认为，编程语言等等的选择，相对不是那么重要的。如果是 Java 后端的话，可能 Apache or Eclipse 基金会下那一堆开源项目或者 Spring 等等会比较合适。
下面是一些参与开源社区的方法：
-
找到一个感兴趣的项目：找到一个你感兴趣的开源项目，了解它的目标、代码库、社区文化和贡献方式。可以通过 Github、Gitlab 或 Bitbucket 等平台找到开源项目。
-
加入社区：参与开源社区最重要的是加入社区，这意味着你需要加入邮件列表、聊天室或论坛。加入社区可以让你了解最新的开发动态，同时也能结交其他志同道合的人。
-
阅读文档：了解项目的文档是非常重要的，可以帮助你了解项目的架构、代码规范和开发流程等信息。
-
发现问题：在项目的 issue 列表中寻找可以解决的问题。一些问题可能很简单，例如修复拼写错误或格式问题，而其他问题则需要更深入的技术知识。
-
提交代码：提交代码是最重要的贡献方式之一，你需要了解项目的代码库和开发流程，以便你的代码可以被审核和合并到主分支中。
-
参加社区活动：参加社区活动是了解其他开发者和项目的好方法，例如 hackathon、meetup 和代码贡献日等。
-
尊重他人：参与开源社区需要尊重他人的意见和工作。要时刻保持礼貌和耐心，积极参与社区的讨论和决策。
参与开源社区需要花费一些时间和精力，但它是一个非常有益的经历，可以让你成为一个更好的开发者，并为开源项目做出贡献。
这里以 CNCF 开源社区为例，举例说明如何参与 CNCF Kubernetes 开源社区。
如何向 Kubernetes、Istio 等开源仓库贡献呢？这里提供一点参考。
CNCF 是一个开源软件基金会，致力于使云原生计算具有普遍性和可持续性。云原生计算使用开源软件技术栈将应用程序部署为微服务，将每个部分打包到自己的容器中，并动态编排这些容器以优化资源利用率。云原生技术使软件开发人员能够更快地构建出色的产品。具体详情可以参考以下网址：
其中 cncf/devstats 罗列世界上活跃于 CNCF 组织的各个公司以及非营利组织与个人。Grafana 展示效果：
-
注册 Github 账户，提倡 @gmail.com 邮箱注册(尽量避免 QQ 邮箱)。避免以后关联 slack 出现问题
-
签署 CNCF-CLA 协议，登录 linuxfoundation 进行注册以及签署协议。
注意事项：签署 CLA 协议的邮箱应该与 Git 客户端本地配置邮箱保持一致，否则验证不过。访问 CLA 签署网站需要科学上网。所以注册邮箱不推荐使用 QQ 邮箱。具体流程可以参考：官方指导
SIGs and Working Groups，它们是 Kubernetes 社区中关注特定模块的组织，Kubernetes 作为一个拥有几十万行源代码的项目，某些小组专门负责不同的某块，如网络、调度、安全等。 目前主要有 API Machinery、Apps、Architecture、Auth、Autoscaling、CLI、Cloud Provider、Cluster Lifecycle、Contributor Experience、Docs、Instrumentation、Multicluster、Network、Node、Release、Scalability、Scheduling、Service Catalog、Storage、Storage、Testing、UI、Usability、Windows。
详情参考官网 website
向 Kubernetes 提交 issue/pr，详见 新手参与 Kubernetes 贡献
熟悉基本 Linux 操作、Git 操作，推荐 Git 操作教程。
如何向 Kubernetes 贡献你的第一个贡献呢？
如上图所示，在 Issues 中输入 help 或者 good first issue 进行过滤，新手一般都是从这里开始参与社区贡献之门。
-
参见 贡献指南，关注 kubernetes 其他仓库，如 enhancements、community、website，enhancements 有关最近 kk 以及未来的发展方向、community 有关 kk 的各种规章制度、website 表示 kk 官网。
-
加入 kk 社区的 Slack 频道，熟悉 KEP， KEP 的全称是 Kubernetes Enhancement Proposal，因为 Kubernetes 目前已经是比较成熟的项目了，所有的变更都会影响下游的使用者，对于功能和 API 的修改都需要先在 kubernetes/enhancements 仓库对应 SIG 的目录下提交提案才能实施，所有的提案都必须经过讨论、通过社区 SIG Leader 的批准。
参与 kubernetes 本地化工作，具体可以参考 K8SMeetup 翻译流程与翻译校稿规范。
Kubernetes 目前已经是云时代的操作系统，作为容器编排领域和云原生领域的事实标准，了解与学习 Kubernetes 的使用和原理成为云原生时代开发工程师的必备技能。
开源社区如此之多，选择自己感兴趣的或者对自己从事的工作有帮助的是最好不过的啦，开源与工作相结合是比较推崇的，既可以提升平时工作的效率(社区中比较好用的工具应用到工作中)，也可以提升对开源社区的兴趣(比如你对某项开源项目中的某个 topic 或 issue 感兴趣，则可以尝试用自己所掌握的知识去实现它)。从不同的社区中我们能够学习到不同的东西，比如：社区的管理与运作方式、提升某项技能、增强编码能力与编码规范。在开源社区能够收获什么呢？
- 提升编码水平与规范。
- 与世界上最优秀的工程师们交流，能够开拓视野，如 k8s 新增一项功能，必须严格遵循 alpha -> beta -> release -> GA 等阶段、e2e 测试、编写完整的文档、代码注释等。
- 可以快速理解项目的实现原理以及工作流程，提升工作效率，提升个人水平。
- 大厂加分项等等
- ......
- PR: Pull Request。拉取请求。
- LGTM: Looks Good To Me。看起来不错，代码已 review，可以合并。
- SGTM: Sounds Good To Me。和上面那句意思差不多。
- WIP: Work In Progress。若你有个改动很大的 PR，可在写了部分的情况下先提交，在标题里写上 WIP，以告诉项目维护者这个功能还未完成，方便维护者提前 review 部分提交的代码。
- PTAL: Please Take A Look。你来瞅瞅？用来提示别人来看一下。
- TBR: To Be Reviewed。提示维护者进行 review。
- TL;DR: Too Long; Didn't Read。太长，未看。
- TBD: To Be Done(or Defined/Discussed/Decided/Determined)。根据语境不同意义有所区别，但一般都是还没 xx。
- SPOF: Single point of failure。单节点崩溃。
- ASAP: As soon as possible。马上，尽快。
- BTW: By the way。顺便说一下。
- FYI : For your information。供你参考。
- TTYL: Talk to you later。待会回复你。
- Plz: Please 的谐音。
- Thx: Thanks。谢谢。
- AFAIK: As far as I know。据我所知。
- U: you。
- R: are。经常用于 where R U？ 邮件里面用的不太多，大多数用在非正式场合之中。
- Wanna: want to。这个属于约定俗成，表示想做什么。
- Pvt: private。经常用在表示所有权上面，比如说私有库，或者私有代码。
- Doc: Document。如果用在其它场合，也可能表示医生。所以需要结合上下文来判断。
- i.e。也就是。。。(id est)。
- e.g。例如 for example。
- etc。 et cetera等等。
- Repository：简称 Repo，可以理解为"仓库"。
- Issues：可以理解为"问题"，举一个简单的例子，如果我们开源一个项目，如果别人看了我们的项目，并且发现了 bug，或者感觉那个地方有待改进，他就可以给我们提出 Issue，等我们把 Issue 解决之后，就可以把这些 Issue 关闭；反之，我们也可以给他人提出 Issue。
- Star：可以理解为"点赞"，当我们感觉某一个项目做的比较好之后，就可以为这个项目点赞，而且我们点赞过的项目，都会保存到我们的 Star 之中，方便我们随时查看。在 GitHub 之中，如果一个项目的点星数能够超百，那么说明这个项目已经很不错了。
- Fork：可以理解为"拉分支"，如果我们对某一个项目比较感兴趣，并且想在此基础之上开发新的功能，这时我们就可以 Fork 这个项目，这表示复制一个完成相同的项目到我们的 GitHub 账号之中，而且独立于原项目。之后，我们就可以在自己复制的项目中进行开发了。
- Merge：可以理解为"合并"，如果别人 Fork 了我们的项目，对其进行了修改，并且提出了 Pull 请求，这时我们就可以对这个 Pull 请求进行审核。如果这个 Pull 请求的内容满足我们的要求，并且跟我们原有的项目没有冲突的话，就可以将其合并到我们的项目之中。当然，是否进行合并，由我们决定。
- Watch：可以理解为"观察"，如果我们 Watch 了一个项目之后，如果这个项目有了任何更新，我们都会在第一时候收到该项目的更新通知。
- Gist：如果我们没有项目可以开源或者只是单纯的想分享一些代码片段的话，我们就可以选择 Gist。
- 等等......
GitHub Trend 页面总结了每天/每周/每月周期的热门 Repositories 和 Developers，你可以看到在某个周期处于热门状态的开发项目和开发者。而 GitHub Topic 展示了最新和最流行的讨论主题，在这里你不仅能够看到开发项目，还能看到更多非开发技术的讨论主题，比如 Job、Chrome 浏览器等。
在 Github 上有很多的项目，我们应该如何去抉择呢？有很多种方式提高我们的搜索效率。如搜索某个用户：
location:china language:java followers:>=1000
搜索某个项目，awesome:高并发 language:java starts:>=500 forks:200
学习与阅读源码是一门苦差事，参与开源社区也需要耐心与持之以恒的决心。参与开源社区是一个非常有益的经历，可以让你学习新技能、结交志同道合的人、增加你的开发经验和在开源项目上做出贡献。
参与 Kubernetes 社区，从中学习到了很多，比如不仅学习到了 Go 语言的开发规范、庞大的开源社区的治理方式，还从社区中的很多优秀工程师身上学到了软件设计的一些技巧，与优秀的开发者交流提高了我的见解，这些都是在日常工作中很难得到的。可能与我们平时的工作内容相关，毕竟大部分集中于业务开发，框架的使用。优秀的开源社区真的是值得我们去学习与借鉴，等着我们去挖掘和学习。加入开源社区吧、后浪们 ！！！