写点什么

6 年开发者社区工作经历,聊聊我眼中的社区、开源与商业

2021 年 7 月 22 日

6年开发者社区工作经历,聊聊我眼中的社区、开源与商业

这可以是一个用爱发电开始的故事,但不应该是一个只靠用爱发电的故事。

1 一个从社区开始的故事

1.1 我为什么一直在社区工作?

过去的 6 年间,我一直在开发者社区工作。从 InfoQ 到掘金,这 6 年的时间遇见过太多形形色色的开发者和技术专家,又跟各个大厂的市场、公关同学建立起了深厚的友谊,这是我这几年最宝贵的一笔财富。


今年 2 月份我选择了裸辞,按说一个年近 30,还着房贷房租,还在装修这个无底洞里往外爬的我,是不应该有这个裸辞的底气的。但我的确就是这么普通却自信,这个自信来源于我的一个认知:


这是技术最好的时代,这是开发者最好的时代,这也是做开发者关系/运营人员最好的时代。


在这样的背景下,我也算是见证了中国开发者社区的飞速发展期。


  • 从第三方开发者社区的角度看,CSDN、InfoQ、51CTO、思否、掘金,这些或老牌或新兴的开发者社区,其发展势头都非常迅猛,新兴社区甚至有了赶超之势。


  • 从企业自建开发者社区的角度看,无论是云栖社区、云加社区、华为开发者社区这些有所积累的老牌社区,还是互联网新贵们的另起炉灶,都让社区这个概念更加深入人心。


  • 从开源、基金会的角度看,Linux 基金会、CNCF 在国内扩张迅猛,本土的 Gitee、木兰协议、开放原子开源基金会也都开始成长起来。


这一切的变化,最后还是追溯回上面的那句话——这是技术最好的时代。庆幸的是,我这样一个文科生也能在这波浪潮里搭上顺风车,吃到所谓时代的红利。


社区的发展,固然超出了很多人的预料,也让很多没有想明白为什么要做社区的互联网大厂开始跟风做起了社区。但真要让我说一声做社区的感受是怎样的,可能千言万语最后只能汇成一句话—— 用爱发电

1.2 社区为什么苦?

当我 2 月份选择换工作时,许多人给我的建议是:你需要去离业务(钱)最近的地方。我换工作的其中一个原因,恰恰也是觉得自己到了需要有所转变甚至转型的时候。


我也的确是朝着这个方向去找的工作,几家头部云厂商的市场部门我都有去接触,也拿到了 offer,但最终还是选择了留在开发者社区,这背后的故事弯弯绕绕,一时半会儿说不清楚,也许等过两年我可以更清楚地梳理自己的这段工作经历。但有一点可以肯定的,就是做社区真的太苦了。


一方面我们这个类型的人才确实受到了大厂的青睐,但另一方面很多时候我们也并不能准确且有说服力地解释自己的价值。这个行业的同行们,很少成为冤家,更多情况是在一起报团取暖,互诉(相)衷(吐)肠(槽)。


基于开发者社区“用爱发电”这样的现状,我们往往很难说服老板这个事情背后能够产生哪些业务上的价值,更别提能搞到多少的预算做出多少的成绩,KPI 很重,ROI 很低,所以能做好开发者社区运营的同学,往往 PPT 都写得很好……


对于开发者社区本身来说,同样有着各种各样的问题。我们很难说服老板承认开发者运营的价值,社区老板又何尝能说服他的老板开发者社区的价值?我已经见过太多社区老板被撤换,甚至整个社区被砍掉的惨剧了。


大多数的开发者社区离业务都太远了,其本身定位往往就是一个支持部门,说得好听点可能套上个“中台”部门的称号,但实际上就是个打杂的。业务部门未必认可社区的价值,社区本身也很难得到业务部门的支持——你不赚钱你还那么多穷讲究?边儿凉快去吧。

1.3 什么样的企业真正需要开发者社区?

在我看来,其实只有两种类型的企业对开发者社区有强需求:


一类是头部云厂商,另一类是开源企业。


对前者而言,开发者社区更多是对云产品潜在客户的培育。我之前看到过一篇报道,里面有数据显示企业内的技术采购决策已经开始有自下而上的趋势,如果云厂商能建立良好的开发者群众基础,对其云服务的转化的确有帮助。对于那些规模更小的云厂商,做垂直的开源项目社区更合理,比如青云的 KubeSphere。对于那些刚起家但雄心勃勃的云厂商,更多考虑的仍旧是头部客户的业务转化而非开发者群众基础,比如字节跳动的火山引擎


对后者而言,开源和开发者社区本身就是先天性契合的最佳拍档。开源企业的最终客户、项目优化、迭代以及未来走向,无不直接与开发者社区形成关系。因此开源企业往往从一开始就有对于开发者社区的强需求,这个需求一方面是自建社区,另一方面也是在其他第三方社区中强化品牌认知、影响开发者心智。代表的开源企业不胜枚举,比如 PingCAP、涛思、Kyligence 等等

2 从社区到开源

2.1 社区和开源的先天关联性

前文已经零零总总地提到了社区和开源的关系,这里展开再深入聊聊。


社区的概念应该早于开源,但社区的膨胀,却离不开开源文化的兴起,这很好理解。当我们回顾软件开发行业的发展,可以清晰地发现闭源商业软件时期和自由软件、开源运动时期的速度差异。前者以办公软件为代表,十年一变。后者以开源软件为代表,一举超过硬件行业摩尔定律的创新周期,让硬件的更新变成了“挤牙膏”式的(当然硬件创新变慢不只是跟软件有关系)。


在这个过程里,社区起到了怎样的作用?我们可以看下 Linux 社区的发展历程。在 Linux 被开发出来之前,所有人都认为,如果软件复杂到操作系统这样的程度,就必须要有一个精心协作的团队,团队要比较小,而且紧密互动。在 Linux 被开发出来之后,整个行业震惊于 Linux 的开发模式:仅通过互联网合作,聚合大量的社区志愿者,通过每周发布,快速获取海量用户反馈,继续协作开发、优化再发布。


然后 Linux 成了,社区模式也立住了。直到今天,开源软件吞噬了整个互联网世界。

2.2 开源到底是一门主义还是生意?

不管是开源运动,还是再之前的自由软件运动,其实最开始都是一个由情怀驱动的故事。这个情怀源自于工程师的“原教旨主义”,相信技术、开放真的能够改变世界。事实也的确如此,开源开放让整个互联网世界的边界前所未有地扩展,社区的概念缩短了物理的概念,"Community over code" 成为了大家信奉的准则。


可从最近几年起,开源、社区蓬勃发展之下,也有了“阴影”的伴生。亦或者可以说,这个论题是开源模式下永恒的争论—— 开源 VS 商业


去年我在华为 HC 大会上正好主持过这样一个圆桌,辩题就是「开源和商业的相爱相杀」。这个辩题的背景,也是基于这样的一个现状——云厂商和开源厂商之间的矛盾开始变得直接且激烈。



比如 MongoDB、Redis 对云厂商(AWS)的实名 diss,比如 Elasticsearch 更改开源协议防止云厂商白嫖,比如各个云厂商被爆出剽窃客户开源项目等等。甚至前一阵我还看到了一个专门的协议,名字就叫做「禁止云厂商协议」(英文名不记得了)。


前几年我曾在 InfoQ 写过一篇文章叫「开源软件盈利难,趁早卖身是正道」。当时我感叹的是开源企业纷纷被收购,或者陷入资金危机,比如 Docker 被下载超过 800 亿次,母公司却差点死了。


你不得不承认,开源的理念很伟大,但开源企业却很少有活得很滋润的。很多人总喜欢拿出 Red Hat 来驳斥这个观点,却忘了只能举出 Red Hat 这个案例本身就是对这个观点的一个佐证。


幸运的是,开源行业有一个 Red Hat,不幸的是,开源行业只有一个 Red Hat。


但事情慢慢在发生变化。云厂商和开源企业的关系,终究是在慢慢趋向合作或者竞合的。


事实就是如此,开源吞噬了软件,云吞噬了开源,某种程度上我们可以认为,云是更高级别的商业模式。不管愿不愿意,背不背离初心,开源终究是要跟云相向而行的。

3 商业化好吗?不好吗?

3.1 用户的声音有时候未必对

当一个社区,或者开源项目提出自己要走向商业化的时候,反对的声音一定不会小,而且这个声音一定是来自于自己的用户。


我之前在 InfoQ 的时候就发现了这样的现状:


绝大多数 Say No 的用户,未必是你的忠实用户。他只是把你当成一个免费的资源渠道,把你的一切付出视为理所应当,社区的就应该是开源的,开源的就必须是免费的,这是他们的朴素逻辑。


说得直白一点,伸手党们不会在你身上花一分钱,还觉得自己是你爹。


这就是做社区的真实现状——我在你社区里是看得起你,你不要不识抬举。更可悲的是,往往这类用户的声音是最多的,如果你没有上佳的心理素质和判断力,你会开始怀疑人生,怀疑自己用爱发的电喂了狗。


他们的反馈是用户的声音吗?是。他们的声音是对的吗?未必。


当你试图为了满足这些用户的观点去做一些需求时,你就会发现也许自己反而影响到了更多的用户。这也是为什么开源社区里会有「仁慈的独裁者」的管理模式,也是之前 React 项目组成员说不能提前透露重大的改进或功能的原因——你无法满足所有人,但你的一举一动都会影响很多人。

3.2 初心不改有多难?

我个人很佩服那些在一开始就说了我做社区、做开源是为了“用爱发电”的人。但我个人对成天把这些话挂在嘴边的人的成分表示怀疑。


就我的观察来看,一开始就为爱发电的人,最后都饿死了。希望你用爱发电下去的伸手党们,在发现你的死亡后,可能会对你表示一丝的哀悼,然后继续去另一个地方伸手。


真正的用户,应该是希望你活下去,然后给社区带来更多价值的用户。但可悲的是,这种人太少了。


这就是现状。


换一个角度想,也许这样的初心本身就是个错误。事实上我见过的很多明星开源项目,一开始都只是作者对自己每天遭遇问题的个人解决方案,项目流传开来则是因为作者遇到的问题成了一大类用户的典型问题。


他们做开源的初衷是为了解决自己的问题,而不是为了解决用户的问题。当发现这个同样的痛点以后,往往经历过前期的追捧以后,随着项目的逐渐壮大,会让这些作者感到痛苦,最后选择抽身而退,离开这个让他名动四方的项目。


很多国内的二极管们,一看到某某社区打广告了,某某项目做营销了,某某服务开始付费了,就开始聚在一起发光:


夭寿啦,你看他们开始割韭菜啦!没有一点互联网的分享精神啊!这个世界还能好吗?你们懂不懂什么叫开源开放啊?


二极管们的思维里,开源与商业是对立的,分享和营销是对立的,比如以前我运营 InfoQ 公众号,一篇技术分享的文章只要加了底部 banner 广告,那这篇文章就是为了打广告出的,而不是广告是内容的附加品,不看不会有任何影响。


其实我一开始也有这样的朴素情怀,这大抵是做内容出身的人最容易犯的臭毛病——假清高。我后来慢慢地意识到,商业运作是这个世界运转的正常规律,无视这个规律要求别人为爱发电的人才是道德绑架。


我从不否认做社区和开源的崇高价值,但在现实的环境下,吃饱饭似乎是更现实的选择。像 Richard Stallman 这样一年工作两个月就赚够钱,能把剩下十个月时间花在自己喜欢的方向上的人毕竟是极少数。


你不行,我更不行。


所以,我敬佩那些为爱发电的人,但我不希望他们的故事只是一个用爱发电的故事,我也不希望我们的媒体、同行去大肆宣传这些用爱发电的人。这个行业他就不应该被摆在一个过于清高的位置上。


我希望我们能在这个行业里为社区、开源做出很多贡献,也希望我们能在这样的工作里收获自己的物质价值和精神富足,如此而已。


本文转载自公众号小智的互联网观察(ID:hear_and_tell)。


原文链接


6年开发者社区工作经历,聊聊我眼中的社区、开源与商业

2021 年 7 月 22 日 21:031374

评论

发布
暂无评论
发现更多内容

架构师训练营第二周作业

Jerry Tse

极客大学架构师训练营 作业

架构师训练营 Week02 学习心得

极客大学架构师训练营

架构师训练营第二周命题作业

hifly

设计模式 极客大学架构师训练营 UML 依赖倒置原则 接口隔离原则

聊聊面向对象的设计(OOD)原则

Jerry Tse

极客大学架构师训练营 作业

什么是依赖倒置原则

老A

极客大学架构师训练营

打造个人品牌的意义

董一凡

发展 求职

第二周作业

晓雷

OOD四大原则

清风明月

架构师训练营第二周学习总结

王鑫龙

极客大学架构师训练营

架构师训练营-第二周学习总结

牛牛

学习 极客大学架构师训练营

0期架构Week2作业2

Nan Jiang

第2周总结

娄江国

极客大学架构师训练营

江帅帅:精通 Spring Boot 系列 06

古月木易

Spring Boot

因为知道了30+款在线工具,我的工作效率提升500%!

Hollis

第2周作业

娄江国

极客大学架构师训练营

架构师训练营第二周总结作业

兔狲

架构师训练营第0期-第2周-命题作业

极客大学架构师训练营

架构师课作业-第二周

Tulane

Lesson 2 软件设计原则 心得笔记

edd

最初的梦想

小天同学

写作 成长 梦想

week2作业

慢慢来的比较快

依赖倒置原则

互金从业者X

如何理解依赖倒置

丿淡忘

极客大学架构师训练营 依赖倒置原则

架构师训练营第二周作业

Geek_2dfa9a

架构师第二周

Tulane

江帅帅:精通 Spring Boot 系列 06

奈学教育

Spring Boot

不懂什么是锁?看看这篇你就明白了

cxuan

Java 并发

Python中的下划线

shiziwen

Python

架构师训练营——第二周总结

jiangnanage

第2周作业

sunpengjian

Week 02- 作业二:学习总结

dean

极客大学架构师训练营

6年开发者社区工作经历,聊聊我眼中的社区、开源与商业-InfoQ