开源&开发者关系

[OPEN强] 开源&开发者关系

background

忽然有群友反思:

我现在面临一个问题

• 我大数据从业5年，一致从事开发工作和产品工作，但是我发现我很喜欢开源运营。明年想尝试转型开源运营。但是有几个担心
  • 1. 开源运营我可能需要从0做起，薪资肯定也较开发低，我不愿意放弃我大数据的技术积累。
  • 2. 我从事开源运营后，把爱好变成工作，可能也会热情不在。
  • 3. 国内开源运营行业，人才市场、职位晋升是否良好，以后的晋升路线不知道怎么走。

logging

俺的吐糟

这位的直觉都对,

结论就是,

嫑转行,
嫑转行,
嫑转行,

业余作, 给公司也是一个义务志愿者的概念就好, 这样, 有时, 申请点儿公司资源, 感觉不是常例也就给了

俺的经验,

• 作是一定要作,而且得坚持,
• 只是, 绝对不能以一个确定的岗位去作,
  • 否则, 第一时间, 你就找不到一个可信的效能评估体系,
  • 越作越难, 最后将自己作没了

Richard Lin 的回答:

• 1. 开源运营我可能需要从0做起，薪资肯定也较开发低，我不愿意放弃我大数据的技术积累。
  • ——不需要放弃。开源运营也不是那么高门槛的事情，可以兼着做，未必全职做。技术还是根本。
• 3. 国内开源运营行业，人才市场、职位晋升是否良好，以后的晋升路线不知道怎么走。
  • —— 我感觉还是开发的晋升道路比较宽广。开源运营很垂直，流动性也比较差。

没错, 将开发作为岗位, 开源运营作为附加能力, 就很流畅,反过来就很尴尬..

然后, 引发新的直觉: 我感觉这是一个新兴的行业，但要求和以前不太一样。有技术实力，能自己开发+可以和开发者沟通的开源运营还是比较少的

这个感觉是对的,

• 只是, 远远不可能发展到因为你激励了多少开发者来使用企业的开源组件而给你工资,
• 因为, 这个逻辑线上, 企业的财务没办法核算成本和收益;
• 所以, 开发具体产品为基础, 附加能自我营销推广的开源运营能力,
  • 就变成 超级个体了
  • 反过来, 只能变成被市场部控制的小丑

也就是江湖传说, 比谁熬的时间长,

• 简单说, 就是混个脸熟,
• 如果你10年如一日:
  • 每周发布一篇开源社区相关文章,
  • 每月进行一次网络直播分享开源社区运营故事,
  • 每年参与42次各种社区大会...
• 你一定是无可争议的开源社区大佬

当然有追问: “超级个体”这个提法很精准..问题就在于，为什么一定要“超级个体”而不“分工”

这方面俺就习惯性吐糟了:

因为:

• 分工, 就有沟通
  • 沟通必然有成本,
  • 成本引发信息损耗,
  • 损耗带来误解,
  • 误解制造矛盾,
  • 矛盾积累到最后, 一定不欢而散...
• 所以, 超级个体, 所有沟通都是内部自我内存沟通,
  • 无损耗, 效能 MAX ,任何组织都干不过...

ask

比如我这边一直想搞一个贡献者激励的体系,一直没有头绪

这方面, 俺就更加想吐糟了:

• 其实有很多,
  • 无论物质的还是精神的都很多,
• 问题在, 你是否能一直有这些资源的控制权,
  • 如果没有, 那就别启动,
  • 否则, 朝三暮四, 很快就没人相信了
• 比如, 之前 Ali 学习 Google , KPI 立了个社会影响因子:
  • 根据对外发布的文章,演讲, 以及图书等等,折算为影响力
  • 年底核算为奖金,绩效;
  • 开始, 没人相信, 只有一些习惯分享的老开源人提交了相关资料
  • 有了先例, 大家就开始作题家分析:
    • 我一年要发布多少文章, 或是演讲, 就可以拿到多少奖金?
    • 消耗多少时间?
    • 而要扛小组指标, 又要花多少时间,还不一定成功?
    • 聪明的发现其中价值偏差了:
      • 小组业绩是有严格质量评估的, 比如当年故障控制在4个9还是6个9,投入的时间精力成本是越来越大的,
      • 但是, 社会影响却是随着积累越来越轻松的..
      • 那么, 为什么不...
    • 慢慢的, 企业发现, 这么多社区大佬, 可系统总是出问题, 双11的利润也在下降, 就关闭了这方面的指标
    • 瞬间, 主动出来分享的工程师们就消失了..

所以, 参考: EKM小解

其中最核心的断言就是:

知识管理
    乃是构建
        可促发
    成员成长的环境

可问题在,

• 真正有 EKM 体系存在的企业,
  • 这种体系本身就是成员构建的,
  • 也就是说,
  • 好企业, 基本上只招有自主成长/学习习惯的好人,
• 只有其它企业, 不得不想办法推动成员,因为:
  • 不敢裁人,
  • 也招不到好人

所以, EKM 搞来搞去, 就非常像安慰剂

有网友摘抄相关图书片段:

在知识社群中持续分享这件事，可以慢慢来，不需要急于求成。不过，当我从个人的角度思考自己未来的发展，不考虑其他因素时，我发现自己必然要做一个属于自己的IP。但我要明确的是，做 卫P 不是我的最终目的，而是通过这个过程来了解我自身的价值点是什么--对于社会以及那些真正需要我的人来说，我能够提供的独特价值是什么。 更重要的是，我需要清楚地知道他们是谁。这一点对我来说尤为重要。如果我不了解这群人,我就无法直接服务于他们，也无法真正为他们提供价值。这种逻辑对我而言是贯通的。所以，无论如何，我都必须去做这件事。尽管我无法从一个完全理性的角度说明为什么，但我内心就是觉得，这件事情是我必须去做的，没有理由可讲。 最初，我的目标是专注于如何提升社群的粘性，试图了解大家喜欢什么，希望能够搭建一个社区，为大家持续提供价值。 ... 因此，我意识到，要解决这个问题，必须更加深入地去了解我的用户群体。这不仅仅是对社群运营的一次复盘，也是在重新审视我自己的定位和目标。虽然这些思考有些零散，但这可能正是我最近经历的一些内心探索。

可能是翻译的问题, 如果一个 EKM 主持人说出这话来,

...如果我不了解这群人,我就无法直接服务于他们，也无法真正为他们提供价值

基本上, 就等于是承认自己不是知识型工作者了

• 就像混圈子, 每当你拼命想进入一个圈子时, 其实在远离,
  • 只有自己变成那个圈子的人所思所想所行,
  • 才不觉已经在其中,
• 知识可以被管理, 但是, 使用和创造知识的人不可能被管理知识的办法来管理,
• 说出这句话, 就已经将自己排除在知识型成员之外了, 以管理者角度去看,永远搞不清的

类似:WIKI 不是这么用的

简单说:

你为什么认为, 
你都能找到的资料, 
成员们竟然找不到?

互联网有了搜索引擎后, 高质量资料的获得早已不是事儿了,

• 所有的问题在:
  • 为什么要干自我成长这么低效的事儿?
• 在 KPI 制定时, 坚定些, 死也不要那些过高的指标,
  • 那么你永远是安全的,
  • 这也是为什么同一个技术组织中,
  • 女生/经理们的 KPI 成绩总是不错,
  • 而老实听话的年终总是拿不到高分的原因...
• 学习, 毕竟是反人性的,
• 而且公司的制度中, 并没有给出学习实践的时间和空间,
  • 要自己下班另外折腾,
  • 那么, 别人下班跑关系, 拉生意,
  • 你慢慢成长, 即便是真的有了一定技术,
  • 可并没有机会去使用, 作出业绩来,
• 长期下来, 无非是两种结果:
  • 成长到岗位容纳不了, 跳槽,
  • 躺平, 永远以中位线水平出活...
• 而, 企业, 特别是大企业, 在业务稳定后, 也只需要听话的普通员工而已

说到底,

• 成员没有动力找哪,
  • 也就是根本没找,
  • 又或是, 找到了, 也并不分享出来而已,
• 说穿了, 找, 看, 理解, 尝试, 融合...
• 有了靠谱的资料, 并不等于立即拥有了对应能力,
  • 还有一系列更加艰难的自我学习过程呢,
  • 这个过程不是没有成本的,
• 只是, 这个成本在一个永远没有机会变成收益的组织中,
  • 就变成的必然的沉没成本,
  • 成员, 为什么要努力?

而中国开源运营者, 最深切的尴尬就是:

• 明明身处这种尴尬企业中,
• 却要在对外时, 无时不刻强调自我成长的重要和快乐..
• 而, 真的从社区招聘到对应积极成员一进来,却要面对一样的尴尬

综上, 在中国技术社区的开源运营,

• 其 贡献者激励的体系 本身就应该脱离具体的物质奖励,
• 毕竟, 心理学研究也反复证明了, 奖励对于成事儿, 并无正向作用
  • 毕竟, 一切奖励都有制度性缺陷,
  • 嘦足够聪明, 都能发现其中内置矛盾加以利用的..
• 而 GNU 以降, 早已成功证明并健康运营的奖励体系一直就存在的:
  • 正确的叫好
  • 称赞, 来者同行的称赞永远是最给力的激励
  • 因为:
    • 只有看得明白自己代码的人, 才能看出其中的创新点加以针对性称赞
    • 这种称赞外行根本看不懂, 而每一次叫好本身也是新创新点的激发点
  • 社区, 嘦将这种称赞机制化, 永久化, 显著化就好
• 以往是通过邮件列表形成的公开称赞
• 现在有更加自然的场景和平台了, GitHub:
  • 反正所有代码以及修订都是公开以及永久的
  • 同时, 也允许针对每次的提交, 以及具体的代码行进行点评
  • 那么:
    • 组织定期/不定期相互 code review
    • 只追加一条约定: 发现精妙的代码, 请对应赞扬
    • 然后, 提供工具, 自动统计这种饱含同级以上智慧的 commit comments
    • 永久在社区公开统计成果, 年度排名
• 这样, 其实就形成了 stackoverflow 一样的贡献值体系
  • 无论是发布代码, 还是发现代码好点
  • 这两种行为都要求对等的工程能力
  • 而, 这两种行为方, 平时, 也都需要这种认同和实践
• 进一步的:
  • 定期将收集起来的 叫好点 收集分类,
  • 将其中经常出现的 好点 作者邀请来公开演讲分享对应技巧
  • 这样结合了具体案例以及社区公开 叫好 的分享, 就比念别人 PPT 的分享来的感人的多
• 再进一步的, 这种分享多了, 也就自然可以整理变成图书持续出版:
  • 不得不叫好的代码系列
  • 结合对应社区, 也是一系列可以拓展到工程/产品/组织/运营/..的自然故事
  • 远比平常要反常创造出术语来自行强行解释的创立点分享来的靠谱的多

          _~`-~~_
      () /  ♡ ◶  \ \/
        '_   ⩌   _'
        | '--∽--' /

...act by ferris-actor v0.2.4 (built on 23.0303.201916)

|> 241220 日糟:
1/4(每天吐糟不应超过4次)