开源在技术领域代表着开放和自由的精神，作为追求卓越的技术人员，与开源的连接密不可分。从早期的互联网到企业级基础设施，开源的采纳程度在不断提升，其影响力也在从生产力走向生产关系。本次访谈我们邀请到场量科技的创始人陈加兴，从行业经历和观察出发，聊聊开源对个人、组织的价值影响，以及这些影响将如何改变产业数字化的未来。
早期接触开源：作为学习者
Q：先谈一下您最早是如何接触到开源的吧
「陈加兴：」作为最早吃到“开源红利”者，接触到开源代码的契机是大学时期的论坛BBS。因为不满意当时最大的足球论坛“足球11人”网站站长对我们所在俱乐部版块的干预管理，通过对BBS的“技术预研”，我们离开并建立了俱乐部专属网站，一年时间就发展到十万会员，我是网站的出资者、技术提供者和站长。与“足球11人”只提供各个俱乐部的讨论版、站长搞一言堂不同，我们建立的球迷俱乐部由数个专业分工的小团队构成，包括翻译组、球评组和赛事组，我们开放地从球迷，主要是各大高校学生中招募志愿者，形成一套为球迷提供专业信息服务的机制。足球11人不久后就因为功用单一、管理不善而倒闭了，而我们的俱乐部目前会员数量25万人，是国内规模和影响力最大的球迷网站之一。让我自豪的是虽然我毕业后就离开了俱乐部的管理团队，但由我所创立的机制尤其是“非商业化、公益独立”的特征保持了20年不变，这也是一种基于开源的自由独立精神。
图：“皇马球迷俱乐部”页面
建设BBS的编程经验帮助我毕业后进入一家通信公司的信息化部门，公司主要是购买和实施商用套件，但我会搜索对应的开源产品，当时最著名的开源网站是 sourceforge.net （简称 SF ），提供了从企业产品到工具各种各样的源代码下载，根据热度排名，可以轻易地找到优秀的开源软件。
我阅读源代码的动机和小时候拆钟表机械一样，是为了研究它的内部实现。很快我也理解到企业决策者（直接上司是CIO）对商用、开源的采纳差异。05年时公司想引入CRM，我从 SF 上找到了 SugarCRM 推荐给了CIO，CIO说，我们公司咋可能用开源？最后买了 Salesforce。我很惊讶，为什么免费的、可修改定制的不用，却去用那么昂贵的产品？记得 Salesforce 一个定制化功能的实现，从头到尾都要和厂商扯几个月。实际上，那时候中国没有那么多工程师，CIO 也并不懂技术和源代码，“开源”尚是一个无法轻易驾驭的领域。
从产品功能截图，我们可以看到是 Salesforce 借鉴了 SugarCRM 的设计。后来我也是 Salesforce 的用户，它在计算项目资源尤其是整合项目费用、开票，实时查看项目利润上很有用，从使用者角度来说，不操心实现是最好的；但从工程师角度来说，必须理解整个系统的实现运作机制。研究 SugarCRM 源码让我掌握了 Cases 这个设计概念，或者说一开始接触到优秀的软件设计源码，对系统设计思维有很大的积极影响。另一个例子是搜索引擎，阅读源代码了解数据的存储与索引结构，对二次开发的效率效果影响非常大，可以这么说，开源对开发者的重要性就好比机械结构对制造工程师的重要性，没读过开源代码的开发者基本等于从来没见过机械内部构造的制造工程师，是不可能存在于行业的。
参与开源：作为模仿者
「陈加兴：」我最早参与的一个开源项目叫 Hubble.net ，它将 Solr 改为 C# 实现。早期国内的工程师水平还不能算优秀，很多开源项目都是“翻译”型，比如把一些C++开源项目翻译成Java，把Java翻译成C#，以满足特定的开发或客户环境需求。我最早参与的一个开源项目叫 Hubble.net ，它将 Solr 改为 C# 实现。刚好我很熟悉 Solr 又会 C#，就参与了进去。那是一个完全的自组织团队，包括开发人员和测试人员，平常大家用邮件往来，最早的代码托管都是 svn ，比如 SF 就提供托管，它是一个中心化的管理，你拉取到 trunkbase ，建立branch ，开发完成后通过邮件请求合并，根据版本计划最后从 trunkbase 发布一个 tag 。参与开源项目让我获得了基于工程的协作经验，这些工作在公司内部，都是由配置管理员负责的，开发人员并不关心也不需要关心发布过程。除协作之外，参与开源也使我建立起了深刻的以“发布”为结果导向的编程模式，即从开始就构想这些代码以什么样的序列连续不断地发布到目标环境，如何在既开发又发布的过程中让一些“中间工作”不影响整个系统的可用性。差不多在十年后，很多开发人员在发布时的选择还是把未完成的代码注释掉，造成很多重复工作甚至 bugs。参与 Hubble 项目的经历不长，但构建的经验帮助我很快上手任何开源代码，包括后来在工作中用到的 OpenStack 和 Jenkins，只需要两三天到一周左右，我就能够完成阅读并理顺关键模块的工作机制。08年一场地震改变了很多人的经历，对我而言也带来了一个重大项目的机会。由于灾后重建规模大、时间紧，通信公司从投资计划到采购到实施验收都需要快速响应，主流企业级厂商的项目管理产品，有的是文档协同，有的是规则引擎，有的是工作流管理，而灾后重建工程项目最大特征是风险和不确定性高，实施过程无法遵循计划并且不可预见。比如，修建过程中经常塌方，项目经理需要紧急修改计划并根据一线人员提供的参数计算损失、快递传递到上下游系统（投资、立项、进度、采购、供应商及财务等），再根据周边进度对计划进行重排，为了不影响整体重建，项目经理在一个项目工期受阻时也需要快速转移资源到其他项目上，这种多项目并行、实时协同在通信公司过去的项目管理经验中也是没有的，市场上缺少这样的软件，必须定制化并实现一个非常灵活的管理过程。可以理解为，该平台需要在过程管理中融合即时的事件响应与决策机制。作为需求方，并不能清楚地陈述这个需求特点，而是直接给了我们全部的项目纸质材料，堆起来比我人都高。项目团队一开始的思路就是把这些纸质文档“线上化”，再基于工作流审批串联起来，但无法解决固定流程如何实现灵活配置，尤其是从成千上万的表单中获取特定的数据并影响下一步流转规则。我马上自荐为架构师去设计了该平台，核心就是借鉴了 SugarCRM 的Cases 流转概念，与研究客户需要的厂商产品优点不同，我重点研究了 workflowpatterns.com 网站提供的，设计概念，将其规则从人/角色/动作扩展到 Cases。通过一个月的核心代码编写，满足所有工程管理过程中的活动运行规则都实现了。
图：项目团队合影
在开源产品中我较熟悉的领域是开发者工具，以比较有代表性的微软开发者系列与Java等其它为例作一个对比。
微软的开发者工具从最早的 Visual Studio、VSTS 到 Azure DevOps，功能全面性、系统性、先进性和灵活性兼得。Visual Studio 是最早提供从源代码生成架构图的工具之一，为快速理解数十万、上百万的大型工程提供了便利；VSTS 也是最早提供自动化测试计划、案例编写、脚本编写并打通执行计划与结果报表的工具；Azure DevOps 类似于企业级 GitHub ，功能全面性是非常强大的，仪表板定制化程度也很高。
VSTS 从语言到功能都是一个封闭生态，Java 的开发者工具既有商业的，也有开源的，最为流行的是开源的 Eclipse。从体验来说，商业产品优于开源产品，包括 Java IDE，JetBrains 的工具体验比 Eclipse 强大太多，厂商设计能力更为专业。但对开发者而言，我们在使用 VSTS 时就发现了它的局限：一家厂商的工具再强大，也无法满足所有开发过程对工具的需求。比如测试人员很满意 VSTS 的测试套件，但做性能测试时她无法在 VSTS 执行计划里把 loadrunner 挂进去，而 VSTS 自带的性能测试工具有很多 bugs ，测试人员认为是“没法用的玩具”。再强大的工具厂商也无法覆盖到所有的细分领域，多个商用工具的集成使用成为了影响软件团队效率的一个因素。
我们的持续集成本来用的是 VSTS 构建方案，一个新的开发人员入职，我让他负责这块工作，他告诉我 Jenkins 是开源的，可以集成很多插件，他让我回忆起当年我向 CIO 提议 SugarCRM，于是我鼓励他继续研究，仅花了一周时间，我们就从 VSTS 切换到了 Jenkins，也意味着一个公司的开发团队正式连接到了“社区模式”。Jenkins 能够让新手级工程师在第一次接触时，通过方案搜索、下载、使用、对比，认为它是最好的，这就是它的成功。数年后我加入了 Jenkins 曾经的“竞争对手” CruiseControl 以及 GoCD 的公司 ThoughtWorks，内部负责人和很多当年的核心开发者都为输给 Jenkins 愤愤不平，认为 GoCD 的 Pipeline 设计理念更领先。
图：TW咨询团队合影
从使用者体验来说，Jenkins 以开源模式的可触达性更好，更容易获得开发者认可，插件生态也是它胜出的因素之一，使集成功能规模快速发展，比如 loadrunner ，可以在 Jenkins 社区找到插件，报表方面，也有很多统计类插件。
采纳 Jenkins 使我们的持续集成能力飞跃了N个数量级，VSTS 提供的是一整套功能，而 Jenkins 提供了一整套理念和可扩展能力。软件开发工作的实质就是动手，learning by doing，通过动手获得的知识巩固了技艺，提升开发团队的能力，这是商用产品无法提供的。「陈加兴：」我大量时间都在商业项目上，源代码归属权不在我，所以很少有社区贡献的机会。第一次将代码提交到社区是基于 AWS CloudFormation 写了一个 OpenStack 的实现，并不复杂，从这点也可以看到，开源截止那个时期还是对商用产品的模仿。企业为什么会有对开源的需求呢？是因为商用产品没有覆盖到这些用户场景。以云计算为例，AWS 提供的是公有云，按使用时间计费，它适用于有弹性的生产环境，而企业的开发测试环境是长期、稳定的使用，采购硬件资源自行搭建，只需要支付一笔固定费用。开发测试环境的使用特点是反复地安装、部署、验证和移除最新的软件系统版本，过去在虚拟机环境下，每次测试的重装、启动非常缓慢耗时，企业希望利用这些已有的硬件，通过云计算方案加速基础设施、操作系统、软件、数据库、应用的安装，并能够进行自动化编排，只有开源能满足这样的场景。
「陈加兴：」前面提到的均是对开源的运用与模仿实现，但正是因为这些经验打下的基础，才得以对它进行突破性的改造。在帮助客户构建组织级的持续集成云平台时，我们使用了微服务架构对 Jenkins 的 Master/Slaves 架构进行扩展，满足了万人级高并发集中式构建部署。为什么要用微服务架构？在阅读 Jenkins 架构文档时，它在 Master 服务器的内存开销说明中提到远程通信中每个 Slave 会消耗 Master 服务器 2M 内存，而 Master 的响应速度是整个构建部署中的关键制约因素，因此，无须维持状态的服务能够极大节省 Master 的性能开销。
接下来的问题是，微服务怎么拆分？或者说，什么功能该是每个微服务的功能内核？快速阅读 Jenkins 源码后，我们确定了 Builder 应该成为微服务，而不是对 Slave （它是一台机器）进行包装（Facade）；从 Builder 入手，只需要解决不同编程语言的问题，而 Slave 还包含了操作系统的差异，前者的类别更少，部署及之前 OpenStack 基础设施编程的知识帮助我们把不同的操作系统的问题放置在微服务部署而不是开发过程中去解决。从“好系统”建立起来的良好的设计直觉帮助我们快速从概念层面构建起平台化的结构。确定了平台架构模式，就基于这个模式的实现进行展开，分别去击破实现中的问题，仅花了三个月时间，我们就发布了平台的 MVP 版本：Java Build Service。
图：项目团队合影
我对该项目创新的总结是“青取之于蓝而青于蓝”，在开源经验之中获得启发、整合和突破，我们在项目上创新的成功，也带来了一个组织的敏捷能力的极大提升。
图：“敏捷学院”合影
Q：结合您这些年的经历，您能否对开源的发展和未来进行一下展望「陈加兴：」我在一开始接触的就是开源应用型软件，它解决了一个兴趣群体的需求，但在企业场景中未被采纳。有趣的是，基础设施开源软件是后于应用型发展起来，却早于应用型软件被企业采纳，核心还是看企业需要解决的紧迫问题是什么，可用的解决方案有哪些。当然操作系统的开源也比较早，具体的我没有实际参与，就不展开，也欢迎同行指正。目前各行各业的数字化转型，就是软件、平台、工具大规模地在企业的各个环节中被引入、采纳，自然存在很多从基础设施到应用场景的多处空白。一方面是需求在推动，另一方面，企业缺少足够知识来设想出技术需求或最好的技术产品/功能，比如在工程项目管理中 Cases 流转的设计，这种情况下更多是供给来推动，以好的产品/功能来启发：原来可以这样解决问题。
我已经看到了不少成功的开源项目偏向于基础类，于是我也会思考，应用类的开源成功可能性，以及企业的采纳程度会是怎样的，会不会像二十年前那样，企业的决策者更看重商用产品，对开源软件采取渺视、漠视的态度？我们怎样来分析？首先从需求端看，企业采纳IT产品的群体变化。现在技术人员更多，中国的技术人员已经超越了美国；创造力更强，很多新的应用型创新都出现在中国，比如说数据库中间件就是一个比较偏“中国式使用场景”的产品。技术型决策者，尤其是会编程的技术决策者，会更倾向于采纳开源、可控的产品，因为后者的可扩展能力更强，能更快地交付新功能需求。
接下来从供给端看，商用产品的供给规模、能力的变化。Atlassian 的 Bamboo 不如 Jenkins 成功，不是因为它的功能不好，更是 Jenkins 的生态圈更大。生态圈是开源天然胜过单一厂商的因素，因为它能够构建出更大的供给规模。开源生态圈并不是吸引和拉拢了最优秀的开发者，而是它吸引和拉拢了最具有潜力的开发者，把他们变成了最优秀的开发者，开源的“造血”能力是商业公司无法企及的。
最后从产业关联理论来看，一个产业链的价值创造是“中间产品”在运动过程中的不断增值，产业链也正是通过中间产品建立起技术关联。如果一个产业，被数字化成功重塑其产品、服务、生产和管理模式，最重要的“中间品”应该是作为最终产品构成部分的技术源代码。可能非经济商业背景的不太明白这是什么意思，举个例子，我们日常使用的牙刷，刷柄就是中间产品，刷柄的材料会有塑料、木制或胶制，分别由不同的厂家提供。中间产品的存在与规模与最终产品的生产过程和规模正相关，最终产品越复杂、生产过程越长、规模越大，中间产品就会越多。
对开发者群体来说，开发者工具就是一种“中间产品”。工具在细分市场的规模并不大，以 JetBrains 为例，2021 年 2.2M 用户贡献 2.52B 营收，共有 1500 位员工，算下来每员工创造 16.8 万美元价值。这是一个小规模、追求精细化和深耕的市场。而产业发展到数字化阶段时，意味着不止是基础设施（承载运行、存储等基础能力）以及开发构建工具进入到数字化的过程中来，市场需求规模与响应速度的差距会打开更多的应用中间产品市场。在数字化转型中，很多企业的误区在于致力构建软件“能力”而忽略了软件“生态”。作为技术人员，我认为99%的软件技术门槛并不高，蜂涌式建设源自企业害怕在竞争中落后同行，害怕被技术公司跨界打击，这就好比银行挤兑，所有的企业都构建技术能力是一场“技术挤兑”，最终的结果就是买方消失，市场消失，因为没有交换、交易的需要，并且企业的资源能力都是有差异的，忽略核心竞争力也造成了资源投入的浪费。从前面从案例中已经证明了，没有一家厂商可以满足市场上所有的需求——如果我们把 Jenkins 这样的开源工具视为一种中间产品，它的致胜因素是生态规模。因此，我们绘制的产业数字化价值创造的路径，是在大量、丰富的软件中间产品的基础上，下游企业开发出最终产品。对中间产品来说，生态规模是关键成功要素，对最终产品来说，独特性以及消费者价值等传统的衡量标准并不会有大的改变。目前低代码是在降低非专业公司的开发门槛，但它尚不是直接作用于数字化产品的开发构成。对技术产品来说，开源是生态构建的一种手段，面向的对象是开发者。在产业中的开源产品更多会面向决策者和采购者，它更类似于传统产品在采购环节中的各种技术评估与验收。所以未来的“开源”未必完全等同于现在的“开源”，包括社区的收入构成与分配，将会出现很多颠覆式的变化，但这些都是积极的变化，所有的新事物，都是因为有旧事物无法满足的需求作为前提出现的。
图书推荐
Q：能否给刚接触开源的小白推荐一本书，也说说为什么「陈加兴：」RedHat CEO 写的《开放式组织》开源在技术上五花八门，以开发者视角最多也只能掌握若干个相关领域。RedHat 这本书讲的组织、文化、开放和创新精神，是所有开发者共享的部分，也值得非技术人员参考借鉴，了解开源“究竟影响了什么”。
成立场量科技的愿景是探索和提升数字化生产力，贡献解决方案、产品工具及咨询服务。目前我们主要围绕软件开发效能提升，为企业组织提供定量定性的差距分析、现状问题诊断和改进方案制定。在定性分析上，我们积累了近二十年的行业经验与众多大型企业关键问题分析解决的能力，在定性分析上，我们自主研发的 X-Developer 研发数据集成分析平台是业内首创的产品，在数据、指标和诊断跟踪方面已经能够全面地洞察技术型组织。我们目前的定位是服务提供商与产业数字化的参与者，因为我们的业务规模还没有到形成社区和生态的阶段。只有在产业的人才、软件、数据达到一定规模的基础上，更专业的细分市场才会更加的成熟，现在很多创业公司和大型厂商都在卖力地推广开源社区 ，我并不太赞同。
社区是由人构建的，我的开源理念是既要有主导的模式，又要有自发的动机，才能形成一个可持续、有生命力的社区。
