近日,Kubernetes(简称 K8s)圈内大佬 Noah Kantrowitz 连发多条推文抨击“FAANG”科技巨头内部晋升机制对 K8s 全职员工不友好,他指出,“科技大厂们的激励措施正阻止人们全职参与开源贡献,大家的贡献积极性正在放缓。”
Noah 的观点在技术圈内引发热议,有人对此表示认同,但也有人认为这样的判断有些过激。
Noah 在其推特中娓娓道来。“FAANG”代表着科技界一股最核心、最强大的势力,原本只是 Facebook、Apple、Amazon、Netflix 以及 Google 的统称,但现在已经成为“科技巨头”的代名词,而“晋升委员会”掌控着谁升谁滚的生杀大权。
虽然具体晋升流程各不相同,但大部分科技巨头都拥有相似的流程模式:
1)写一份材料,说明你为什么有资格晋升;
2)由经理将材料提交给委员会;
3)等待;
4)可能成功,可能失败。
而在这套流程下,申请材料非常重要,申请者得在其中描述自己的工作为什么重要、是怎么帮企业赚钱的、是怎么表现出自身领导力的,还得再附上一封来自高层管理者的内部推荐信。当然,如果申请的是高管岗位,那就换成外部推荐信。
因为材料太重要,所以组织和编写往往需要耗费夸张的时间和精力。而且交上去之后,申请者还得亲自上阵、像竞选拉票一样宣传自己。
并且,一旦申请被拒,基本没有第二次机会,所以这套制度在本质上就鼓励大家“要么做大做强,要么回家抱孩子”。“而且不管大家承不承认,我们的晋升其实就是在与同事们竞争,这就要求我们在激烈的对抗中脱颖而出。”
但不可否认的是,晋升带来的好处很实在:比如 Google 公司 L6 升 L7 的价值就是每年约 20 万美元,而 L7 到 L8 则是每年 40 万美元。其他大厂也有类似的模式,员工获得的不只是头衔,还有多得多的薪酬。
看到这里,很多朋友可能会抱怨“这不就是资本主义的老一套吗,不爽不要来”,而且这跟 K8s 有什么关系?“当然大有关系,因为晋升委员会多年来一直在刻意贬低全职 K8s 贡献者们的工作,或者说在刻意贬低整个开源社群的工作。”Noah 强调。
Noah 进一步解释称,可归因收入已经成为多数企业最看重的指标之一,但 K8s 几乎没有明确的归因收入。参与开源贡献的收益往往循序渐进,无法当成简单且直观的预期结果。这是事实,想参与开源就必须要接受。
他继续抱怨道:“开源维护人员长期超负荷工作”早就不是什么秘密,人已经这么累了,还要让他们每周再拿出长度不等的时间搞什么“晋升竞选”、在企业高管团队里“建立印象”,这可能吗?
大家有孩子、有生活、有贷款,但科技巨头偏又秉持着“不进则退、适者生存”的残酷理念。做了对的事却没有回报……“世界不是这样的,世界不该是这样的。”Noah 感慨道。
如此一来,一些人就“学乖”了,要么调到其他直接收入更可观的部门去,要么跳槽到体量较小、但更尊重他们专业知识的初创公司。但大多数人呢?大多数开源贡献者只能眼睁睁看着自己被现实困境慢慢榨干。
K8s 在行业中确实重要,但很遗憾,这个世界上并没有 K8s 公司。Noah 写道,“每位参与者要么跟我一样,从本就少得可怜的空闲时间里再抽出一点为项目做贡献,要么就是直接选家供应商供职——基本上就是 FAANG 这类‘科技巨头’。”
“K8s 项目可以说是毫无自主权,我们控制不了招聘、甚至控制不了成员们的工作内容。虽然也有一部分高级贡献者能根据特别兴趣小组(SIG)的指引工作,但这种情况已经越来越少,而且人员仍在不断流失。”
于是情况就变成了现在这样:维护者的总体规模越来越小,而且大多需要选择那些有助于个人晋升的贡献方向。
在 Noah 看来,这可能是阻碍 K8s 可持续发展的最大问题。“一股巨大的外部激励压力已经渗透进来,而我们对其束手无策。而且老实讲,我暂时想不出任何解决方案。”
所以 Noah 呼吁,如果看到这些推文的朋友中恰好有哪位是 FAANG 晋升委员会成员的,希望能认真想想该如何评价开源贡献工作。“至于普通贡献者,我也不知道该做何建议。虽然我通常会‘鼓吹’UBI 之类的资助计划,但这完全不足以支撑起如此大规模的开源生态发展。”
“我真心希望找到扭转这种颓势的方法。我坚信 K8s 既会成为未来行业发展的良好技术基础,也将成为我所期待的、令人惊叹的蓬勃技术社区。”Noah 最后说道。
Aeva Black 目前在微软 Azure 首席技术官办公室就职,负责开源生态,并担任开源安全基金会(OpenSSF)的技术咨询委员会成员,她对 Noah 的观点持赞同态度,她直言,跟决定转向产品开发团队的同龄同事们相比,自己的薪水一直要低个三分之一左右。她把它称为“开源税”——“虽然出于个人价值判断,我觉得这个税交得不亏,但也确实挺让人不爽的。”
Noah 在其推文中有提到,在人才价值的衡量上,开源工作价值的“不直观性”是个很大的挑战。毕竟修复掉 kube-apiserver 中的 bug 确实能帮 Google Cloud Platform 客户或者苹果服务避免一次代价高昂的服务中断,但这具体值多少钱?CI 稳定性值多少钱?社区幸福感又值多少钱?难以评估。
不过,有网友认为,不光是开源,大多数工程师的工作其实都很难被量化成可证明的收入数字,唯一容易量化的就是能直接产生收入的交付项目。“负责开发内部构建工具的员工怎么升职?设计新型培训模式的员工怎么升职?对遗留代码库进行大规模重构的人怎么升职?这些例子也都挺常见吧?”
“所以 K8s 也不例外。工程师必须证明自己的工作内容是否、如何跟团队目标保持一致。如果不一致,但他们就压根不该在这些事上浪费时间。虽然占用个人甚至上班时间参与开源贡献并不是大问题,但除非公司能直接从中受益,否则对职业晋升没有帮助也完全可以理解。”
也有人认为,到目前为止,K8s 最大的问题是其累积的技术债务。FAANG 晋升委员会很可能低估了 FLOSS(自由 / 开源软件)的贡献,但这对所有 FLOSS 的影响都差不多,并不局限于 K8s。
另外,还有不少评论认为,其他企业相比,技术大厂已经算好了,至少是在鼓励员工们参与开源项目的。
有自称来自 FAANG 大厂的经理现身说法,他指出,其实科技行业的晋升委员会已经比其他行业要更重视开源项目维护工作。“问题在于委员会往往是由来自其他职能部门的人员所组成,所以他们并不太清楚候选人参与的开源贡献究竟意义何在,于是只能从申请材料中稍做推断。不怕告诉大家,如果在其他行业,那开源贡献的意义等于零——甚至是负的。他们才是真正的只问结果、不问意义。至少在 FAANG 这边,只要我们把投入到维护中的精力转向拓展新功能,晋升成功率就能大大增加。虽然不完美,但已经算好的了。”
不过,也许 Noah 的讨论范围更适用于较高级别的晋升。有在 Google Cloud Platform 工作的网友分享说,晋升的考核指标是根据各个工作组来定义的、要求跟组内目标保持一致。只要提高 K8s 的稳定性这类维护性工作符合小组发展目标,那就可以当作晋升理由,完全没有问题。“OSS 项目的生存不是建立在道德或者情感层面的支持之上。对于像 K8s 这样的基础设施项目,企业都在根据自身需求做出贡献,Google 当然也是如此。”
但从若是涉及从 L6 到 L7,或者 L7 到 L8 级别的晋升,则未必如此。“一旦到了 L7 和 L8 那个级别,这样的小组成员就相当少了,他们的工作也逐渐变成引导小组发展、为小组制定目标。从这个角度看,那为 K8s 之类的开源项目贡献确实反而有碍他们的进一步晋升。”
参考链接:
https://twitter.com/kantrn/status/1511791378497384454
https://news.ycombinator.com/item?id=30938842
点击下方图片即可阅读
你也「在看」吗?👇