从2023年5月下旬开始参与InLong项目，已经快3个月，正好用这篇文章记录下我的这段经历。
参与InLong的起因是赋闲在家，虽然平时也会关注技术相关的发展，但是也担心久不写代码会手生。而参与开源项目就成为我的一个选项，在前司主要是负责大数据接入侧工作，也是出于对腾讯公司的喜爱就将目标锁定在Apache InLong上。
虽然，对于自身的技术水品并不担心，但是多少还是有一些恐惧在里面，这种恐惧可能来自于Apache的名头或者完美主义的想象。所以，在一开始我选择先在inlong-website项目中提交代码，它是InLong的官方文档项目。在阅读文档的过程中，自然的会发现一些问题（没有问题是不可能的）。参考其他已经合并的issue，自己也开始写文档，提交修改。
我们出生在一个好的时代，虽然我的英语很烂，但是翻译工具已经能满足我基本的需求。如果有这方面担心的朋友完全不用担心，你要相信维护项目的人一定能看懂你写的可能有错误的英语。
连续在inlong-website中提交3个PR并成功合并后，我也基本掌握项目的贡献流程，更为重要的打破了心里的恐惧（面对它，才能解决它），后面在主项目中提交PR也就水到渠成。
我有一个习惯，在了解新东西时会先将所有公开的信息浏览一遍，包含文档、项目、公众号、公开视频等，这个过程也是在建立整体的认知，比如公众号中一些介绍InLong demo运行的文章，就比官方文档更加详细和个性化。
接下来，我将精力花费在搭建开发环境和阅读代码上。这里有两个小建议：其一，不要放过任何一个在玩项目中出现的你认为有问题的地方；其二，明确自己感兴趣的模块，这能让自己的精力更加集中。InLong项目给我的第一印象是项目结构很好，CI/CD构建方面有很多是公司项目里可以借鉴的。只要愿意去深挖总能发现一些有意思和值得学习的点。这也是参与开源项目对个人的价值所在吧。
我已经记不得是如何与InLong项目PMC docker建立联系的。在与他的沟通中表达自己参与InLong项目的意愿，他给我了我很多的鼓励，也会将一些issue分给我，让我能更快的融入开源团队。
参与开发的过程中，让我更加确定理解业务和沟通可能比编码更重要。项目的开发者分布在天南地北，没法像在公司里一样，拉个会就能将问题对齐。而且，作为新人你对于项目整体架构和设计掌握的不够全面，那么在涉及重要功能或者全局性的修改时更要谨慎，先将方案沟通清楚再写代码会事半功倍。
当然，每个程序员都是各自的审美与坚持。难免，在一些功能实现细节和风格上会产生争执。这种时候需要一些妥协。我相信这些都能解决，毕竟大家参与到InLong项目的建设都是希望它更好。
这段时间断断续续的提交8个PR，目前正在开发sort中基于Flink1.15的kafka-connector。对我来说心态的变化是最大的，在使用InLong遇到问题不再是想着将其抛出去，而是去研究它为什么会如此，我能怎么解决它。感谢一路上帮助过我的docker、wake、van、healchow、goson等等。
最后，如果你看到这篇文章，也愿意参与到开源项目的建设中，那么参与InLong会是你非常好的选择，因为这是一个有爱的团队。
Apache InLong项目：https://github.com/apache/inlong