给开源项目分钱，为什么总有人觉得亏：一套利益分配机制的现场笔记

上个月在南京见一个做插件的朋友。四个人，项目一年流水八十多万，散伙饭吃得像追悼会。A说代码八成是我写的，B说我天天回issue到凌晨，C说服务器和备案都是我扛的，D没说话，默默把群退了。

钱少吗？不少。可每个人都觉得自己亏。问题不在分蛋糕的刀快不快，在于利益分配机制根本没把“谁做了什么”变成能摆上桌的账本。说白了，机制不是数学题，是一套让贡献可观测、可申诉、可迭代的约定。

先别急着谈比例，把贡献拆成能看见的信号

很多团队一上来就吵比例。我拿六成，你拿三成，他拿一成。吵到凌晨也没结果。为什么？因为“贡献”还是个模糊词。模糊词一进分账表，就会变成谁嗓门大谁有理。

我见过一个插件团队用代码行数算钱。结果有人把格式化工具跑了一遍，diff多了三千行。还有人把一行注释拆成三行。你说这是坏吗？不全是。指标长什么样，人就往哪里长。这是机制设计里很朴素的反馈回路。

我的做法是做一个贡献账本。别怕这个词，它就是一个事件流：commit、code review、issue分类、线上值班、发版、文档、社区答疑、拉新维护者。每个事件记四件事：类型、难度、影响面、时效。难度用同行评议，影响面看受影响的用户或模块，时效看是不是救火。然后定期打快照，季度结算。

这里可以借一点Shapley值的思想。听起来吓人，其实很土：看移除某个人之后，项目产出会掉多少。掉得多，边际贡献大；掉得少，贡献小。实操里没人真去枚举所有组合，但你可以做近似：维护者投票、模块归属、事故复盘记录。关键是让“贡献”有证据，不是靠记忆。

账本不是KPI。KPI会逼人刷量，账本用来复盘和分账。两码事。账本要能看见脏活累活，否则写代码的人总比回issue的人显眼。对吧？

权重不是拍脑袋，脏活累活得有价格

权重怎么定？拍脑袋也行，但得拍完写下来，下一季度还能改。我给一个粗糙的起步表：代码四成，评审两成，运维支持两成，文档社区两成。每个类别内部再封顶，防止一个人把某一类刷爆。先留20%进公共池，用于救火、新人保底、法务税务和突然的维护者退出。

有人会问，评审凭什么两成？因为评审是隐形的刹车。没有评审，代码能跑，但三个月后没人敢动。线上值班也一样。一次事故，写代码的人十分钟修好，大家鼓掌。可之前写监控、写告警、写回滚脚本的人，可能救了命却没出现在事故群里。分账要追溯，不然下次没人愿意做那个“看起来没产出”的人。

常见误解得拆一拆。按star数分？star是流量信号，不是贡献信号。按谁在群里活跃分？嗓门大不等于贡献大。一次性定死比例？项目阶段一变，比例就失真。还有一个隐蔽误区：把分账表当合同。它更像一个持续谈判的界面，得留申诉窗口，比如结算后七天内有异议，拿证据说话。没有申诉，沉默的人就会直接退出。

风险也在这。指标会被人玩，公共池会被滥用，新人冷启动会被老账本压死。我的补丁是：新人前三个月有保底积分，但不挤占历史积分池；公共池每季度公开用途；贡献事件允许补录，但需要两个维护者背书。别追求精确到小数点，追求“大体服气”。

机制跑起来之后，怕的是沉默的人直接退出

说到底，利益分配机制只能处理可协商的部分。项目如果强依赖平台流量、销售渠道、资本输血，技术贡献就不是唯一变量。你非要用一套贡献账本去分所有钱，机制会崩。边界得提前说清楚：哪些收入进分账池，哪些算公司资源，哪些是个人外快。

还有个现实问题：税。个人分账和劳务报酬、经营所得不是一回事。别等年底才发现账本对不上发票。技术团队常忽略这个，觉得谈钱俗。可钱的事不谈清楚，代码也写不踏实。

我见过的健康状态是：每季度一次复盘，账本公开到事件级，金额公开到类别级，个人隐私打码。有人觉得亏，可以提，提了要改规则。规则改完，下一季度再跑。机制不是一锤子买卖，是一台需要保养的机器。话说回来，如果四个人连账本都不愿意一起看，那散伙饭迟早要吃。只是早晚的事。