71 lines
9.5 KiB
Markdown
71 lines
9.5 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
05 蚂蚁内部开源：迈出第一步，但还有很长路要走
|
||
上一节玉伯分享了参与开源的故事与收获，开源精神和开源理念无论是在管理层面、产品层面都深深影响着他。除了 Open Source，我们也想让玉伯聊一聊对 Inner Source（内源）的看法。国内外许多大厂都在进行内源实践，蚂蚁也不例外。这一节玉伯主要分享了蚂蚁内源的发展，以及前端项目内部开源的经验。
|
||
|
||
|
||
|
||
极客时间：我知道蚂蚁现在在做内部开源，企业做内源需要什么条件呢？蚂蚁现在大概做到什么程度了？
|
||
|
||
玉伯：我可以先讲一下为什么会有内部开源。印象中 2019 年时，蚂蚁正式提出要做 Inner Source，Inner Source 的实践源自 Google 等硅谷公司。有时不少内部项目，因为各种原因，并不适合直接做 Open Source，然而公司已经足够大，比如说公司上万人甚至十几万人的时候，公司里其他团队可能也会依赖你这个项目，给你提需求，这个时候怎么办呢？从公司角度就希望你把代码开放出来，别人基于你的代码再去实现某个需求，这是内部开源的需求源头。
|
||
|
||
再回到蚂蚁做内源的背景，当时集团已经开始“去中台”了（建中台的目标之一是去重复建设，当中台开始阻碍业务增速时，拆中台、去中台的声音开始出现），要求技术中台回归业务线。但是“去中台”也会带来一个隐患：回归业务线之后，如何保证不会又冒出一堆烟囱？这也是 Inner Source 应运而生的一个原因。
|
||
|
||
如果我们在内部搞开源，哪怕技术回归到各个业务线，但是代码还是开放的，同时如果你的项目在这个领域是做得最好的，那其他团队就可以直接基于你的代码去做自定义，或者是大家在一起维护这个版本。所以在“去中台”大背景之下，Inner Source 是可以防止再次重复建设，或者至少可以减少很多重复建设。
|
||
|
||
但时至今日，在软件界依旧会有一个观念叫做“Not Invented Here”，不是在我这里发明的我就不认，因为不是我亲手创造的，用起来我就觉得不放心或者不顺手，所以总想在自己的业务领域去发明轮子。这就是轮子满天飞的原因，不光是前端，后端轮子更多。
|
||
|
||
前端老被吐槽轮子多，所以我们前端开源一开始就是以 Open Source 这种方式去做，但是后来因为公司变大了，各种内部的规章制度一管，加上中美关系的变化，就发现某些技术是要受保护的，所以导致很多技术其实并不适合做开源。所以回到前端做内源的真正原因，一开始也是一种无奈之举。
|
||
|
||
当时刚好在蚂蚁做内源的人联系到我们，他们老觉得前端做开源是鼻祖，就会问我们的意见，我觉得内源确实挺适合我们的。很快我发现参与内源有个好处，Inner Source 真正用途是解决人性的问题，一定程度上能解决“Not Invented Here”的问题。
|
||
|
||
比如说 AntV 数据可视化这个项目，最开始是我们团队去做的，很长时间也都是我们团队维护，所以很多人开始的观念就认为 AntV 是体验技术部的。Inner Source 来了以后，我们干了一件事情，让所有内源项目去团队化，让 AntV 变成是蚂蚁的，而不是体验技术部的。怎么做呢？首先把 AntV 贡献出来，变成蚂蚁的一个内源项目，类比一下就跟捐给 Apache 一样，捐给 Apache 之后项目就不属于自己公司了。内源就意味着 AntV 不再属于某个团队的，而是属于蚂蚁的，可以实现轮流维护。比如今年体验技术部维护，明年数金前端维护，后年蚂蚁国际的人来维护。通过这个做法希望解决“Not Invented Here”的问题。所以我们挺认可 Inner Source 的价值。
|
||
|
||
但现在也看到一些问题，比如很多人不愿意进内源，或者进了内源之后还是强调项目是自己的，是有归属的，其他人是来做贡献的。这也可以理解，特别是在后端领域。我跟后端工程师们交流过，他们很难解决这个问题，一个原因是如果没有归属，就可能没人维护了，还有一个原因是别的团队没有这方面的专家，接不住这个项目。
|
||
|
||
在前端这块，我们的做法是想一些办法让其他团队接得住，比如部门间人才的流通，把人才放到其他部门里，打破边界墙，这样在不同的团队都有人能参与及影响身边的人。AntV 和 Ant Design 目前算是部分实现了内源，是比较正面的案例，但像 Chair（基于 Node.js 的 Web 框架）很难内源出去，因为很少有团队能够接住，对方缺少这块专家。像这种情况，我们的做法是把一些模块、组件让其他团队承担，部分实现内源的目的。
|
||
|
||
极客时间：整体来说蚂蚁内部开源推进得还算顺利吗？
|
||
|
||
玉伯：谈不上顺利还是不顺利，蚂蚁内源还在路上。
|
||
|
||
这是我自己的判断，我理解所谓顺不顺利，是看做内源这件事解决了什么问题，从一级到十级，我心里至少得到六级才行。目前蚂蚁 Inner Source 只达到了源码开放，内部社区还在构建过程中，Not Invented Here 涉及的人性问题更难解，这涉及技术人才的发展体系设计。
|
||
|
||
极客时间：那未来要去做蚂蚁内源社区的规划，你认为要怎么去推进？
|
||
|
||
玉伯：内源的蛮难的。回到开源的三个阶段，第一阶段是源码开放，第二个阶段是社区讨论，第三阶段是产品视角。内源很容易卡在第二步，因为第二步有很核心的点，是要有足够的人参与进来。对蚂蚁来说，能够达到第一步已经是个进步，至少代码开放了。
|
||
|
||
极客时间：很多大公司都在推进内源建设，但把内源做成还是任重道远。关于开源，最后还想聊一聊商业化的问题，这两年对开源软件企业的投资也非常火热，你对开源商业化有什么理解？
|
||
|
||
玉伯：开源商业化的话题我一直比较关注，但这个话题，我没什么见解。这是因为，前端领域的开源，目前更多在做社区。某种程度上讲，前端开源项目的商业价值很难很高，业界的很多前端开源项目，有商业化尝试的并不多，商业化非常成功的凤毛麟角。
|
||
|
||
对蚂蚁前端的开源项目，我们受益于开源社区，我们的策略就是回馈社区，尽量不做商业化。
|
||
|
||
像 Ant Design，我们的核心代码都是开源的，大家用就好。时不时也有中大企业会联系我们，表示想购买 Ant Design 的商业服务，想付钱买服务。但后来我们自己算了笔账，他们要的真正服务是基于特定业务场景的 Ant Design 的深度定制，去做适合特定业务域的一套前端 UI 的解决方案，这是一个专家咨询加资产定制服务。这个服务极耗人力，然而在国内，大多企业给不到我们的成本价，如果去做，做一个亏一个。真要做，我们得给 Ant Design 组建一个交付团队，然后卖人力、卖咨询、卖服务，然而这是一个没有规模效应的生意，有能力付费的企业并不多，最终会很亏钱，这条路很难走通。
|
||
|
||
极客时间：所以如果要做开源商业化的话，基础软件还是更有竞争力。
|
||
|
||
玉伯：最近几年开源商业化确实很火，很多 VC（风险投资机构） 知道我做开源也总是找我，我其实都想清楚了前端还是做免费。但跟他们聊的时候确实也了解到，目前在后端的数据库领域，包括数据界的 DevOps 领域，开源商业化是挺热的话题。
|
||
|
||
很多做开源商业化的公司模式就是：开源就是商业本身。我开始也很好奇，这句话怎么理解呢？其实他们是分版本的，有一个开源版本来做影响力，另外的专业版本收费。
|
||
|
||
开源本身可以增加用户买单的信任度，因为你有开源版本，又有专业版，别人可以看到开源版本的代码，它不是黑盒，用户会更有信任感。
|
||
|
||
另外，通过开源可以抢占话语权，通过撬动一些生态的力量，然后一起去定义标准。通过开源可以博得业界声量，让业界开始认可而逐步成为事实标准，先开源就会抢占先机。
|
||
|
||
有了信任感、影响力，以及获得制定标准的话语权之后，往往就能够圈一波自然粉，会有很多用户跟随，其实这也是私域运营，到最后一步才会做付费。
|
||
|
||
这个模式能不能成功，这一波做开源商业化的能不能起来？还要再观察，因为 VC 的钱也刚进来，最终要看买单的客户有多少，是否能够支撑开源商业化的公司可以持续往前走。
|
||
|
||
小结时刻
|
||
|
||
蚂蚁做内源的原因之一是在“去中台”大背景之下，InnerSource 可以减少很多重复建设，尽量减少轮子满天飞的问题，同时前端团队参与内源开始也是因为一些项目不适合做 Open Source。蚂蚁内源现在做到源码开放也是迈出重要一步，只是离玉伯心目中的理想还有很长的距离。
|
||
|
||
你对内源有什么理解，是否从内源项目的参与过程中得到收获呢？欢迎在评论区发表想法。我们下一讲见！
|
||
|
||
|
||
|
||
|