首页 > 其他分享 >StoneDB首席架构师李浩受邀采访:浅谈KPI与开源的可持续发展,认可长期主义很重要

StoneDB首席架构师李浩受邀采访:浅谈KPI与开源的可持续发展,认可长期主义很重要

时间:2023-08-22 14:35:49浏览次数:37  
标签:李浩 社区 浅谈 项目 指标 开源 开发者 StoneDB KPI

编者荐语: <br> StoneDB 开源社区PMC、首席架构师李浩老师近期接受了 ITPUB 的采访,本文是对众多采访嘉宾的汇编,李浩老师对 KPI 与开源提出了独特见解,推荐大家阅读。 <br> 以下文章来源于ITPUB ,作者李雪薇

image.png 近年来,全球开源生态迈向高速发展的崭新阶段,很多企业、社区和个人都将关注点聚焦在开源之上。其中,有些企业、社区和个人更是为开源成立专门的组织机构,抑或是给开源设定KPI指标,意在推动开源项目或开源社区的可持续发展。 <br> 当开源与KPI挂钩,结果有时会出人意料。一方面,某些开源社区或者技术大牛通过在开源项目中设定KPI,获得了广泛的关注和支持;另一方面,某些公司主管为了个人的职位晋升,盲目追求KPI指标,而开发了一个毫无使用价值的开源项目,显然有违开源精神。

<br>image.png ::: hljs-center

图片来源于:互联网坊间八卦

::: KPI既可以促进开源的飞速发展,又可以让开源停滞不前,陷入缓慢的沉寂期。自此,人们开始思考:使用KPI的方式来运营开源项目或社区,能否带来可持续发展?一个好的开源项目的KPI指标是什么?用户和开发者对于开源项目设置KPI有何看法?企业或组织如何推动开源项目的持续发展,并避免KPI开源的变味走向? <br> 显然,开源项目和社区的成功不仅取决于技术实力,还取决于诸多因素,比如可持续发展。为了实现开源项目的可持续发展,需要确保项目对于个人、企业乃至市场具有一定的使用价值,并且可以留存用户和开发者。KPI指标应该能够衡量项目的质量、用户满意度、社区贡献度、以及用户和开发者参与度等方面,而不是单纯追求数量上的增长。 <br> 对于企业或组织而言,推动开源项目的持续发展需要注意规避“KPI开源”的变味走向。他们应该注重开源项目的使用价值和社区贡献,鼓励开发者和用户参与其中,以确保项目的可持续发展。归根结底,开源项目的成功需要开发者、用户、企业和组织等各方的共同努力,方能实现真正的可持续发展。 <br> image.png ::: hljs-center

业界如何看待KPI开源?

::: 在开源生态持续繁荣的今天,很多公司和组织为了鼓励员工为开源做贡献,会将开源项目相关的指标列入到KPI考核中。二者相互关联,形成了一种考核形式,甚至演变成了一种模式——KPI开源。它坚持“要什么考什么”,具有计划性、系统性,是推动公司开源项目价值创造的驱动因素,其核心思想在于不断提升组织和员工绩效。 <br> KPI开源是一种现象而不是原因,它具有一定的必然性,并且备受争议。对于KPI开源,不同人可能有不同的看法。 <br> 支持者认为,通过采用KPI开源的方法,可以更好地了解和评估开源项目及社区的表现和可持续性,有助于促进项目或社区的成功和发展。 <br> SphereEx联合创始人&CTO潘娟表示,“从开源项目角度出发,KPI开源主要围绕项目质量进行目标制定和衡量;从开源社区角度来看,可以将KPI开源解释成一种运营管理策略,来构建活跃或健康的社区。” <br> “指标是有价值的。”开源社理事兼执行长、前华为开源能力中心开源专家庄表伟指出,“我们应该研究指标,开发指标,推广指标,并希望能够在行业内,形成对于一些关键指标的共识。对于特别容易‘买到’的短期指标,我们需要通过塑造影响力,让大家降低对这些指标的看重。” <br> 白鲸开源联合创始人代立冬也并不反对为开源项目设定KPI,他认为,“很多个人开源作者都是为爱发电,很难坚持 3 年之久,而相反 KPI 开源有起码的各种保障,比为爱发电要靠谱得多。” <br> Apache SkyWalking & Apache ShardingSphere 核心贡献者高洪涛表达了他的期望,“我们希望与真正执行者共同制定KPI,而非从上到下委派任务,共同确认与互动才是 KPI 开源的核心本质。在 KPI 激励体制帮助下,全球开源项目能取得长足进展。” <br> 批评者认为,KPI开源带来了一些负面影响。 <br> 例如,某些组织可能会过度关注指标的增长,而忽略了项目或社区的实际价值和质量。还有一部分人认为,KPI开源可能会增加项目或社区的竞争性,导致开发者和社区成员过度关注指标而忽略了项目本身的长远发展价值,比如创新、协作和知识共享。 <br> 为了开源而开源,参与者没有什么乐趣,也无法形成内在的驱动力。笔者采访了StoneDB开源社区PMC、首席架构师李浩,他认为,“从以往情况来看,很多被迫进行KPI开源的行为,最终的结果通常都不是很理想,要么‘年久失修,无人维护’,要么‘门可罗雀’社区参与感不强。” <br> 诚如李浩所言,当KPI开源发展到了一定阶段,部分开源项目和开源社区中就会涌现出一些乱象,比如:部分管理人员为了职位晋升而盲目制定KPI,GitHub有偿刷星活动等等,某些电商平台甚至还出现了付费刷Star的灰色产业链。在所有KPI开源的案例中,我们都能够发现以下特征:数值化,短期化,忽略社区成员的体验。 <br> 前端社区知名专家、《重学前端》专栏作者程劭非对KPI开源嗤之以鼻,他表示,“KPI项目多数是公司某些不懂技术的领导动了心思,觉得开源有公关意义,得投入资源大力搞。然而开源是长期投入的一件事,前期大量资源的投入,在公关稿的热度过去之后必然要抽离,狂欢之后就只剩一地鸡毛。” <br> 在知乎上,KPI开源也被众多公司职员所诟病,我们摘取了部分热评。某匿名用户透露到,“在开源项目的实际投入过程中,有点‘鸡生蛋、蛋生鸡’的循环。想要发力做开源,老板却不肯投入更多的资源,看不到快速增长的收入,就难有说服力。在执行上,也出现过很多短视操作,没有长远规划。”[1] <br> 也有一位知乎网友@Wang Xu表示,对于开源这样开放式结局的任务,绝对忌讳“KPI式管理”,它必须充分激发开源团队的创造力,应该明确OKR管理,根据目标分解要达到的关键结果,但考察的时候重点考察达到了什么结果,是否帮助实现目标,而非和设定的“关键结果”死磕。[1] <br> 更有甚者认为,上级是不会理会下属的死活,当公司达到一定的规模,一切“业绩”都需要虚假的项目和数据支撑;扯上KPI的主要原因应该是立项目的不单纯,团队业务不多的情况真的为了KPI没有问题也得制造问题,为了想痛点绞尽脑汁,最后晋升成功就再也不想维护了。[2] <br> 当然,关于KPI开源的话题,不仅有正反两方的观点,也有一些中立的态度。 有人认为,KPI开源是一个有用的方法,但需要合理使用和衡量,以确保它不会产生负面影响。合理的KPI可以给开源项目人员提供一个明确且可落地的目标,有利于大家统一思想,形成合力,更好地衡量和评估项目的绩效。 <br> 然而,不合理的KPI可能会导致开源项目过度注重指标和数据,忽略项目的本质和创造性,最终使整个开源团队转向“唯KPI论”,很多公司的高层管理人员却又往往被虚假的繁荣所蒙蔽,忽略了人而浮于事,造成资源浪费的问题,严重影响公司健康的发展。 <br> 总的来说,KPI开源既有正向价值,也有负面影响。它并不是一个非黑即白的问题,其最终效果取决于具体实施的方式和目的。组织或企业应该谨慎采用KPI开源方法,并根据实际情况进行调整和改进,以推动开源项目或社区的持续发展和成功。 <br> image.png ::: hljs-center

怎么规避KPI开源走调?

::: “开源项目如果失败了,根本不会是因为机器、网络或办公场地,它们死掉的唯一原因就是开发者们不再感兴趣了。”EricStevenRaymond在《大教堂与集市》中如是说。用户和开发者的参与度,决定着开源项目的生死。 <br> 基于开发者的真实需求,立足为其解决实际问题等角度,而非为了KPI而KPI,为了KPI而搞开源。那么,企业或组织应该如何做项目,使其能够可持续发展,又该如何规避KPI开源的走调问题? <br> 正所谓,罗马不是一天建成的,开源亦是如此。做开源项目的基本流程主要有三个方面。首先,需要明确一个切实可行的开源计划,关注一线生产用户的问题和诉求。其次,需要建立完备易用的知识库,方便后续新社区及时快速上手项目。重点关注解决方案和成功案例的建设,上下游生态,国产化等。 <br> 另外,在项目后期,可能会出现组织架构调整,项目核心人员的变动,组织对于项目的重视程度变化等诸多原因,导致项目无法进行的情况。如果项目已成功地由社区支撑,则不存在项目后续维护问题。但是如果社区不足以支撑,则需要一个体面的“临终”关怀,完善运行线上用户的过渡,维护等问题。 <br> 对此,StoneDB开源社区PMC、首席架构师李浩提出建议,“对于高层管理人员,需要认可开源项目对于组织和社会带来的价值,是一件值得长期坚持投入的事情。对于中层执行者,需要有一个正确的评价考核体系,认可其参与开源项目对于组织的贡献。最后,开源组织需要尊重每一个社区用户。” <br> 全方位推动开源项目的可持续发展,需要关注以下五个方面: <br> 确定评估指标:在KPI开源中,要定义或确定好评估指标。KPI指标需要更多的从服务社区和项目出发,尽量减少组织短期对利益的诉求。例如,KPI指标可以设定为:社区活跃度,Issue平均响应时间,Review的及时程度;外部贡献者的活跃程度;项目文档的完整程度和易读性,上下游生态整合度等。 <br> 保证项目质量:开源项目有价值、有质量是根基。一个对行业没有价值的开源项目,是无法持续发展的。KPI开源需要关注质量而非数量,这意味着更加关注代码的可读性、可维护性以及提高项目的稳定性和安全性,可以通过实施更严格的代码审查、自动化测试和持续集成等方式实现。 <br> 培养开源文化:组织需要培养开源文化和开源环境,真正做到“我为人人,人人为我”的原则,从而形成一个良性的正循环,减少开源项目被大企业“白嫖”这类事情发生。组织和个人需要认清开源这条路的艰辛程度,杜绝“一夜暴富”的心理和“杀鸡取卵”伤害社区的做法。 <br> 重视参与者体验:KPI开源应该更加关注项目的实际应用场景和用户需求,重视参与者体验,以确保项目的长期价值。如果用户或参与者热爱开源社区,将会推动项目不断发展。开发者和社区用户应该鼓励参与者积极回馈开源项目,将开源项目在实际生产使用过程中所遇到的问题及时改进,帮助社区其他用户避坑。 <br> 强调社区参与:从某种角度来看,开源社区就像一个微缩版的“国家或者社会”,大家在社会中具有社交和关联性。社区参与是保证开源项目长期维护和可持续性的重要因素,开源项目和社区之间应多建立联系,从而能形成一个完整的闭环,为大家提供完整的解决方案,做到1+1>2。 <br> image.png ::: hljs-center

写在最后

::: 毫无疑问,企业投入资金做开源是一件非常值得赞同的事情,通过一定手段考核开源项目也无可厚非。但是,企业应该看重开源项目的长期价值,避免以项目进度要求开源产品进度,忽略开源产品本质是创新,而不是劳动密集型工作。在组织和个人名利双收的同时,希望开源项目能够保持初心。 <br> 您如何看待KPI开源?欢迎大家热烈讨论。 <br> 参考资料:

[1]知乎:企业搞开源的程序员KPI怎么计算?https://www.zhihu.com/question/508045817

[2]知乎:美团离职员工公开揭发:KPI 开源项目,毫无使用价值https://zhuanlan.zhihu.com/p/102621178

::: hljs-right

作者:李雪薇

设计:Yeekin

责编:宇亭

:::

<br> 如果您对我们的源码感兴趣,欢迎到我们的 GitHub 代码仓库阅读查看,觉得不错记得点个 Star 哦~ StoneDB 代码仓库:https://github.com/stoneatom/stonedb StoneDB 社区官网:https://stonedb.io/

标签:李浩,社区,浅谈,项目,指标,开源,开发者,StoneDB,KPI
From: https://blog.51cto.com/u_15722181/7189592

相关文章

  • 浅谈煤矿井下电力监控系统的改造研究--安科瑞张田田
    摘要:当前我国很多煤矿企业在市场环境中发展越来越困难,同时随着煤矿企业运作成本的不断提高,进一步压缩了煤矿企业的利润空间,使很多煤矿企业都很难在复杂的市场环境中生存与发展。鉴于此,本文主要分析煤矿井下电力监控系统改造。关键词:电力监控系统;煤矿井下;改造;随着科技进步,以及煤......
  • 磨刀不误砍柴工,数据压缩,带来的可不止空间节省 | StoneDB数据库观察
    谈到数据仓库,必然都会涉及海量历史数据,但是对于历史数据有个共识,就是越近的数据访问频率越高,越久远的数据访问频率越低。作者 | 祁国辉编辑&设计|宇亭责编 | 韩  楠当历史数据访问频率低到一定程度,我们就会发现数据的存储成本和收益开始倒挂,存储数据有点得不......
  • 浅谈Angular模板指令:ng-template和ng-container的用法
    本篇文章带大家简单了解一下Angular模板的ng-template和ng-container指令,介绍一下ng-template和ng-container指令使用方法。ng-template指令简介ng-template是一个Angular结构型指令,用来渲染HTML。它永远不会直接显示出来。事实上,在渲染视图之前,Angular会把ng-template......
  • 哪篇论文宣布了 HTAP 数据库的诞生? StoneDB带您解读《A Common Database Approach for
    theme:condensed-night-purple开启掘金成长之旅!这是我参与「掘金日新计划·12月更文挑战」的第4天,点击查看活动详情本文是 StoneDB学术分享会专栏的第五篇,我们来分享一下HTAP学术界上比较经典的一篇论文《ACommonDatabaseApproachforOLTPandOLAPUsinganIn-M......
  • 主流开源分析引擎梳理,看看你最中意谁?| StoneDB数据库观察
    编者荐语:本文来自石原子合伙人祁国辉老师,主要对主流的开源分析引擎进行详尽的分析,干货满满,欢迎大家阅读学习。最近一段时间,我重新梳理了一下目前市面上主流的数据分析引擎,发现真是琳琅满目,令人眼花缭乱。静下心来花了两周时间横向看了一下,学习过程中,记了一些笔记,希望能够......
  • StoneDB 源码解读系列|Tianmu 引擎工具类模块源码详解(一)
    StoneDB源码解读系列文章正式开启,预计以周更的形式跟大家见面,请多多支持~本篇源码解读内容已进行直播分享,可在视频号观看直播回放,也可点击阅读原文跳转至B站观看回放视频。PPT内容可在社区论坛中查看下载:https://forum.stonedb.io/t/topic/89各个工具类属于Tianmu引擎......
  • 浅谈软件产品质量模型与软件测试的关联关系
    为什么软件测试人员需要深入理解软件产品质量模型?软件测试人员在测试产品的过程中,就像一面镜子,需要照出系统的面貌,提供开发者修改代码的依据。而这个照镜子的过程就是对质量对评估的过程,测试人员需要对有效的质量评估负责,那就要求测试人员能充分的理解产品质量的概念,那么测试人......
  • 浅谈性能分析
    浅谈性能分析2022年02月05日 数据库 评论1条 阅读1,855次 性能分析和优化是一个要求比较全面的工作,通常既要了解所分析的目标系统本身的设计和实现,也要对操作系统等底层基础设施有一定了解,同时需要掌握一些方法论以指导性能分析和优化工作。本文尝试根据个人这几年......
  • 浅谈敏捷开发的测试策略
    【摘要】随着敏捷和DevOps的出现,改变了传统的软件开发模式,与此同时测试也面临着不小的挑战,在敏捷开发模式下,短周期迭代交付模式意味着时间变短,拥抱变化意味着变更频繁,用户故事描述需求的方式意味着文档变少,全功能团队中意味着专门的测试人员变少。基于这样的情况,如何让测试也变得......
  • 浅谈架构
    1     引言    笔者从事架构师工作多年,发现虽然软件开发人员人人都知道架构,但架构真正做什么,确很少有人能说的清楚。    大部分普通开发人员所想到的架构是框架的搭建以及各种架构技术比如缓存、消息队列、多线程等等,笔者曾经面试过一个应聘架构师岗位的......