演讲者 ： 刘亚琼
来源 ： 中国开源云联盟
2020年12月29日至30日，由中国电子技术标准化研究院（以下简称电子标准院）主办，中国开源云联盟、木兰开源社区、全国信标委云计算标准工作组、云计算标准与应用工业和信息化部重点实验室承办的“第十届中国云计算标准和应用大会”在京盛大召开。本次大会以“标准聚力 开源共赢”为主题。
首先感谢大会的邀请，其实PingCAP之所以一直在所谓媒体上低调，是因为之前的发展真的是也都很曲折，因为毕竟是开源的项目，开源在中国的发展道路大家应该都懂，其实还是挺曲折艰难的。
我首先想感激蒋总，因为我能走入技术领域走入开源其实是在CSDN。
我介绍三方面：第一介绍一下TiDB，第二介绍一下我们为什么选择开源，第三介绍我们目前治理的一些方法。
TiDB是一款开源的分布式的关系型数据库，这是今年到10月份为止的一个数量，1500多家，右边这个是在GitHub上代码的贡献量是1200多个，我们自己内部的工程师大概有不到两百，更多的是一些来自于外部和海外的代码的贡献者。
这张图是我们选的一些比较有代表性的用户，他们代表银行、美团、三星、Zoom、UCloud这种的，目前在全国的用户部署了一些TiDB的项目。
我们为什么选择开源？对于一个做数据库的公司来说，已经有了Oracle这样的巨头在前面，其实你想做一个成功的数据库的公司是很难的。简单拆分了一下，如果要做一个可能是比较成功的公司需要什么？比较成熟的市场，高价值的场景或者说现代的一种商业模型。我们看了一下，这些好像Oracle或者其他的友商，做数据库的都有这些东西，我们从中国想做一个这种东西，我们需要跟他们搞一些不一样的地方。不一样的是什么？也就是首先我们从中国起步，我们在中国的市场能得到什么？
刚才蒋总也说了我们下一波红利是中国的工程师。包括我们家孩子现在4岁了，也在上一些编程的课。所以可以肯定的说，中国接下来十年、二十年是拥有全世界最厉害的工程师，同时中国自从互联网或者说移动互联网开始发展之后，它有了全世界最令人羡慕的场景或者应用，不管是泛在还是业务的发展都特别迅速。在中国市场能够给我们带来第一个是优质的场景，第二是足够厉害的工程师。因为仅靠PingCAP，首先是它的自己的钱不可能说完全去雇佣刚才我们说的一千两百位工程师去帮助我们写代码，这种在目前来看或者接下来五年来看应该都是不可能的，我们怎么样能够让这些工程师贡献到我们代码里，让这些场景被我们所使用。
开源好像是唯一的办法。
因为我之前是做2B的，2B和社区的玩法有些不一样，因为之前传统Marketing模式在2B里面基于漏斗模型，但在社区里面基于传统的漏斗模型会导致一些价值的流失，所以我们会选择用2C的方式去做2B，就是用社群的方式去真正做社区Marketing，我们选择的道路是传统Marketing变成运营，运营支持社区。之所以说漏斗模型在社群或者开源社区运营里面导致价值的流失，是因为传统的漏斗模型是基于不确定的因素，然后通过不断的去迭代，去往下漏，漏到一些关键的指标，然后给它关键的信息，让用户转化为付费或者他的核心用户场景。
开源是相对松散的组织，基础就是自由，可以随时来随时走，没有特定的权利或者义务，再用传统漏斗模型因为不确定性太大了，所以这个不太适用。
这是我们目前在做的一个模型。我们从BCP三点分析：C端大家可以理解为社区的开发者，社区的DBA、社区的用户、社区的人才，我们通过不断的去培养人才，去发掘人才，通过人才去建立一个护城河，通过他们不断的使用给社区一些功能做一些完善，通过他们去反馈给B端；B端就是我们的用户，我们用户如果需要使用TiDB，我们给对应的人做一些培训、赋能，帮助用户共同成功；不管是C端还是B端都会给我们的产品（P端）带来更好的打磨，帮助我们产品进化，同时给我们带来更多的解决方案，在产品不断完善的同时又可以去帮B端做业务成功。
通过开发者去赋能我们的产品，通过产品促进我们的User Base，再扩大我们用户数量和用户使用深度。
很多人好奇TiDB目前社区的项目到底在做什么，有什么职责，他们怎么跟内部进行划分的，我这儿简单写了一下。
我们现在更偏向于用社区的方式，比如说SIG就是一个小组，不管是Stack还是PR都会以SIG为单位去做，把相同感兴趣的人放到一个SIG里，对SIG活跃度做监控，比如issue，这个PR是不是被合并了，PR是不是等待review的工作。同时我们有一些挑战赛，月度的月会或者博客等等，做对外品牌的曝光。最后做一些比较基础的，大家更多的交互在GitHub上，我们有时候也会提醒他可能有哪些PR需要核了，有哪些issue需要去跟，这些通过BOT方式去实现。
TiDB的社区运营重点，第一个扩大漏斗，除了对外输出的用户场景和一些案例，之后有各种活动的布道，这种目前集中在开发者圈子里。同时我们做的比较重要的一点就是人才，对于人才现在分几块，包括我们对于最终用户的使用，里面可能会包括一些DBA，包括数据库的开发者，还有专门重做开发的。我们给他们做一些培训，他们到TiDB生态里面的企业可以做针对于TiDB的一些开发。这是扩大漏斗。
第二块提升向下的转化效率，其实很多人给我们反馈，大家看到TiDB的社区，来到之后发现很难。对于很多刚进来的人而言看到TiDB的代码觉得在看奥数，我们其实在做降低门槛，比如对于issue模板标准化或者对于PR的方式，对于抛出讨论的东西，都在不断的去做，就是为了降低开发者进入的门槛。
我们同时在思考一个问题如何更高效的扩大漏斗的第一层，激发人们的二次传播，其实跟我们最近思考社区自治是一个道理，但现在好像没有一个特别好的解决方案。
开源项目一般常见的治理架构会分为这三种：比如说仁慈的独裁者，这是TiDB目前在用的。或者说精英制，活跃的项目贡献者决策，决定通常会基于投票，Apache基金会提出。
我们基于仁慈的独裁者进行组织架构，进行对外公开做一些事情，有PMC、开发者组织等等，他刚进来是Committer，对开发者层级做了更细的拆分，大家会觉得TiDB社区做的挺好，会有不管国外或者大厂开发者来贡献，大家觉得做的很好，但其实在我们内部来看，我们现在做的所谓的这个组织架构真的有用吗？
不见得，因为我们如果做一个开源社区它的治理，我们希望最终的东西叫自治，我们现在有做到自治吗？整个PMC，目前在社区写代码的这些人可能不知道PMC里面有谁，我们自己内部人看一下PMC里面都是谁，基本都是PingCAP的人，这些人会对目前的情况做反馈吗？不会，这个东西没有起到真正的作用，所以我们最近在做的一项措施就是把目前的整个社区的治理架构废掉，重新去做，找那些真正去关心TiDB，真正愿意参与到TiDB项目的人进来，让他们去做这个社区的治理。
后来我们重新设立了新的架构，上面是一些Committee，下面有TOC、LoCo、Marketing和Publicity，我们通过TOC方式去做，之前并不是真正的社区组织，现在我们做TOC的时候特意标注了这一点，我们希望TOC是什么样的？
我们希望它是协调跨公司跨组织的，就是不仅仅是PingCAP，不仅仅是PingCAP的用户，比如知乎、伴鱼、360等等，而是可以协调各家组织各个项目，能够统一调动资源，做社区里面统一攻关的东西，这是这个TOC的目的，TOC肯定不是属于PingCAP的，而是说PingCAP只是TOC里面的一环。
我们初步投票TOC主席，TiDB、Tools等项目代表需要选拔，由CNCF孵化的TiKV、Chaos Mesh的项目代表各一名，组织建设发展，PingCAP代表一名，核心企业合作代表，他们能够共同决策社区接下来整个项目产品发展路线是怎样的，就是说PingCAP只是社区里面唯一一家可能说目前唯一一家商业公司在对外提供服务而已。
这是做完TOC建设之后给TOC制定的一些Meeting简单的工作流程，在这些活动之前我们需要去向各方面的Meber收集他们需要讨论的东西，因为TOC里面更多的是非PingCAP的一些人，大家的时间又很宝贵，所以要把这些流程提前规定好，这个可以包括TOC更快更轻量的去做。
这是在活动之中大家怎么提自己的项目，提自己的规划等等。基本上都是在之前要去做好。
目前TOC算是基本上建立完了。下一步要做整个开发者下面的SIG，之前各个SIG，大家觉得TiDB现在做挺好，但目前你们更多的人是说PingCAP人不断的推，不断的去做的，我们希望有更多来自社区的人加入进来，我们接下来会去找一些比较愿意比较积极的开发者进来，选取一些SIG的Leader作为试点，选取一些SIG，让他们真正有自活跃自治在里面发生。
另外对于开发者和用户进行分层运营，因为开源这种东西，我觉得你首先吸引大家进来，你的经历和荣誉感必须一直伴随他终身的，所以这块我们会进行一些增强，这也是我们明年到3月底主要要做的一个事情。
视频直播回看请点击“传送门”