编辑导语：开源理念很伟大，但开源企业活得滋润的却很少。究其原因，无外乎是开源项目商业化时，用户的反对声太大。那如何才能平衡好用户和商业化？开源项目商业成功受哪些因素影响呢？笔者给出了自己的看法，我们一起来了解一下吧。

2017年我写过一篇初创策略：开源技术商业化，因为这篇文章有好几家科研型公司都找到我，聊商业化难题。

写那篇文章的背景是与Apache Kylin的合作，对方希望我的一个咨询项目上采纳他们的产品，甲方公司年营收5000万，使用的传统Oracle BI无法解决业务量的问题，因而转向大数据解决方案。具体过程就是前文所述：

拥有开源产品和项目实施能力，但很难建立渠道接触目标客户，希望寻找渠道合作伙伴一起拓展市场。

分析发现，产品的定价策略不清晰，在同类产品中难以形成竞争力。

在要求B公司做好市场调查时，发现对目标客户没有定位，当前太过于依赖项目，也没有想清楚创建公司的目的和目标。

给出的建议是：不要紧盯某个客户或某个项目，在缺乏客户影响力的情况下很难拿到项目，也是浪费公司的精力。

先制定公司的目标，再制定合适的市场推广计划，建立客户关系，找到愿意选择自己的客户。

定价比产品还重要——这往往被技术人员忽略。对技术初创公司来说，虽然拥有新技术，但并没有建立起市场品牌和销售网络，在竞争上尚处于弱势。合适的定价策略是：

1. 成本导向定价：通过对研发、销售、市场和其它经营管理成本进行核算，设定盈利目标和销售数量预测，进行产品定价。这种定价方式可以帮助公司搞清楚生存底线。
2. 顾客导向定价：调查目标客户的预算范围和潜在购买机率，进行产品定价。这种定价方式可以针对性地赢得项目。

我自己也是Kylin的早期用户，2013年就将这个框架推荐给了通信行业NO.2公司的大数据部门。

不久我就发现，两家头部银行的数据部门都采纳了Kylin，而且一家公司的高管对Kylin公司表示出相当狂热的态度——Kylin的真正客户群体是头部企业的专业技术人员，而且是技术高管，只有他们才能理解这个产品的技术水平与差异。

头部企业的数据部门更庞大、分工更细致，有足够多的重复性数据处理场景，正好Kylin构建了一个有别于当时侧重于非结构化、流式处理的互联网大数据技术方案，更聚焦结构化、BI应用特点的传统业务大数据方案，所以在这个空白的市场，快速商业化拿下头部客户。

中小科技公司反倒不是Kylin的用户，原因有两点：

1. 甲方自己的商业模式未经验证，不可能拿出百万的经费基于一个没有成熟商业方案的开源产品构建；
2. 中小企业使用场景复杂，需要综合性解决方案，比如在那个案例中，技术人员需要的是一个大规模运行机器学习算法的数据平台，并非单一的BI分析。

Kylin及不少开源项目的成功也引起了更多的技术人员、资本市场的追捧。我个人也是从 http://sourceforce.net的SugerCRM 起就长期关注开源以及商业化，总结了一些点供参考。

一、开源不是模式上照葫芦画瓢

大部分团队、投资机构对开源的理解停留在“开放源代码、社区协作”这种浅层模式的理解和复制上，以为把源代码放在GitHub上供大家Star，就是开源了。

开源项目的成功条件，是一个本来就已经成功的项目通过开放源代码的方式获得更多的用户和市场反馈，以满足更大的市场需求。

项目成功有两种条件：已经存在一个成功的商业闭源产品，或者在头部企业真实环境中投产运行多年的内部项目。

1. 商业模仿型开源

这种情况下，是市场上已经出现了一个成功商业化的闭源产品，但它的市场是特定的、有限的。

开源模式通过对这个成功商业化产品功能的模仿，通过社区协作开发、部份与商业化产品有竞争关系的头部企业捐赠贡献，最终形成一个高仿品，填补剩余市场空间，满足与商业化产品竞争的需要。

模仿型开源的本质是一种低成本竞争战略行为。

企业级市场的生态是复杂的，比如说AWS作为云计算领域最成功的商业闭源产品，它的传统竞争对手EMC、VMWare及新兴竞争对手Google、Microsft均不可能成为AWS的目标市场客户。

Google、Microsoft可以通过自己的海量访问、开发者生态工具的协同效应来研发自有的商业闭源产品，与AWS抗衡，而EMC、VMWare没有运营基数和粘性工具的情况下，就会采取开源作为竞争策略。

2. 生产力杠杆型开源

软件系统无论在互联网还是企业级，从测试框架到非功能型组件到架构脚手架、构建部署工具，其实存在非常多的共性问题及解决方案，比如说Mock、 Log、AOP、MVC、CICD等等，开源框架的影响力与价值与复用度、系统覆盖度成正比。

举个例子，Mock脚本的维护成本很高，仅覆盖测试环节，存在感和价值都比较低。

最好的策略就是创作者一次构建整个框架，交给社区维护，当好Commiter，借助项目影响力去大公司任职，就不会出现Faker.js的悲剧。

Spring Framework作为J2EE领域生命力最强、影响力最大的开源框架之一，就是因为AOP设计思想和对系统架构的高覆盖。

借助Spring Framework，普通程序员秒变架构师，无须深入理解设计原则，就能开发出对象生命周期管理规范的应用程序，这就是Spring Framework创造的开发者价值。

借助自动化工具，使过去一个运维人员最大限度能够维护6~8台服务器的部署工作，变成一个开发人员都可以兼顾数千个应用目标环境的部署，生产力指数级提升。

或者是Google Angular.js、Facebook React.js这些内部项目，解决前端数据绑定和跨PC移动开发，生产力也实现了成倍增长。

研究这些开源项目不难发现，它们都具备“生产力杠杆效应”，光有特定领域解决方案不行，还得有生产力杠杆，最好这个杠杆作用是已经被证明过的，而不是通过开源来证明。

二、开源商业化要尽早

对于商业价值尚未验证的新品类，在没有种子用户获得渠道的情况下，可以尝试通过开源社区获得第一批种子用户，并在发现有企业用户使用时，推出企业许可证和收费策略。

最好的案例就是Jira。

Jira的创业团队只有两个程序员，从推出到产品成为市场第一，都没有销售团队，依赖的就是开源社区免费扩散加企业用户授权许可证收费并存。这种策略是如何实现的呢？

1. 寻找目标用户交集

开源框架的核心团队、贡献者、参与者以及用户，与企业级市场非但不隔离，相反两者之间存在交集。

Jira的用户就有这样的一个特点，早期开源的核心团队几乎都是大企业的精英开发者。因此，Jira很容易将产品同时销售给企业级用户，无须额外的销售渠道。

给国内企业很好的借鉴意义，就是如果你的用户群体中存在着潜在的付费客户，产品驱动增长（PLG）就是一个高可行性的策略。

除Jira外，在新品类下尽早商业化成功的案例是前面提到的 Apache Kylin。

2. 利用细分市场头部效应

俗话说，创业公司的成长是“找到一个池塘，成为池塘中最大的那条鱼”，讲的就是细分市场头部效应，更学术的词汇叫企业家租金（Entrepreneurial Rents）——扣除投入的时间、精力、资源与不确定成本之后的剩余利润。

头部效应是新市场中很多创业公司，也包括一些开源公司重点争夺的目标。但它有两个前提条件：

1. 一家公司能够满足这个细分市场的需求总和；
2. 细分市场不存在头部，或现在的头部有可能失败或倒闭。

在新兴领域谁也不能确定以上两点时，所有的公司都会采取先发策略，以期得到头部效应的机会。

所以在各个新市场，普遍存在的现象就是过度竞争，只有少数公司能够正确判断市场是否已经达到饱和状态，并采取正确的下一步行动。

三、勿滥用规模

ToC领域消费者决策机制单一，相互影响力弱，因此，C端的产品、厂商也有海量化、弱连接、替代性强的特点。

比如一个用户大量时间都在刷短视频，那他就没有太多时间刷微博，新生代更喜欢刷视频，但影响不到中生代喜欢刷微博。

对每一个C端产品来说，都很难“多元化”，比如社交与电商的分界、图文与视频的分界，一种简单的解释，是用户行为切换成本。

换而言之：

• 用户很难在社交场合，突然开始买东西，或者在市场上，突然又开始社交连接；
• 安静看视频时，很难开始做深层文字输出（浅层弹幕除外）；
• 进行文字输出时，很难切换到视频设备场景和模式。

从用研角度，每一个产品最多只能有一种“独占模式”，作为用户的主交互界面，这就导致C端产品很难呈现出多元形态。

相互影响力和易变性弱的情况下，产品追求的就是规模效应，公司之间是规模的竞争。

而对企业级产品，特征是反过来的，操作复杂、集成复杂、生态复杂。致胜因素并不在规模。

胜兵先胜而后求战，败兵先战而后求胜。

评估一个开源项目的成败要素，文中也已经回答了：先成功，再开源，而不是先开源，再寻求成功。

#专栏作家#

陈加兴，微信公众号：加兴曰，人人都是产品经理专栏作家。陈加兴，场量科技创始人，研究领域：研发组织效能、数字平台、SaaS创业战略。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议