写在 Dubbo go 的第五年( 二 )


dubbogo 项目已经过了草莽阶段 , 形成了一个的 800 多人的社区群 , 所以 dubbogo-proxy 项目立项后 , 很快就在社区群内找到很多项目爱好者 。
2. 成员的 qualification
项目发展初期有很多同学会 Java 不懂 Dubbo 不会 Go , 最后都通过参与项目提升了自我的能力 。 当然有些人会担心项目代码的质量 , 但只要秉持 ''Community Over Code'' 这个 ''Apache Way'' , 在发展过程中这些问题都不大 。
2019 年时 , 参与 dubbogo 项目的成员中一部分同学平时的工作是进行业务开发 , 秉承着对中间件通信技术 “我是谁?我从哪里来?要到那里去” 的初心参与 dubbogo 的开发 , 无论是对 dubbogo 抑或是对其自身技术水平提升都产生了积极的影响 。
dubbogo 社区对 dubbogo 发版时间有一定期限要求 , 所以对参与人员的时间投入也有一定的要求 。 每个版本的核心功能的 owner , 需要保证在 deadline 期限内完成开发任务 。
dubbogo 每个版本都有一个发版人 , 负责相应版本的任务拆分、发展跟踪、代码 Review 和最后的测试验收 , 这就要求发版人自身的技术水平和时间投入极高 。 目前 dubbogo 每个大版本的发版人都不是同一个人 , 每次 dubbogo 发版 , 都意味着每个发版人的体力和精力的极大付出 。 于某在此致敬历届发版人!
【写在 Dubbo go 的第五年】 管理
项目立项后 , 就需要明确发展大方向、发展 milestone、版本规划、以及一段时间内的具体的开发规划 。 项目发展初期 , Roadmap 可以不清晰 , 先摸着石头过河 , 在发展过程中逐步明确其内容 。
1. 需求收集
dubbogo 项目发展初期 , 其目标仅仅是实现 dubbo 某个版本的功能 ,所以其需求收集并不用花费很久时间 。 随着 2019 年 8 月份发布 v1.0 后 , dubbogo 越来越多地被多家生产厂商投入生产使用环境中 , 目前其需求方来源如下:

  • 实现 dubbo 某个版本的功能;
  • 实际使用方的生产需求;
  • 为紧跟当下最近技术发展方向而进行的技术预演 。
dubbogo 当前的 K8s 注册中心技术方案就是紧跟最新技术发展方向而进行预演的极好例证 , 其发展时间线如下: