从开源项目构建产品的框架

这是一个将项目转变为商业开源产品的路线图。
116 位读者喜欢这篇文章。
Wright Brothers first flight via NASA

Opensource.com

我对电脑的最初记忆是在 90 年代初,通过祖父制药研究实验室的 x86 PC 上的 MS-DOS 终端玩游戏——玩存储在 3.5 英寸软盘上的游戏并进行盲打练习。随着技术的进步,我花了大量时间拆卸电脑,添加更多 RAM、新的显卡或新的风扇,主要是为了玩更酷的游戏。这是一个有趣的、持续进行的项目,我和父亲因此建立了深厚的感情。这也比买一台新电脑便宜得多。

在开源的背景下,这有什么意义呢?

嗯,即使当时我不知道“开源”是什么,我的行为也像今天典型的开发者对待开源项目一样——花我的空闲时间拼凑和构建我想要的东西,有时是为了一个特定的目标,有时是为了学习新事物,有时是为了与他人建立联系。

但是,随着时间的推移,我停止了修补。出于某种原因,我决定我的时间变得太“宝贵”了,不能再改装旧电脑。我开始使用 MacBook,当我的旧 MacBook 运行不佳时,我花了一大笔钱买了一台配置更好的新电脑,而不是拧开底部看看是否可以塞入新的 RAM 卡。

我的行为变得更像企业买家——通过花钱来节省时间和麻烦。

开源软件项目 不是你销售的产品

如果你的技术经验在任何方面与我的相似,你就会凭直觉知道,我们 DIY项目与我们花钱购买的产品不同。

这在开源社区中并不是一个新观点。

IT 行业资深人士,开放容器倡议的成员 Stephen Walli 就此主题撰写了 大量详细的博客文章。领导 Kubernetes 社区并深入参与 Nginx 和 MySQL 社区的 Sarah Novotny 在首届 Open Core Summit明确指出,公司管理的开源项目和公司销售的产品是两个完全不同的东西。

然而,商业开源软件 (COSS) 公司的维护者出身的创始人,尤其是在开源项目获得关注时(具有讽刺意味的是),仍然将项目和产品混为一谈。

我认为,这个错误会重复发生,因为当开源项目已经被广泛使用时,很难在脑海中概念化商业产品应该如何以及为何不同。

是什么让 COSS 产品与众不同?

两个核心要素将商业产品与其开源根源区分开来:打包的体验和买家特定的功能。

打包的体验

打包你的项目,使其具有开箱即用的用户体验,不仅仅是关于抛光的用户界面 (UI) 或将其作为 SaaS 托管在你的服务器上(尽管这可能是其中的一部分)。这表达了你,作为项目的创建者或维护者,公司创始人,你认为应该如何使用该技术来解决客户的业务问题。这种“观点”本质上是客户为之付费的产品体验。

当您运行开源社区项目时,通常最好持偏见,让您的社区自然而然地蓬勃发展。当您为客户开发产品时,通常最好主见。

这就是改装的 x86 PC 与 MacBook 之间的动态。

Hashicorp 首席执行官 Dave McJannet 和 Segment 首席执行官 Peter Reinhardt 都认为,打包是将开源项目转变为可扩展的商业产品的关键步骤。

买家特定的功能

一个包装完善的产品还必须具有您的目标买家证明购买合理的功能。这些功能是什么取决于买家的概况,但可能性是有限且可管理的。

企业买家,例如全球 2000 强企业,将拥有一套相对一致的功能,这些功能是他们购买产品所必须具备的。(EnterpriseReady.io 是一个关于这些功能通常是什么的很好的资源。)

中小型企业买家,例如您当地的夫妻面包店,他们的财务资源和人力较少,并且对价格更敏感,需要不同的东西才能被说服购买。

通过广告获利的消费者服务,其中您的买家是广告商,而您的用户是普通人,情况仍然会有所不同。

可以肯定的是:您的买家几乎永远不是您的开源社区。

了解您的买家购买所需的东西,并将其与您关于如何解决买家问题的专家意见打包在一起;这就是产品与项目的区别。

Sid Sijbrandij 对 GitLab 的 基于买家的开放核心 模型的阐述是企业的一个很好的例子。

当然,可以添加其他元素以进一步区分。但是,具有买家特定功能的打包体验至关重要。如果没有其中之一,您的潜在客户还不如自己免费进行修补。

一个重要的指标:价值实现时间

在产品开发中,一个长期存在的难题是衡量进度并建立一个数据驱动的框架,以确定您是否走在正确的道路上。我喜欢“一个重要的指标 (OMTM)”的心态,在 精益分析 中对此进行了详细阐述,您在当前阶段只关注一个数字(高于一切)。这种方法在您可以收集并分散自己注意力的大量数据(通常是虚荣指标,如下载量或 GitHub 星星)中强制执行专注和纪律。这个单一的指标可以有效地将您的整个公司团结在一个有形的目标或使命周围——这对于一家早期公司尤为重要。而且您关注的指标在不同阶段会有所不同。

那么在产品开发的早期,正确的 OMTM 是什么?

我建议使用价值实现时间

这里的“时间”很简单——越低越好。

“价值”需要一个精确、严谨的定义,该定义是特定于技术和问题的。您的分布式数据库之所以有价值,是因为它可以在服务器发生故障时提供数据而不会停机。您的持续集成工具之所以有价值,是因为它使应用程序开发人员能够更快地推送改进,而不会破坏应用程序。您明白我的意思了。

客户能多快看到或感受到您衡量和优化的一个核心价值?什么是“足够短的时间”取决于用例,但鉴于企业技术日益消费者化,任何产品的价值实现时间超过 30 分钟可能都太长了。

找到并严格定义“价值”是困难且迭代的,但如果您希望围绕开源项目建立一家产品公司,这也是基本要求。如果您不深入了解客户的价值是什么,可能就没什么公司可以建立的。

归根结底,尽管“增强”我的 x86 PC 很有趣,但我对我的 MacBook 非常满意,并且乐于支付溢价。因此,如果您的目标实际上是销售 MacBook,请不要太沉迷于修补的乐趣。

(附注:如果您正在建立一家为开源项目用户提供服务的咨询或支持型公司,那么此处概述的思维框架可能不适用。有关不同 COSS 商业模型的更广泛阅读,请参阅 Joseph Jacks 的 COSS 商业模型演进。)

特别感谢 Sarah Novotny 对本文草稿的反馈。


本文先前已在 COSS Media 上发布,并经许可编辑和重新发布。

接下来阅读
标签
User profile image.
Kevin 目前是 OSS Capital 的常驻企业家。他每周在 Interconnected 上撰写关于更广泛的技术行业的文章。他曾任 PingCAP 全球战略和运营总经理,PingCAP 是一家 NewSQL 数据库 TiDB 背后的商业开源公司。

评论已关闭。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.