清华博士创业之路:从程序员工作量化到开源价值分配

大东BE 发布于 02/25 14:49
阅读 4K+
收藏 3

在开源社区中,关于个人贡献者利益分配的话题从未停息。这些来自开源项目创始团队以外的开发者,出于个人的热情为社区贡献代码,那么他们是否应该享有一定的权利呢?

供职于英特尔的开发者 Thiago Macieira 是一名开源爱好者,他曾利用业余时间长期为 Qt 项目贡献代码。去年年初,Qt 官方正式宣布将项目 LTS 版本全面转入商业化阶段,不再向社区无偿提供。这一变化让包括 Thiago 在内的 Qt 外部贡献者感到心寒,他们多年来出于热情向 Qt 贡献的代码被官方当成赚钱的工具,自己却没有收到任何回报,甚至连无偿使用稳定版 Qt 的权利都没有。

比起商业公司或项目所有者,无数开源项目个人贡献者的利益往往更容易被人们忽视。

开源社区价值难以分配

事实上,除了项目创始人和极少数核心开发者可以通过开源项目获得一些利益以外,大部分开发者对于项目的贡献程度难以度量,这导致了开源项目所产生的价值难以分配到这部分人手中,这些利益包括社区获得的捐赠、项目商业化经营所得等。

知名开源前端框架 VUE 作者尤雨溪是少数通过开源项目实现财务自由的顶级开发者之一,在全职开发 Vue 的初期,他的主要收入来源是众筹平台 Patreon 上的捐赠。在 2017 年时,Vue 的核心开发团队已发展至近 20 人的规模,其成功离不开每一个人的贡献。尤雨溪曾尝试过将自己收到的捐赠分配部分给一位贡献突出的团队成员,却遭到了对方的谢绝,原因是“他觉得如果他拿了一些钱,那么对于同样从事这项工作的其他贡献者来说是不公平的。”尤雨溪坦言,如何正确量化和衡量每个贡献者所做的工作,合理公平地为每个贡献者分配利益成为了社区一直难以解决的问题。

与歌曲、电影、书籍等发行物的原创作者拥有明确的收益分成比例不同,大部分由团队研发的软件(无论是开源软件还是商业软件)很难将其收益分配给所有参与该软件研发的人员。清华大学计算机科学与技术博士、前微软研究院研究员任晶磊指出,造成这一现状的原因可以用经济学中的两个概念来解释,即信息不对称契约成本

信息不对称:软件用户很难了解程序员的开发工作,而每个程序员个体其实也缺乏全局信息以及对每个人贡献的了解。那么,谁又能来决定价值收益的分配呢?人们不得不采取如下两个办法中的一个:构建起公司的层级结构来进行价值分配,即便这个体系并不高效和公平;或者干脆放弃这些价值,免费开源,从而规避了分配问题。前者是商业公司的道路,后者是开源社区的道路。

契约成本:为了促成交易,每个用户需要和每位贡献代码的程序员达成契约,订立合同;所有开发者之间也要为知识产权的共享和酬劳讨价还价,直至形成共识和契约。更糟糕的是,开发者可能随时退出当前项目,也会有新的程序员加入;用户们更是会来来去去。于是,人们想了两个办法来降低这些契约成本。一是设立一个法人的概念,作为软件用户和开发者的中间人;这样,每位用户或开发者都只需要和法人形成一个合同。二是将所有可能的契约简化并统一成一个简单的开源协议。这样的简化降低了契约成本,但通常只规定免费共享著作权,而舍弃了更加有利的合同关系。前者构成商业公司的基础,后者构成开源软件的基础。

总结起来,不论商业公司还是开源社区的软件开发模式,都是人们面对信息不对称和契约成本而做出的妥协。正是软件开发过程中所有参与者的工作难以量化,从而导致软件产生的价值难以像歌曲、电影、书籍等出版物一样“公平”地分配。

如何量化开发者贡献?

从上世纪八九十年代开始,人们常常用代码行数 LOC 来衡量开发者在一个软件项目中的贡献,这种衡量方式无论在开源社区还是商业公司中都曾被广泛采用,甚至延续至今。

2015 年,LLVM 社区发起了对代码进行重新授权的提案,他们在这项工作中绘制了一张图来统计每个贡献者的贡献比重,其中每个矩形代表一个人所做的贡献,每个矩形的大小代表该人贡献了多少行代码:

由于不涉及利益分配,开源社区用代码行数来统计开发者贡献比重的方式无伤大雅。但在商业公司中,这种按照代码行数来计算员工绩效的方法就显得非常不合理。

2016 年,Facebook 内部仍在采用统计代码行数的方式计算员工项目奖金,这种简单粗暴的衡量方式遭到了业界的质疑。图灵奖获得者 Edsger Dijkstra 早在上个世纪 80 年代就指出,用 “每月生产的代码行数” 来衡量 “程序员的生产力” ,忽略了程序员的创造性带来的更大价值,反而会鼓励人们编写没有意义的多余代码。

为了探寻能够合理衡量开发者贡献比例的方法,任晶磊和来自 UC Berkely、清华大学、FreeBSD 项目组的团队成员开启了相关领域的探索。他们利用程序分析和机器学习技术,对代码的结构化价值和非结构化价值进行分析,以期找到能够更加全面、合理量化开发者工作的指标。

2018 年,团队在软件工程领域顶级国际学术会议 FSE 2018 上发表论文《关于量化代码贡献的开发价值》,引发了业内的广泛关注。基于该论文的学术成果,任晶磊与研究团队成员共同创建了思码逸(Merico)公司,以解决开源社区与软件行业的价值分配问题为终极愿景开启了创业之路。

合理评估开发者的工作量

以思码逸研发团队推出的一种新的量化指标“代码当量(ELOC)”为例,它可以用来替代 LOC。

ELOC 不是统计源代码层面的信息,而是评估源代码编译成的抽象语法树的复杂度。这样自然避免了源代码中注释、空行、换行等噪音。同时,对代码抽象语法树中的编辑类型、节点类型、函数内重复代码进行了加权计算,能够更加合理地反映代码工作量。

编辑类型加权:将抽象语法树从一个形态修改成另一个形态涉及四种编辑操作(Edit Type Factor):新增节点 Inserts,删除节点 Deletes,更新节点 Updates,移动节点 Moves。可以近似地类比为:新增代码,删除代码,更新代码中某语法结构的值,移动一段代码。通常可以认为这四种编辑类型的单位工作量是不一样的,例如删除一个节点比新增一个节点更“轻松”。

节点类型加权:抽象语法树的节点类型对应代码语法结构的类型,例如 If 节点表示一个 If 语句,Call 节点表示一次函数调用,String 节点表示一个字符串字面量。而生产不同类型的节点所需的工作量也是不同的,例如在代码中添加一个字符串比添加一个 If 条件语句更“轻松”。基于这个假设,ELOC 为不同的节点类型设置了不同权重。

节点重复加权:开发者在编写代码时,通常会有一些复制或者近似复制(复制后稍作修改)的行为。复制一段代码和原创一段代码的工作量是不同的,复制或复制后稍作修改会更“轻松”。因此在计算代码当量时,ELOC 加入了对相似代码段的检测,并降低其权重。

代码当量仅仅是任晶磊和其团队合理量化开发者工作而做出的诸多努力之一,其他的度量技术或指标还包括代码依赖关系、复用度、模块性、缺陷密度等等。任晶磊也作为起草专家参与了由中关村智联软件服务业质量创新联盟、中国软件协会过程改进分会发起的《软件研发效能度量规范》标准,其中定义了五大认知域几十种度量指标。

然而技术并非愿景实现道路上的唯一障碍。由于软件研发本身是十分复杂的系统工程,长期以来许多管理与协作都是在黑盒中进行,信息不对称的情况下只能依赖主观判断,市场上也没有使用量化数据的习惯。

一方面,当前市面上一些主要面向企业或者管理者的工具,通过统计代码行数的方式来度量开发者工作量,这对于开发者来说是显然是不合理的;另一方面,开发者自身的工作难以量化,往往只能依靠“PPT”、“演讲”等汇报形式向外界介绍自己的工作,这造成了软件行业中很多职场不公平问题的出现。

思码逸产品经理张开云告诉我们,公司目前的商业产品正是以此切入,通过代码当量等技术度量与分析数据,在评估开发者工作时不再单纯统计代码行数,而是聚合开发过程中的代码交付效率、交付质量、故障恢复时间、交付成本、社区贡献度等可视化数据,帮助企业研发团队客观评估、定位并快速解决研发过程的问题,主要面向企业或开发团队的管理者。

而在开发者侧,他们的产品也能帮助开发者更加客观地复盘自己的开发过程,补足技能树上的短板,同时也能够充分体现个人工作的价值,从一定程度上消除行业“内卷”。

通过这些商业化的尝试,一方面帮助研发团队在实际场景中不断打磨提升技术,另一方面也使量化开发数据逐渐被市场采纳,成为研发日常中的基础设施。这都为思码逸团队追求终极愿景打下了基础。

为了将已有的技术回馈社区,同时吸引更多的开发者参与共建,思码逸于 2021 年末开始将其产品的核心能力陆续开源出来。

DevLake 是其首批开源的项目,定位是开源的 DevOps 研发效能数据平台,在团队计划开源的三大产品模块中扮演着数据整合者的角色,帮助开发者团队在整个软件开发生命周期(SDLC)中整合和分析软件开发数据。

针对当前 DevOps 工具链复杂、数据散乱难以收集的问题,DevLake 可以汇聚需求、设计、开发、测试、交付和运营六大软件研发环节的研发效能数据,连通软件研发全生命周期;同时支持数据源的多样性,目前可接入主流工具 JIRA、GitHub、GitLab 及 Jenkins 的研发数据,并采用灵活的架构和插件设计,方便用户进行二次开发,接入自己的数据源进行分析。

张开云透露,尽管 DevLake 主打从复杂、异构的研发流程中收集并汇聚数据的能力,仅有基础的分析功能,但已经可以解决很多中小型研发团队基本的效能分析需求。知名开源数据库 TiDB 研发团队就在使用 DevLake 进行质量侧的效能分析,其背后的商业公司 PingCAP 内部也订阅了他们的付费产品进行更深入的研发效能分析工作。

DevLake 的开源只是思码逸回归开源的第一步,后续他们还将把包括量化开发者工作的数据分析技术在内的核心能力陆续开源出来,一步一步向公司创立之初的终极愿景迈进。

终极愿景

在创业之初,任晶磊曾在哈佛大学的演讲上描述了自己的终极愿景 —— 他希望能够把完善的开发者工作量化技术与股份制公司系统结合起来,创造一个开放的虚拟公司。

任晶磊在开源项目中引入了一个智力股权(intellectual shareholding)的概念。开发者向一个项目贡献代码,得到相应的股权,其数量由他们正在研究的量化算法动态计算;而项目的收益,如捐赠或赞助等,会按照股份比例(即贡献)分配到开发者手中。通过智力股份制,开发者可持续获得预期收入,即便他们选择退出一个项目或者这个项目只在一年后才产生利润。这种新的模型可以为开源开发者带来更加公平和长期的回报。

通过结合代码贡献量化和未来的智力股权模式,开发者将避免传统公司低效的层级组织、死板的工资体系和严格的知识产权分隔。特别地,非软件开发贡献也同样可以融入这个新模型。一个项目可以预留一定比例的股权或收益给非软件开发贡献者,例如外包的财务或市场团队。总之,一个开放的虚拟公司,既可以像传统商业公司一样获得利润,又可以保持开源项目一样的软件开发流程。程序员们将获得更多的自由选择他们真正喜爱和擅长的工作。

“也许在未来的某一天,所有的软件都将以开源或开放的形式构建,每一个程序员都能以自己的脑力付出获得持续、合理的报酬,只要你参与构建的软件能够持续创造利润,你可以在任何喜欢的地方写代码。”任晶磊说。

嘉宾介绍

任晶磊

清华大学计算机系博士,前微软亚洲研究院研究员,斯坦福大学、卡内基梅隆大学访问学者;《软件研发效能度量规范》标准专家组核心专家。在软件系统、软件工程领域从事前沿研究多年,具备丰富经验。曾在 FSE、OSDI 等顶级国际学术会议上发表论文多篇,亦参与过微软下一代服务器系统架构设计与实现。同时,也是一位积极的开源贡献者。

现任思码逸 CEO,通过打造先进的深度代码分析技术和研发大数据平台,以数据驱动软件工程,助力企业和团队提升研发效能。

DevLake 项目地址https://gitee.com/merico-dev/lake

加载中
0
程思
程思

如何量化开发工作,几乎是软件工程的核心问题。

0
睡懒觉的猫
睡懒觉的猫

脑力劳动的量化,确实是一个很复杂的问题

d
dwcz
劳动的量化,本就是因果搞反了的结论。劳动的价值是由结果定的,结果的用处不大,那所用劳动就是白费。资方之所以全收是因为利润远大于成本。搞量化也只是一种管理上的优化。
0
d
dwcz

这个问题好解决,从现有的方案中凑呗。不用股权,用期权。在有期权的前提下,先学人们干坏事时的办法--利益均分,再学商业上评价体系--好评多的多分。也就是,只要贡献了就有份,至于,每份的价值由使用者给出。“由使用者给出”的具体形式可以有:市场交易定价、行内评分、指定赞助、竞赛模式。开源完全可以发展出与现有公司不同的管理方式--非领导式。

0
万事通
万事通

世界上所有程序猿都面临的痛点问题

OSCHINA
登录后可查看更多优质内容
返回顶部
顶部