一、起点
我所在的工业物联团队在23年末开始投入工业新架构研发，基于使用场景、读写性能与可维护性等多方面考虑，我们计划在新架构全面使用openGemini替换掉InfluxDB，而在当时openGemini官方客户端SDK设计开发还未启动。在老架构场景下都是我们使用InfluxDB的客户端连接openGemini服务端，工业新架构下我们希望使用openGemini官方的SDK并参与维护。
基于上述情况，我们技术专家贺张俭提议大家可以一起做一下openGemini客户端SDK开发的开源工作，有了这个想法他就开始在部门内召集感兴趣的人一起投入开发。大家的积极性都非常高，于是我们很快组织起来一个openGemini SDK小团队。
二、SDK小团队内部运作
SDK的设计主要基于openGemini的官方文档与openGemini主仓的部分代码，同时也调研了InfluxDB客户端SDK的实现。
我们的小团队提供多语言SDK，多语言开发要求风格上尽量统一，避免因语言不同导致SDK开发走向截然不同的方向，即要求多语言SDK的实现是一样的，区别仅是语言本身的区别，使用者不需要在理解不同语言SDK的逻辑上投入额外精力。这样可以极大优化使用体验，但是对SDK的设计就有了更高的要求，更加考验设计者的知识储备与设计能力：设计者需要熟悉多种开发语言的特点，且能灵活根据各语言特点设计通用的方法。我们的开源专家贺张俭有丰富的多语言开发经验，并写过一些相关文章，由他掌舵openGemini SDK的设计，其他人则投入自己熟悉的语言部分开发，由此我们这艘小船开始缓缓前行。
我们团队主要使用Go和Java，所以在一开始时我们计划以Go先行，其他语言紧随其后。截至撰写这篇文章时，openGemini Client Go SDK已发布v0.2.0版本，链接如下：https://github.com/openGemini/openGemini-client-go/releases/tag/v0.2.0
欢迎大家使用并提出优化建议。同时我们的Java版本、C++版本与Python版本SDK也已初具雏形，会在后续发布正式版本，也欢迎大家届时使用并给出优化建议。
开源意味着所有人都可以看到我们贡献的代码，同时我们维护的项目可能会在很多未曾设想到的场景下被使用，从而会发现许多一开始未曾识别的问题。因此我们的代码需要有合理且易于维护的设计，设计上应该易于理解，实现上应该望文知意，使用上应该符合开发者的使用习惯，有问题时修改起来不会伤筋动骨。由此，SDK的设计在我们内部经过了充分讨论，同时我们也积极与社区交流；大到一开始的框架设计、接口设计，小到一个简单的变量命名，我们都有进行充分讨论。
在代码开发上，我们走的是小步快跑路线，即每实现一个小的功能或是做一些小的修改，都会让大家充分检视并且在相关的群组内讨论以确保代码的正确性与可读性，同时我们配置的ci工具也在很大程度保证了代码的整洁与测试充分。同时我们的小团队也会经常开会议一起写代码，进行一对一或多对一的结对编程，这对我们代码风格上的统一与设计实现上的统一奠定了基础。
三、开源社区支持
参与openGemini的社区建设是我第一次与开源社区交流，开源社区的大家都非常友善，为我们提供了很多帮助。在规划投入openGemini社区开源贡献以前，社区曾给我所在的部门做过技术分享，所以有过一些沟通基础。决定投入SDK设计开发以后，我们组织了线上会议向社区介绍了我们的开发者，开源社区向我们介绍了openGemini一些基础知识与架构。之后我们便分下任务开始做每个部分的调研，并基于各部分的调研结果与社区的建议进行SDK设计，在设计阶段我们保持与社区一或两周一次的线上会议，待一切敲定后开启了开发工作。
openGemini社区的支持不限于SDK开发阶段的技术支持，在投入开源贡献的初期我们便收到了许多社区周边，很大程度调动了我们开发者的积极性。在第一版Go SDK验收完后我们与社区依然保持着紧密联系，社区还规划了2024年定期技术分享与答疑。社区的向宇、李仕林、范祥多次与我们的小团队进行交流，响应非常及时并毫不吝啬的提供支持与帮助，这对我们在SDK的设计开发与之后的openGemini数据库的使用与贡献非常重要。
四、开源新手建议
经过openGemini SDK的设计开发，我已经对开源贡献的流程相对熟悉了，作为一个开源新手，我有如下一些经验可以给同样作为小白想为开源做贡献但是比较迷茫的朋友们借鉴：
1、从熟悉的项目入手
选择项目时最好是选择自己曾经使用或之后会考虑要长期使用的项目，这样可以减少很多学习成本，也可以根据自己的使用体验发现产品可以改进的地方。
2、可以从很小的事情做起
万事开头难，可以尝试少量的提一些代码，以此熟悉流程包括但不限于修改一些拼写错误、升级一些依赖关系、修改一些文档等。想要一开始就做很多复杂功能是不现实的，需要有一个循序渐进的过程。
3、需要学习git相关的知识
需要熟悉一下代码合入的流程，尽量保持提交记录是线性的。每次提交记录最好可以清晰准确的描述代码的实现内容，这样可以清楚的看到项目的演进过程，也方便定位到代码的修改原因，很大程度提高代码的可读性与项目的可维护性。
4、学习开源提交的规范
贡献代码之前需要读一下贡献规范相关的文档，每个项目可能有一些不同的要求，代码的提交信息格式等信息最好与之前的提交者保持一致。
5、注重与社区和其他开发者的交流
积极与社区互动并了解项目的演进方向，指引贡献代码的方向，同时分析同类型的产品的演进方向也可以学习到很多。与其他开发者进行技术交流可以很快提升编码水平，也有机会拓宽认知边界。
6、实际使用体验更能发现问题
通常比较知名的开源项目的开发贡献主力都是该项目的重度用户，只有用户能够深度使用并发现存在的可优化问题。项目的演进方向通常也由用户的使用方向，可以说把了解用户的诉求就可以判断项目的发展方向。
五、个人感悟
作为一名开发者，工作中使用到开源产品的机会非常多，但是之前并未向开源社区贡献过代码，想为开源代码贡献力量也一直都没有什么头绪。借由本次参与openGemini SDK的设计与开发，我的git水平与代码能力都在大幅度的提高，对开源的认识也更上一层楼。
通过本次SDK的设计开发，我们从使用者的角度考虑如何提供一个工具，同时作为使用者发现问题并认识到不足；深刻认识到用户是软件开发中不可或缺的一环，开源软件需要有实际项目在使用，这样才可以及时发现问题并优化。同时也认识到开源社区的力量，所谓众人拾柴火焰高，借助社区的力量可以办大事。
技术在交流中才有进步，有需求需要落地的时候大家一起交流，可能会发现一些更优的解决方案。如果不参与开源看到别人贡献的代码，可能没有机会了解对方的编码思路，使用的时候通常也不会专门分析“为什么这样设计？”、“为什么这样写？”、“有没有什么更好的方法？”等问题，开源提供了很多与人交流的机会，通过与其他开发者的交流讨论可以对技术发展、软件行业的发展、软件行业的生态都有更多的认识。同时，参与开源项目对英语表达能力有很大提升，通常英语使用仅限阅读而不常有表达的机会，在开源项目上有很多机会与其他人交流，英语表达的场景也会更多。
在24年3月的某天，向宇哥说经过社区推荐，决定接纳我为社区的新committer，这令我非常开心，openGemini是我参与的第一个开源社区组织，这也是我第一次成为committer。作为社区的新力量，我会同社区的大家一起成长，回馈并一起建设我们的社区，为openGemini社区的繁荣发展贡献力量！
在此特别感谢社区、以及我的领导和我们团队的所有人，求助事事有回应，这是我们能快速完成开发的基础。
openGemini 官网：http://www.openGemini.org
Star for me😊：https://github.com/openGemini
openGemini 公众号：
欢迎关注～ 诚邀你加入 openGemini 社区，共建、共治、共享未来！
