这次竟然不是在差旅的途中读书，着实是一个好习惯的开始。
这次阅读的是第一部分第 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 的工作处在复杂的内部利益斗争中，可能都自身难保，更何况开发者关系什么定位了，工作也就只剩下汇报这件事儿了。
这章最后的 “开发者关系测试” 我觉得是非常有用，用来判断是否和开发者关系的工作有关：
我是否在开发者关系的领域工作？
- 你是否以开发者为主要的目标受众？
- 你的战略和战术是否旨在影响开发者的行为？
- 你的成果是否取决于开发者？
开发者关系的定位，应该思考的是开发者和公司商业价值的关系，而不是汇报的关系。当然手册还是要当手册来读，这手册后面多半也不讲如何实现价值。目前看前两章可以形容为外企开发者关系厚黑学手册，其实实话实说就好了，老外就是喜欢玩政治正确。
