金色观察 | Anchor联合创始人：标准创新悖论 对web3有何启示

本文作者Michael Mignano 2015年作为联合创始人创立当今全球最大播客平台Anchor，后被Spotify收购，目前负责管理Spotify播客、直播及视频战略相关业务。Michael还是位活跃的天使投资人和顾问，接受其投资和建议指导的早期科技公司逾50家，发表于Variant Fund联合创始人Li Jin的substack，对基于开放协议和标准的web3或许有所启示。

标准，如播客的RSS，使新兴技术能够轻松地插入现有的生态系统，从而在信息时代广泛传播。但标准化最终是有代价的，创新也因此而受损。例如，这就是为什么播客格式在其20年的历史中几乎停滞不前的原因。

技术标准是个极好的发明。标准帮助研发团队节省时间和成本，让他们使用通用语言实现产品间的相互交互，不必在同一个市场内分别研发各组件，也不必重新定义系统间该如何交互。例如，一个团队研发创建了一个新的邮件客户端，他们不需要重新发明格式以实现邮件在发送者和接收者之间的传输；他们只需采用SMTP（简单邮件传输协议，是定义邮件传输的标准），重点关注如何为用户打造极佳应用体验，不必顾虑其他。这意味着当有人想要做一件前人做过的事情，不需要再重新发明轮子——他们只需要采用标准，加速产品研发进程，抵达他们的受众——当产品与市场相契合——抵达用户的速度远比创建完全专有产品要快得多。

尽管基于标准的产品可以更快抵达受众，但较低的准入门槛意味着会有更多同类产品，导致市场分割，最终导致创新进程缓慢。有得必有失，我把这一所失称为标准创新悖论。下面我将做详细解释。

但首先……标准究竟是什么？

简单说，一项标准就是一个具体规格，决定某技术（硬件或软件）应如何与其他技术对话。标准通常是由社区研发的，经委员会共识核准和维护，委员会通常对所有人开放，人人都可参与做出贡献。HTTP（用于网络浏览）、SMTP（用于邮件传输）、RSS（用于内容聚合，例如博客或播客）或SMS（用于发送/接收短信）就是现代技术标准的典型。

标准化的好处

想要全面理解标准化为研发团队带来的好处，我们可以拿一个例子做解析说明。以应用于播客的RSS（简易信息聚合）为例。RSS早已成为播客的支柱，为创作者提供强大的分发机制，让创作者可以从一个单一端点发布音频并立即同步内容到任一想要接收此内容的消费平台。过去的20年里，通过定义一种通用语言，巨大的播客网络和播客收听app间可以相互交流，RSS让播客得以在开源互联网上蓬勃发展。若要通过RSS发布音频，创作者（或代表创作者的播客平台）必须使用具体格式发布播客，只包含此标准定义的参数，例如指向播客封面、选集列表等等的URL参数。

我曾长期从事RSS相关工作，作为合伙人创立了Anchor——一个播客创作平台，该平台于2019年被Spotify收购。Anchor让任何人在任何地点都可以轻松从iOS、安卓系统或者从他们的浏览器上发布播客，不需要有任何相关经验或技术知识。Anchor对创作者来说最神奇的一点要属它可通过RSS标准一键发布播客，所有播客收听平台都可以接收内容。这一强大的分发能力是Anchor得以急速增长的原因之一，最终让Anchor成为全球最大的播客平台。

我们创建Anchor帮助播客创作，RSS在其中确实居功至伟，同时，RSS也是播客消费端的有力工具。几乎世上所有现存的播客收听app（例如Apple的播客、Spotify、Overcast等）都支持基于RSS标准的播客。这样做有巨大好处：如果一个播客收听app应用此标准，就能立刻自动将当今所有播客展现给其用户。和我上面提到的电子邮件的例子类似，也就是说这些播客收听app可以把重心放在创造极佳的用户体验上，不必担心内容方面的问题；内容已经存在于开源互联网，可以让用户轻松收听。

得失权衡下的“失”

既然采用RSS标准让播客收听app不必重新发明在播客生态系统内的内容流动方式，从而节省了大量时间和金钱，这也就意味着为这些app找到听众的门槛降低了。结果就是，在长达20年的播客生态系统内有太多这样的app，导致市场分割加剧。如果你曾在App Store或Google Play应用商店搜索过某个播客app，你会看到大量的搜索结果。某种程度上说，这种市场分割对用户是有好处的，因为这意味着用户有海量选择，可以灵活使用产品收听播客。但与此同时，这种分割对创新是不利的，基于RSS标准进行应用体验创新几乎是不可能的，也就是说播客收听体验停滞不前，这么多年来几乎没什么发展变化。为什么？正如前面所说的，标准受共识驱动，驱动这些播客app底层语言的变革不会轻易发生。下面我们以规划度假为例，以便更好理解这一切。

家庭旅行

设想一下，你和你的另一半到一个之前没去过的国家共度为期两周的假期。因为只有你们两个人，在旅途中你们可以想做什么就做什么，不用顾虑太多。想要取消今天的晚餐预定去听音乐会？可以。明天不想参观博物馆了，想要租车去另一个城市转转？可以。

现在，再设想一下同样的旅程，但却不止你们两个人，还有你们的孩子，你们的父母，三个朋友，你的哥哥和嫂子，还有他们的四个孩子全都一起来了。这是一个完全不同的旅行，确实。在这个版本的旅行里，所有事都要认真计划。如果你决定改变一下行程，需要征求所有人同意，而那几乎是不可能的。这次旅行让你和许久未见的家人、朋友共度了愉快的时光，但因为这是个共识驱动的旅行，所以也就没那么有趣和独特了。

在一个大规模广泛应用的标准之上建造产品，正和这样的家庭旅行类似。一旦某个团队想要做些新鲜有趣的超越标准界限的事情，他们须让应用此标准的所有利益相关者一起做出改变，否则单方面的变化是无用的。并且，无论如何，一旦你突破标准做出改变，便会失去标准带来的诸多益处。让一群朋友和家人在旅行中改变行程计划已经够困难了，试想一下要和众多大大小小不同潜在竞争利益、不同性质的公司周璇该有多困难。这是基于标准研发建造面临的悖论。

标准创新悖论

标准创新悖论是产品团队基于标准研发建造新产品时面临的权衡结果；产品可以快速适应市场，为产品找到受众相对容易些，但由于市场惰性和基于共识驱动标准的研发，让创新终归于失败。如果且当一个团队在没有其他所有利益相关者支持的情况下决定为创新突破标准，标准带来的那些益处也就消失不见了。在一个生态系统里利益相关者越多，需要征得同意的人也就越多（所以，改变也就越困难）。

现在，设想一下在一个不基于统一标准的封闭的专有系统内研发建造产品。在从无到有的创建中，团队可以在他们认为适当的情况下自由实施、改变技术，不需要担心和他们不在一条战线上的其他利益相关者是否会买账。当然也有缺点，那就是研发成本更高，找到产品和市场的契合点也更具挑战性。然而，一旦这样的产品找到了与市场的契合点，便没有标准带来的天花板阻碍此团队加速创新发展的步伐。

标准创新悖论迫使团队在研发创建新产品的时候做出选择（应用标准可加速产品研发）：是应用标准，在现有的汪洋大海般的产品生态系统里获得即时的分发/可交互性利益（以牺牲未来创新为代价），还是从无到有研发创建产品，获得最终的灵活性和创新潜力（以牺牲融入现有受众为代价）？

播客（ Podcasts ）中的悖论

在我们早期用RSS标准创建Anchor的时候就面临了这样的悖论，那还是在我们被Spotify收购之前。对播客格式进行创新性的改变几乎是不可能的，因为其底层标准是几乎不可更改的RSS。

举个例子，比如我们想为每集播客添加一个评论区，在节目的RSS提要里实现评论功能。除非我们可以让市场上几百个播客收听app应用这一改变，不然评论功能是无法获得播客收听方支持的。没有这一支持，也就失去了让创作者应用、实施这一变化的动力，这个功能会立即以失败告终。

再举个例子，假设我们想打造一个内容更丰富更加动态的播客分析系统，可以让创作者更好了解他们的节目表现如何，从而通过现代互联网广告形式提高他们的收入潜力。除非我们可以让市场上几百个播客收听app全都应用所提议的改变，否则，要从收听方app获得更详实的数据反馈给播客发布平台是不可能的，创新也将失败。

RSS悖论多种多样，过去20年间导致了大量播客收听app的悲剧，很多欲打造不一样的播客app的尝试归于失败，因为整个生态系统是基于完全刚性不可变的标准。

短信（ Messaging ）中的悖论

SMS短信标准是另一个可说明基于标准研发带来局限性的例子。SMS标准于20世纪80年代诞生。大约10年后，在所有必要利益相关者都使用此标准后，SMS终于在1992年首次应用于移动电话，于1999年终于达到规模化应用（注意：标准被应用需要大量的共识）。自此，世界上任何地方的任何人都可以向另一个使用支持SMS移动电话的人发送短信，不管是哪款移动电话，来自哪个供应商。

然后，有人有个绝妙的想法，想给短信增加一个新功能：图片！如果可以用你的手机通过短信发送图片该有多棒？但是因为SMS是开源标准，图片功能不能被简单地用代码写进最新的软件更新里。标准本身必须做出改变才行，所有的手机生产商和运营商必须同意并应用这个变化才可以，当然，需要一个新的标准：MMS。所以，又差不多用了另一个十年，MMS才终具规模。

现在我们来看下Apple的专有信息服务iMessage，那根本就不是一个标准。iMessage之所以成功是因为有大群人快速接纳使用了一个虽然专有但却了不起的产品：iPhone。使用iMessage，必须先拥有一款Apple设备，比如一部iPhone手机，这当然是种退步。如果你用一个Apple设备向人发送信息，你会得到不断快速更新完善的服务。Apple在自己专有的生态系统里进行研发，得以快速创新信息收发体验，现在它的短信服务和SMS时代已大不相同。

回想一下iMessage这些年来的变化。早期的iMessage和SMS没有多大区别。但现在，它具有极其丰富的功能特性，比如已读回执、图片库、面部滤镜和Memojis、App应用商店、语音备忘录，等等，数不胜数。Snapchat、Messenger、WhatsApp等其他很多专有短信平台也是如此。这些平台能够达到这么高的创新水平和这么快的创新速度，唯一的办法就是在SMS标准之外进行研发创建（虽然，不可忽视的一点是牺牲掉了与其他系统的交互性，从而限制了潜在受众）。

Newsletters中的悖论

这里有一个更新鲜的例子。你很可能听说过有个很棒的Newslettes产品Substack。这是一个可以让创作者创建、存储并扩展其Newslettes业务的平台。Stubstack的妙处在于它应用了开源标准——驱动邮件传输的SMTP——可以轻松向所有电子邮箱用户分发Newslettes。

与上面播客的例子相反，任何应用RSS的平台都可以立即解决“鸡生蛋还是蛋生鸡”的供应侧问题，Substack的做法相反：它通过确保其所有消费者都能读取邮件内容来解决需求方问题。这真是个绝妙的策略，作为一个平台，它发展迅速，吸引了无数知名作者和付费订阅用户。

尽管应用SMTP可以即时向读者分发内容，这个方法也有其自身缺陷：邮件是静态的，只要邮件客户端受SMTP标准驱动，邮件将一直是静态的。这意味着Substack不能使用邮件做任何动态的事情，比如在邮件客户端将读者的探索体验实时个性化。或者，包含一个实时更新的动态评论区。再或者实施其他任何可以增强创作者或读者体验的功能特性，但这需要在邮件客户端里实现某种动态界面。就像上面播客的例子，要实现这些，需要互联网上大多数主要邮件客户端都应用Substack的创新。

所以最近他们有个非常聪明的举动，虽然鉴于标准的局限性，也许这个举动并不算惊人：他们推出了一款app，可以让他们在丰富的电子邮件新闻信经验之上进行扩展。在我看来，这么做很有道理。如果Substack可以成功扩展它的app，便可快速创新Newslettes体验，不再受制于SMTP标准。但是此举会牺牲掉开源标准带来的益处，他们最初正是凭借这些益处才开启了用户对他们的业务需求。

在我看来Substack似乎受困于标准创新悖论：继续在SMTP上进行研发，以受益于电子邮件的广泛应用？还是研发专有解决方案加速创新？随着其app的发布，我认为可明显看出Substack的选择是开始脱离标准。

打破魔咒

标准创新悖论的魔咒可能降临在任何一个快速发展想要创新的公司，但这个魔咒是可以打破的。实际上，有个办法可以让研发团队鱼与熊掌兼得，他们既可以获得标准带来的益处，又能突破标准进行创新。

利用专有系统的分发机制

一定时间后，所有应用规模化标准的产品最终提供的体验都会大致相同。这是因为他们能提供什么是有天花板的，天花板来自标准的不可更改的刚性本质。有越多的产品应用标准，市场惰性就会越大，改变也就越困难。这会带来激烈的竞争，不可能有任何一个产品会因为不同的体验破局而出。所以，这些产品要如何突破瓶颈，找到对其至关重要的规模化应用？它们需要借助其他非标准驱动市场内的产品。

还是以Spotify的播客业务为例。几年前，这个音频流媒体巨头从仅提供音乐服务发展为提供包括播客在内的各类音频。鉴于音乐和播客的内容和体验不同，很多人希望该公司可以发布一款专门收听播客的app，为用户提供与欣赏音乐完全不同的应用体验。然而，如果他们这么做了，就一定要和汪洋大海般的播客收听app竞争，因为它们受限于标准，为用户提供的功能大体都是相同的。对于Spotify播客app来说，要突破瓶颈是很困难的，就像对其他任一播客收听app一样。所以，Spotify利用其现有app上的现有音乐用户群体基础，向数亿用户分发播客。这样做使Spotify解除了悖论魔咒。

实现向后兼容

切记，用户喜欢使用基于标准的产品是因为这样一来他们的选择和数据是可移植的。如果一个基于标准的产品能突破市场分割的瓶颈脱颖而出，很重要的一点是要保留用户起初获得的标准带给他的益处，否则，就会冒着丢失用户、失去产品市场契合度的风险。最佳办法是确保与标准的向后兼容。以Apple的iMessage为例。如果你曾使用过iMessage，那你基本也一定用过安卓设备发送短信。注意到iMessage是怎样做的吗？iMessage复用SMS标准与短信接收方交互。这对双方用户来说都是最好的结局。对于使用Apple设备的你和你的朋友来说，你们可以享用一个创新专有平台的所有益处。但这些益处却不必牺牲掉基于开源标准的短信核心功能，因为你仍然可以通过SMS向安卓设备用户发送短信。

究竟要不要使用标准？

尽管存在标准创新悖论，但我们不能忽视过去几十年来标准化为技术成功带来的巨大好处。然而，基于标准研发创建一个新产品，权衡利弊总是很重要的，要考虑到在团队找到产品市场契合点后未来发展是否会受到标准创新悖论的阻碍。