《开发者关系 - 方法与实践》读书笔记 - 第一部分开发者关系的定位
最近没有写读书笔记的主要原因是在读另一本书《排名诡计》，只是读了一部分就让我对当前的各种排行榜和排名有了一个新的认知，推荐大家去翻一翻。上一篇读书笔记在老崔的公众号发布后，他截屏发到群里面竟然有人在催更，这比公众号广告挣到 0.7 元分成更让我震惊，真的有人在读这些无聊的东西么？ 和老崔交流后的总结是 “中年人最健康的变态方式就是抽烟喝酒骂街“。
这次竟然不是在差旅的途中读书，着实是一个好习惯的开始。
这次阅读的是第一部分第 2 章 - 开发者关系的定位，通读下来觉得这里所说的开发者关系定位，只是指在一个企业中开发者关系的业务归属，汇报层级和部门之间合作的方式等等。
产品部门通常将关注点放在消费者需求上，以提供出色的产品体验为目标。一般而言，从产品走进市场的那一刻开始就以为着产品部门的使命已经达成。但开发者关系并非如此。
就像之前说的，这本书开始并没有把所说企业情况讲清楚，猜测作者的角度默认是一个非 IT 类的产品研发型企业，即使如此我也十分不同意产品上市就是产品部门的使命完成。这不是应该产品部门（经理）端到端（潮流点的词叫 E2E ）负责，直到产品不再生产下市么？我理解产品全生命周期都应该是产品部门负责，或者有产品经理从始至终的跟到结束。开发者关系的周期应该和产品的生命周期绑定在一起，生命周期我觉得应该稍长于产品的生命周期，或者延续到下一个接替的产品。
如果是我写这本书，我可能会把和开发者关系有关的企业做个分类，通过不同分类分析不同的开发者关系定位，譬如 SaaS、PaaS、IaaS、小程序等等吧。另外开发者关系的定位，我想应该是分析不同类型产品和开发者关系的关系，关注背后的商业逻辑。所以书中的 “开发者关系活动的背后涉及许多商业行为，仅仅关注产品是远远不够的” 这句我觉得是对的，只是在一个公司内如何定位，我个人认为完全取决于领导层对这个事情的认知。也有些人喜欢讲什么要教育领导层如何认知开源或开发者关系，要向上管理云云，至少在中国企业文化中，这完全是痴人说梦。哪个公司的领导如果能把这个事儿放在台面上，都不用说放在心上，中国早就会出现一些受人尊敬的软件公司了。
市场营销部门通常认为开发者关系和传统的 B2B（Business-to-Business， 企业对企业）/ B2C （Business-to-Consumer，企业对消费者）营销部门活动非常类似。他们认为，传统的市场营销方法同样适用于开发者关系。但实际上，开发者是一类特殊的消费者群体，需要用全新的视角去了解。
所以国内很多公司，关于开源运营工作大部分是由 Marketing 部门来负责，采用的手段就比较传统。买渠道扩大宣传，搞案例做行业会议，请院士请政府领导站台，胁迫合作伙伴造势，这一套在涉及现在所谓“信创”相关的国产开源项目是相当的好使，只要砸钱够多，就能营造出一个开源项目生态蓬勃的景象。不知道请个院士出场的车马费是多少钱，开大会拼院士已经是个 Fashion 了，至于谁是开发者，到底是谁在用反正 Marketing 出个报告就行，搞个白皮书几十万花的相当值。当然这个策略在公司角度是没啥问题，因为国内真正付钱的甲方采购不看生态不看功能，看的是政策导向和采购要求。只是在这个循环中根本没有开发者，这也就是国内开源开发者关系的现状吧。没有哪个老板相信一个所谓开发者会议有上亿人观看直播，但是这个事儿也不能戳破，大家还是要一起讲故事。不用追去到底是什么 “全新” 视角，至少是一个还有开发者存在视角去了解开发者关系的定位吧。
社区运营部门通常认为开发者关系的工作 … 都是帮助对方解决问题，发挥他们的创造性，而不是让他们觉得自己是一个需要达成的业绩指标。
不知道国内公司有没有这样的运营部门，我猜大多数运营指标就是所谓社区有多少开发者，社区就是个论坛，没有论坛也要建个论坛，只要来注册的开发者就属于这个社区。管理者把 “拉新促活” 挂在嘴边，当然还有想把营收指标作为社区运营部门的 KPI 。这其实也不算懒政，是老板根本不认为社区运营部门有价值，在头上悬一个 “达摩克利斯之剑”，啥时候砍头祭旗就看老板啥时候需要借机整理职场。
这一章有一节是讲 开发者关系的汇报结构 ，内容上找不到什么有价值的文字，这里只说一下我观察到的国内开源开发者关系的汇报结构现状。
- 有一种最简单的管理方式是产品团队有专人负责开发者关系，向产品团队的领导进行汇报。这种模式多见于创业公司，创业项目多是一个领域内的解决方案，开发者关系相对比较好，是他们开源项目的用户。
- 有一种比较松散的管理方式是在公司内成立开源委员会，这样公司的一些共性是公司的管理层中有 1 ～2 位级别比较高的领导对于开源是认可的，但是还找不到开源和公司业务结合的最佳方式，希望通过一个松散的开源委员会让公司的开发环境相对开放。委员会汇报给对于认可开源的高层领导，是一个融洽的管理关系。但真正的开发者关系工作如何在开源项目中得到重视和推动，一个委员会是远远不够。
- 有一种比较复杂的管理方式是成立 OSPO （Open Source Program Office） 。如果公司的 OSPO 只管理内部使用开源，这个公司多半于担心对外贸易的过程中是否会受到合规威胁，希望通过 OSPO 来提升内部使用开源的合规能力提升产品的竞争力；如果这个公司 OSPO 同时管理外部开源，那这个公司多半是有个什么矩阵管理体系，OSPO 的工作处在复杂的内部利益斗争中，可能都自身难保，更何况开发者关系什么定位了，工作也就只剩下汇报这件事儿了。
这章最后的 “开发者关系测试” 我觉得是非常有用，用来判断是否和开发者关系的工作有关：
我是否在开发者关系关系的领域工作？
- > 你是否以开发者为主要的目标受众？
- > 你的战略和战术是否旨在影响开发者的行为？
- > 你的成果是否取决于开发者？
开发者关系的定位，应该思考的是开发者和公司商业价值的关系，而不是汇报的关系。当然手册还是要当手册来读，这手册后面多半也不讲如何实现价值。目前看前两章可以形容为外企开发者关系厚黑学手册，其实实话实说就好了，老外就是喜欢玩政治正确。
文章评论，请到 Craft 链接