开源 (Open Source)

开源为我带来了很多的成长，很多的成长经验和学习途径都是通过开源获取到并且学习到的。 这里有一篇我的第一次开源的成长指南：https://nsddd.top/zh/posts/open-source-contribution-guidelines/ 第一次参与开源还是一个刚刚接触大学没多久 ~ ，调研了解到很多优秀的开源项目都会有很多业界大佬坐镇，因此会让大家以为只有“大牛”才能参与开源。实际上，开源社区经常会听到 “我是小白，我可以参与开源吗？” 这种声音，发出这种声音的同学往往是对开源感兴趣，但并不知道如何入手的小伙伴。 从开源定义来看，我们不需要成为“大牛”才能够参与开源。所谓开源，其实是一种促进个人成长和开源领域发展的行为，通过分享自身技术和经验来促进大家的技术交流，从这方面讲，开源是没有门槛的，只要有想要分享的东西，所有人都可以参与开源。 从参与要求来看，我们需要具备一定的知识积累才能参与开源。开源社区不是学校，社区会解答你的疑问，但首先你要有一定了解，才能准确提出你的疑问。对开源项目一无所知是无法参与开源的。当然，这与你是否成为“大牛”也并没有什么关系。因此，只要具备一定的技术积累，就可以参与相应的开源项目。 “罗马不是一天建成的”。没有人天生就是“大牛”，“大牛”们也是在参与中不断成长的，不要被虚无的 title 所困扰，只有不断的坚持和探索才能让自己不断成长！ 在开源社区中，我慢慢学习到了非常多的技巧，比如这里我总结出一篇开源社区的提问技巧：https://nsddd.top/zh/posts/the-art-of-asking-questions-in-open-source-communities/ 我对整个的开源成长也有自己的思考总结，写了这篇关于开源的成长性指南阶段，从我们第一次加入开源项目开始，到最后开源和维护自己的项目，以及商业化成长，可以参考： https://nsddd.top/zh/posts/stage-growth-of-open-source/https://nsddd.top/zh/posts/stage-growth-of-open-source/ 非常推荐阅读 ~ 在加入 OpenIM 的社区一年中，我将自己的开源理解和运营技巧都集成在了 OpenIM 的开源布道上，将 OpenIM 社区带入到了一个顶级的开源社区中来。除此之外，我参与过其他的优秀开源项目的贡献和维护，我会从自己的角度上来介绍如何运营一个优秀顶级的开源社区。 开源不仅是我的热爱，也逐渐成为我的一大优势。在我与开源的互动中，我们相得益彰。 开源除了给个人以及公司带来技术影响力之外，更为重要的是通过开源实现商业化价值，而这部分才是很多开源项目成功的实际驱动力。本文会介绍我对开源的理解，以及着重介绍自己对开源以及开源商业模式做了一个系统的研究，为决策项目是否应该开源、采用何种开源策略以及开源商业化路径提供参考意见。 如果你对我有兴趣，可以关注我的开源的 github 账户： https://github.com/cubxxw 什么是开源 「开源」一词对应英文 Open Source，最初起源于软件开发领域，因此也称为「开放源代码」，对应的软件则称为开源软件（Open Source Software）。除了我们熟知的开源软件以外，开源的表现形式还有开源硬件（Open Source Hardware）、开放设计（Open Design）、开放文档（Open Document）。 我们最常见的是开源软件和开放文档 ~ 先来谈论一下 开源软件 一般很容易理解就是 是不是公开源代码的软件就是开源软件呢？ 实际上并不是。按照 OSI 组织 (opens new window)（Open Source Initiative Association）的 OSD 定义 (opens new window)，除了公开源代码，开源软件的发行条款还必须符合以下十个条件： 序号 条款 简单说明 1 Free Redistribution 允许自由地再发布软件 2 Source Code 程序必须包含所有源代码 3 Derived Works 可以修改和派生新的软件 4 Integrity of The Author’s Source Code 发布时保持软件源代码的完整性 5 No Discrimination Against Persons or Groups 不得歧视任何个人或团体 6 No Discrimination Against Fields of Endeavor 不得歧视任何应用领域（例如商业） 7 Distribution of License 许可证的发布具有延续性 8 License Must Not Be Specific to a Product 许可证不能针对于某一个产品 9 License Must Not Restrict Other Software 许可证不能限制其他软件 10 License Must Be Technology-Neutral 许可证必须是技术中立的 你可以通过查阅OSI官方许可证的目录 Open Source Initiative 认可的开源许可证...

author(Github) 在提问之前 在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情： 尝试在你准备提问的论坛的旧文章中搜索答案。 尝试上网搜索以找到答案。 尝试阅读手册以找到答案。 尝试阅读常见问题文件（FAQ）以找到答案。 尝试自己检查或试验以找到答案。 向你身边的强者朋友打听以找到答案。 如果你是程序开发者，请尝试阅读源代码以找到答案。 当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。 运用某些策略，比如先用 Google 搜索你所遇到的各种错误信息（搜索 Google 论坛和网页），这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果，在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助。这么做（加上搜索过的字串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。 别着急，不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前，再阅读一下常见问题文件（FAQ）、放轻松、坐得舒服一些，再花点时间思考一下这个问题。相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑拋出，只因你的第一次搜索没有找到答案（或者找到太多答案）。 准备好你的问题，再将问题仔细的思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。 小心别问错了问题。如果你的问题基于错误的假设，某个普通黑客（J. Random Hacker）多半会一边在心里想着蠢问题…，一边用无意义的字面解释来答复你，希望着你会从问题的回答（而非你想得到的答案）中汲取教训。 绝不要自以为够格得到答案，你没有；你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案，靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题，而不仅仅是被动的从他人处索取知识。 另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示？、我的这个例子里缺了什么？以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心。 当你提问时 慎选提问的论坛 小心选择你要提问的场合。如果你做了下述的事情，你很可能被忽略掉或者被看作失败者： 在与主题不合的论坛上贴出你的问题。 在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然。 在太多的不同新闻群组上重复转贴同样的问题（cross-post）。 向既非熟人也没有义务解决你问题的人发送私人电邮。 黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。 因此，第一步是找到对的论坛。再说一次，Google 和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括阅读 FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接，如果是这样，链过去看看。 向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说，别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定，那就向别处发送，或者压根别发。 在选择论坛、新闻群组或邮件列表时，别太相信它的名字，先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题，这样可以让你感受一下那里的文化。事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意，也许这样就找到答案了。即使没有，也能帮助你归纳出更好的问题。 别像机关枪似的一次“扫射”所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。 搞清楚你的主题！最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错，最好在搞清楚这之间差异之前什么也别问。 一般来说，在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点，一是看潜在的回复者有多少，二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。 可以理解的是，老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 —— 已经好几次了，一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。 Stack Overflow 搜索，然后在 Stack Exchange 问。...

社区不规范怎么办 作为 OpenIM 社区首席运营官，对整个社区的 communtiy 以及 GitHub 配置仓库 进行了全面的配置。并且对整个 OpenIM 的 Makefile 和 CICD 流，以及整个 OpenIM 使用的日志包 、错误码、协同流、贡献者文档以及 社区文档 进行架构和设计。 在这个时候总会有一些问题，即使你觉得自己的 贡献者文档 写的很牛逼了，很全面了，但是依旧很少有人愿意花心思去按照你写的规范去学习。这对我打造顶级的开源社区是一个非常大的阻碍，于是就有了今天的这个文档，我会将它记录在 GitHub Gists 上，提供拉取和使用的说明、链接，并且定期的维护它。 首先，我提供克隆的链接： git clone https://gist.github.com/cubxxw/126b72104ac0b0ca484c9db09c3e5694 如何设计 首先是针对基础的功能，那就是我们熟知的 commit 信息和 push 信息。 我们可以对 commit 信息的格式进行设置 我们可以对 push 的大小进行设置 我们提供了 actions 的功能 我们提供了 Makefile 标记和清除 Hook 的能力 我之前在学习 git 的时候写了一篇很全的笔记，并且分享在 GitHub 上面，在这个 🤖 链接 上可以学习到 git 很多高级用法。 这篇文章讲解了 git 有哪些规范，寻找合适的 CICD 流： 统一格式： 统一格式：git commit -m 'type(scope): 描述(#issue)' 我们在提交的时候带上邮箱信息 -s 来签证，这是一个很好的习惯。...

✨ 熟悉我的人都知道，我是一名不折不扣的开源爱好者，从大一开始接触到 GitHub 后，逐渐的沉迷于 开源世界 ~ 今天这篇文章很特别，算是自己参考并且总结出来的开源阶段，以及学习开源项目的步骤和心得。未来自己也是按照自己的规划来进行成长。 同学习 Kubernetes 的成长轨迹一样，这篇文章将会长期更新，也可以参与贡献 ~ 目前我是处于第一阶段，处于一种对开源世界和对知识的沉淀与积累的过程中，这个阶段的主要表现是我们开始学一些基础。但是我喜欢做笔记将它们记录下来，供自己日后翻阅和复习，当然也是制作自己的内容价值。 GitHub - cubxxw/awesome-cs-cloudnative-blockchain: 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 这一阶段，并不是意味着我开始迈入第二阶段，第一阶段就 come to an end. 我认为以下所讲的所有阶段就像是人生轨迹，并不是意味着你当爸爸了就不是父母的孩子，你依旧可以扮演着多种角色，并且不断完善和改进自己的角色。开源项目也是如此，类比我们的成长经历，在后一阶段我依旧会扮演好前一阶段的角色。所以我会坚持做自己的内容创作和知识共享 ~ ✨ 下面开始介绍适合大多数人的开源项目的不同阶段，为了方便定位，我将上面知识积累称呼为 0 阶段知识积累阶段。下面开始从第一阶段开始讲起~ 第一阶段：简单看源码阶段 方法： 简单看源码 说明： 简单看源码、文档、跑跑样例代码 学习效果： 1 ~ 2 有产出： 没有产出 是否达成学习闭环： 尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环 Get 到的技能点： 阅读源码的技能 案例： 阅读 sealer、sealos、Kubernetes、k3s、horizoncd 的源码，并且测试 阶段 第一阶段：简单看源码阶段 方法 简单看源码 说明 简单看源码、文档、跑跑样例代码 学习效果 1 ~ 2 有产出 没有产出 是否达成学习闭环 尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环 技能点 阅读源码的技能 案例 阅读 sealer、sealos、Kubernetes、k3s、horizoncd 的源码，并且测试 第一阶段的建议是简单地看源码、文档、跑跑样例代码来学习。这个阶段的主要目的是积累基础知识，建议尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环。阅读源码的技能是这个阶段最重要的技能点。建议阅读一些开源项目，例如 sealer、sealos、Kubernetes、k3s、horizoncd 等，并进行测试。...

参与本项目 ⚡ 前言 欢迎来到我们的项目！本项目旨在建立一个基于区块链的全民学习平台，通过集体的智慧和努力，推动技术和知识的普及。无论你是初学者还是经验丰富的开发者，你的贡献都将对项目产生积极影响。 💡 关于本项目（先看❗） 本项目由一个热衷于区块链和软件开发的团队发起。我们致力于创建一个开源、去中心化的学习环境，让每个人都能够访问和分享知识。 🌐 联系方式 Facebook Website Blog Telegram Twitter Linkedin Donate 🔍 项目背景 我们相信，通过集体智慧和技术的力量，可以打造一个更加开放和包容的学习环境。这个项目不仅是一个技术挑战，也是社区合作的成果。 🌟 如何参与 不论你的技能水平如何，都有多种方式可以参与本项目： 提交问题和功能建议。 参与代码编写和文档撰写。 在社区中提供帮助和支持。 我们都是这个仓库未来很有潜力的客户，或者是贡献者，谢谢你选择了加入C-UB社区，我们将会一起合作，未来我们将会考虑以区块链为底层搭建一个全民学习平台，我们每一个人都将会是这个社区的构建着，将会推动c-universal blockchain（链学） 社区的发展和进步~ 如果你对本项目有任何建议或发现文中内容有误的，欢迎提交 issues 进行指正。 对于文中我没有涉及到知识点，欢迎提交 PR。 或许我们会很疑惑？ 在我们参与贡献的时候，如果克隆了**🧷 cs-awesome-Block_Chain项目，但是每次获取上游代码很麻烦怎么办？如何提交有意思的代码？这篇文章将会解决这个问题~⬇️ ** ⚡提前需要你… 你需要学会使用markdown🖱️ 你需要学会使用git 你的代码符合Google代码规范 排版 笔记内容按照 中文文案排版指北 进行排版，以保证内容的可读性。 不使用 ![]() 这种方式来引用图片，而是用 <img> 标签。一方面是为了能够控制图片以合适的大小显示，另一方面是因为 GFM 不支持 <center> ![]() </center> 这种方法让图片居中显示，只能使用 <div align="center"> <img src=""/> </div> 达到居中的效果。...