编者按：平台是个大生意。看看苹果、微软、谷歌、Meta、亚马逊等，无一不是平台，且很多都是万亿美元级的企业。但究竟什么是平台？平台的经济学是什么样的？平台可以划分为哪些模型？为什么很多平台推出的时候会失败？有没有平台护城河这个东西？关于平台的这种种疑问，可以在这篇平台终极指南里找到答案。文章来自编译。
产品开发的重中之重是打造平台。我之所以说是重中之重，是因为总的来说，创建平台对于大多数产品来说都难以捉摸，至少在我们想到平台（Windows、iPhone、AdWords 等）时往往会想到的那种规模来说是这样的。实际上，当我们环顾四周时，看看那些以客户和第三方的身份对平台下注的人，最终通过平台获得了巨大经济效益与收益的例子比比皆是。
虽然我们都很想建立一个技术平台，但却缺乏共同的分类法或定义。一旦我们有了这个定义，我们就可以研究平台兴衰沉浮的模式。
本文的组织结构如下：
什么是技术平台？
关于经济学的注释……
平台的模型
关于粘性/转换成本的注释……
为什么平台在推出时会失败？
关于未能考虑到所有的 4P 的注释……
为什么平台能成功？
关于平台护城河的注释……
平台的生命周期
什么是技术平台？
平台最简单的定义是属于技术的一种，这种技术可以作为他人成功的要素，但这种技术本身非常重要，重要到它自己也获得了认可和市场地位。这个市场地位让很多人也想提供同样的完整产品或服务，但大多数，或者甚至所有这些终端产品或服务所依赖的核心要素（虽然不算什么秘密），却是由该平台定义的。
我们把讨论限制在相对现代的业务上，最早采取平台战略的例子之一当属通用汽车 (GM)，他们设计了汽车产品线。1950 年代及之后，在通用汽车内部，一开始为了提高供应链采购效率的做法演变成了一种进入市场的策略。通过依靠汽车的通用组件以及其他子系统，同时在品牌和选项选择上进行差异化，通过针对特定客户群做出针对性调整的汽车，通用汽车制造出一种为更多客户提供服务的错觉。这最终导致了基于通用平台的独立业务，比方说，大黄蜂（Camaro）、火鸟（Firebird） 和 Trans-Am 这几款车其实差不多是一样的，但针对的客户却截然不同。在通用汽车平台上你可以找到一份令人大开眼界的汽车清单，从中可以了解该平台战略的进展情况。
当既有者（incumbent）取得成功之后，往往会故意将既有产品平台化（这是我说的），并试着一遍又一遍地重用既有产品。奥利奥饼干或好时巧克力会出现在超市的十几个不同的过道上。成分是高乐氏漂白剂的产品塞满了整个过道。从芭比娃娃到星球大战，在玩具和娱乐领域，我们看到了这些平台的扩展。因此，今天的迪士尼公司是平台战略的伟大执行者之一。
从历史上看，在软件领域，Windows 也有自己的平台战略尝试，那就是以 Win32 API 这个概念作为战略基础。Java 也是如此，虚拟机是一个广泛平台的核心。如果你有心扩展平台战略，那么这两个故事都值得借鉴。
Windows 的可扩展性——以卡通格式展示了每种类型的 Windows 计算机的示例。以微软的一张幻灯片作为例子，“Windows 可扩展性”展示了 Windows 平台从移动一路发展到服务器集群。图中可见，连手机、手持设备，甚至Wallet PC，以及高性能科学计算都曾有过Windows的身影。 （来源：个人）
虽然上述战略背后的东西值得称道，但你很难躲得过这个话题，那就是与建立相比，成功与否则要取决于执行。最有趣的平台的出现不是来自于既有者的刻意扩张，或者甚至是带着要成为平台的渴望而去开发产品。相反，最大以及最成功的平台都是从试着解决问题开始的。
关键是这个解决方案必须至少对一小部分人来说是显而易见的，而且要立竿见影。这一小群人未必就是我们所认为的开发者或软件开发者，也许就只是用户而已。
电子表格也许是最无处不在的现代生产力工具了，一开始电子表格似乎不是一个平台，而“只是一个应用”，甚至是“[平台] 的杀手级应用”，但绝对不是平台本身。随着时间的推移，电子表格添加了可编程的宏功能，甚至后来又加入了非常复杂的插件架构，需要专业编程能力才能用，但与仅使用电子表格相比，这些任务并不占主导地位。尽管如此，电子表格仍是一个平台。它是整个金融、咨询、科学以及更广泛的分析的基础组成部分，职场几乎所有类型的工作都离不开这个东西。如今，人们围绕电子表格设计工作流程，把它打造成了最终产品和服务。
有时候，一个平台会从某项内部技术（比方说通用汽车创建的技术）之中脱颖而出，从而独立成为一个新平台。Adobe PDF 代表着通往无处不在之旅。最早的时候，PDF 是从 Adobe 自己的 PostScript 格式衍生出来的，作为供出版商使用的平台的。面对将各种原生格式“转换”为这种格式的挑战，打印成 PDF 的想法最终形成了一种通用的文档查看格式。2008 年，Adobe 为这种格式提供了一个开放标准，从而巩固了它的普遍性，尽管因此放弃了大部分的获利性。现如今，PDF 已成为几乎每一项官方交易工作流的重要组成部分，并在几乎所有的工作流程当中都充当无纸化签名的基础。这是一个没有大规模平台经济的平台。这又给我们上了一课。
Web、HTTP 、 HTML 以及相关技术从一开始就是开放与免费平台的典型例子。它也应该是用例或场景比想象要多得多的平台的例子，相对于最初设想的作为在线共享文档的手段，这些技术后来的用例、场景要丰富多了。就像作为这些技术基础的核心互联网技术（即 TCP/IP、DNS等）一样，web 技术扩展和变形的能力确实非凡，从而支撑了更多的技术，并建立了我们这个时代的平台。这个平台提供了一个很好的经验教训，也就是架构原则的重要性，这些原则构成了健壮和持久的技术平台的基础。Unix 操作系统是经久不衰的平台架构选择的另一个例子。
鉴于有这么多独特的例子，对平台进行分类变得越来越困难。最有趣的是，要记住，平台是定义明确且有意为之的实体，并且通常将它们的成功归功于平台战略。但平台战略通常是通过观察产品的使用方式之后有机出现的战略，或者是非常严格的追溯构建的结果。大多数成功的平台都是从一系列场景开始的，这种成功导致将技术用到了甚至连发起者都没有想到的任务。在发生这种情况的同时，竞争对手的影响以及新技术的引入也会将平台推向了最初预期以外的方向。事实上，这种演变正是大多数成功平台的基本要素。
因此，对单个平台的任何描述都只能适用于某个时间点。平台的演变和管理变得比原始设计和模型更为重要。
关于经济学的注释……
平台的一个标志是，从经济上讲，它是一种双边市场的形式。平台将买家和卖家（开发者和用户等）聚集在一起，并充当某种形式的中介。
有时候这种事情只发生在公司内部，比方说通用汽车这个例子。更重要的是，平台汇集了价值链的不同部分。最常见的情况是，一个平台为价值提供了一个清算所，利用这个清算所来提供分配，然后将市场的一侧的东西打包，供另一侧消费。谷歌和 Facebook 的广告市场就是这种方式的平台。这些平台通过不断添加功能来横向扩展，利用这些功能来增加分发和消费，从而对消费者和广告商都有很大的好处。这种消费者越来越多的正向强化循环又会吸引更多的广告商，从而拉动更多投资到吸引消费者的能力，这是这些产品的关键要素，尽管未必就能将竞争对手排除在外，比如 Facebook 和谷歌就形成了双头垄断的局面。
就 Windows 而言，该平台的聚合发生在横向和纵向两个方向。我们通常将 Windows 看作是开发者开发应用的平台，然后这些应用再进一步向价值链上游移动，最终到达客户。Windows 还延伸到价值链下游的 PC 组件制造商，与他们不知疲倦地合作，以改进他们向价值链更上游的 PC 制造商销售的产品。 Windows 还跟许多合作方合作，通过给 Windows 体验添加功能来横向扩展 Windows。这些公司看上去也许像应用或硬件，直到微软选择在 Windows（或 Office）本身去实现这些功能。这种垂直市场与水平市场的结合早就了一个外部飞轮，放大了平台的经济性。平台越是扩展，想要加入的人就越多。比尔·盖茨曾说过：“当使用它的每个人的经济价值之和超过了创建它的公司获取的价值时，它就变成了一个平台。”虽然这种说法捕捉到了一个美好的理想，但它并没有捕捉到整个生态体系的内在脆弱性，一旦经济学不是这种情况时，就会变得像 3.0 版之后的几乎整个 Windows 一样。从历史上看，最终时 Windows 俘获了该平台的大部分利润，而不是合作伙伴——今天的苹果 iPhone 以及广告的某些方面也可以说是这种情况。
平台的模型
在设计平台时，即便大多数平台都是有机地出现的，但对模型有一个清晰的认识至关重要。虽然模型总是在不断演变，并且一项新技术可能就会创建出一个新的（并且比以往任何时候都要大的）平台，但这种技术的发展往往会朝着以下分类法的一个或多个方面快速收敛：
应用程序编程接口 (API)
用户体验 (UX)
应用既平台
数据存储平台
水平与垂直平台
插件、加载项和及可扩展性机制（定制）
连接器与集成
应用商店
交易市场（Marketplaces）与网络
开源
下面介绍的每一个案例都有一个最统一的特征，那就是随着时间的推移，平台的主要用户会把平台当成自己的工作，而不仅仅是一个可以调用的东西，真的就完全把平台当作自己的工作了。比方说，很多市场营销人员把所有的时间都花在了谷歌和 Facebook 的制造需求上面。当然了，大多数开发者都曾一度认为自己是 Windows 开发人员。许多企业完全将 Shopify 当作自己的分销，等等。
下面的描述还介绍了一些结构性挑战，而这些挑战往往定义了特定平台模型不断要抗争的东西是什么。
我的目的不是要定义出完整的分类，而是提供一系列涵盖广泛市场大多数产品的平台类型。虽然我不敢说这份清单已经很完整，但我觉得大多数平台都具有里面列出的其中一个主导元素。
API（应用程序接口）。API 从很多方面看都属于原创的后大型机技术平台（长期以来被许多人认为是大型机的主要平台的一种编程语言）。 API 主要针对开发者。不过，有很多 API 会被非专业开发人员无意中使用到。从某种意义上说，无代码运动对用户隐藏了 API，尽管由此产生的生态体系也是基于 API 的。
随着时间的推移，API 平台的管理变成了平台产品开发最困难的挑战之一。当你提供 API 时，实际上是在提供你的实现的视图。因此，随着时间的推移变更实现意味着你直接或间接地在坚持采用旧架构。这就是为什么很多 API 公司弄出了大量冗余，或“做同样事情的 n 种方法”。数据库及数据访问的世界在 API 的演变过程中几乎处在很滑稽的位置，那些公司总是例行公事地推出一个新的 API，试图理清一切，但往往总是又引入了一个新的“n+1”API。 API 尤其容易受到平台竞争的影响，竞争对手平台会为开发者提供“刚刚好”的解决方案，并聚焦在跨多个底层操作平台（如云或设备）提供支持上，同时还提供了操作平台上不存在的服务。
存在完全是为了给底层系统提供抽象的 API，也就是中间件，可以解决上述典型的 API 挑战，但中间件也会受累于另外两个脆弱性。首先，这些 API 为程序员提供了一个独立于底层系统的模型。这种做法确实不错，但如果底层系统分化到难以将其功能暴露出来时，中间件的做法就会遇到麻烦。事实上，大多数平台都在费尽功夫把位于中间位置的中间件挤走。其次，这些平台往往会抽象出多个底层平台（比方说，跨平台库）。它们也会遭遇上述问题的困扰，但会以n 种方式出现，从而在实现上将产生无法解决的复杂性问题。
这就是为什么更具防御性的 API 平台会提供功能广度的独特组合，同时隐藏一些没人愿意去关心的复杂性。任何只想通过互联网收钱的人对国际税收的理解都不可能像 Stripe 那么深，至少在达到一定规模之前不可能。当 Windows 作为操作系统出现时，打印机以及视频子系统的多样性曾经令每一位 MS-DOS 开发者头疼，现在这些事情对开发者来说根本不是问题。在这两种情况下，API 也取代了一些公司过去往往当作知识产权或运营资产的东西。
最成功的 API 会将自己的范围扩大到工程师把大部分的编码时间都花在跟这个 API 打交道以及处理整个系统的增长上。实际上，对于这位工程师来说，API 是定义了他们自身工作的抽象。
用户体验 (UX)。在复杂性的另一端会有变成平台的用户体验。我们不怎么会考虑平台的体验，因为这个东西看起来更容易或更易变，但在实践上，开发出新颖的用户体验，把它作为解决重要问题的一部分，这可能会给平台带来活力，为最终用户而不是工程师带来经济效益。
为了让 UX 具有平台动态，用户体验还必须包含有一系列难以甚至不可能复制的功能。正是出于这个原因，一些人认为用户体验可以被视为平台成功的次要原因。 Excel 之所以能成为占据主导地位的电子表格，是因为它的用户界面，还是因为构成了真正平台的大量功能？社交网络也是这样，里面少量的用户体验机制是网络、用户引导、算法性动态消息以及推荐引擎这些基本动态的组成部分。
从竞争的角度来看，最好的答案是上述都要。说到户界面，直接克隆通常不起作用的主要原因是因为你得把整个用户体验都复制过去才行。也许没有任何产品会像 Windows 与 Linux 之争或 Office 与“克隆产品”之争一样受到如此长时间的攻击，但这些都没有给最终用户市场产生明显影响。实际问题仍然存在，也就是克隆品也许能模仿别人的UX，但永远复制不了整个产品体验。
UX 即平台在经济上的最大赢家是微软、Adobe、Autodesk 等，这些都算是大众市场的生产力工具。每家公司都打造了丰富的体验，再加上新颖功能，为各种职业定义了平台。我们最近还看到了完整体验是如何颠覆这些已经非常强大的平台的，比方说 Figma 就颠覆了设计行业（编者注：尽管 Adobe 已经非常强大了）。在软件领域，不管平台的主导地位有多强，都没法确保稳坐王位。
到目前为止，维护用户体验平台的最大挑战是客户群接受新体验的困难。当你想到使用 Excel 的财务人员、使用 PowerPoint 的顾问和教育工作者或使用 Word 的律师时，没人会想到这样的画面：大家希望获得最新最好的产品功能来简化他们的工作，但这需要他们重新学习所做的一切。在以 UX 为平台的工具里，类似向 Office Ribbon （编者注：一种以面板及标签页为架构的用户界面），甚至彻底转成浏览器型的工具很少见。 Figma 属于个案，它采用了全新的产品，全新的做法，从而改变了设计市场。
平台技术最重大的挑战之一是把一个属于 app UX 平台的东西 “开放”，然后变成 API 平台。很多 app 都会经历这么一个生命周期：一开始先是作为 app 甚至点解决方案而获得关注，然后这个 app 逐渐开放，支持插件、连接器或其他的自定义设置（见下文），最后，从大型技术采用者那里获得了足够的反馈，后者希望利用该 app 的后端、引擎或运行时的魔力，并构建他们自己的 app 体验，把原先的 app 当作可重用代码块来用。尽管这条演进道路也许很有吸引力，但几乎永远都走不通。
在这个生命周期阶段存在许多挑战。首先，不管产品一开始就设计得有多么好，如果你是先做用户体验的话，那么会有两个老生常谈的东西。首先，用户体验本身可能会在不可预知的地方去抽象出来，就为了让产品能跑起来。其次，如果缺乏合适的用户体验，就不可能维护数据的完整性，因为你很快就会知道这种完整性有多少是在用户体验当中形成或得到保证的。这些问题都可以通过时间和重新设计架构来解决，但负责后端或运行时的工程师不部分都会诅咒前端团队违反抽象约定。这会让 app/平台陷入困境，因为开发者希望有完全控制权，但企业希望保留产品的品牌与所有功能。
其次，平台的经济效益很快就会失效。基于平台后端构建整个体验的客户或第三方，因为无法与产品的标准前端一起运行，会不愿意为自己系统的每个用户支付全价。如果第三方知道他们的销货成本（COGS）仍包含产品的全价许可的话，他们几乎永远都不会愿意对这个平台下注。这通常会导致各种套利的工程手段。从历史上看，这对 PC 计算当中最早的平台工具类别，也就是桌面数据库造成了困扰。没人能找出让桌面数据库赚钱的最佳方法，因为桌面数据库主要是用作数据库引擎而不是产品用户体验。SAP 与 Salesforce 经历过同样的情况，因为客户开发了针对数据（客户生成数据）的解决方案，但不需要为每一位用户提供许可。两家公司最终都变更了许可方式，但到了那个时候他们已经积累了相当数量的用户体验，并对平台进行重新设计，通过提供基础设施来避免上述完整性问题。
App 即平台。尽管既没有新颖的用户体验，甚至也没有最终用户（相对于 IT而言）决定要购买和使用自己的产品，但部分 app 仍几乎变成了平台。做业务流程，特别是在大中型企业的业务流程，往往会因为把一个业务问题解决得很好，最终定义了那个业务流程，从而变成了平台，并展示出经济回报。从费用报告等日常任务，到人员编制和预算编制等战略流程，再到为运行这些流程而部署的供应链产品等关键任务工作，这些都是公司的平台。
SAP 在沃尔玛、苹果、宝马等公司的崛起比任何其他产品都更能说明这一点。今天的大多数人可能对“部署”SAP 所付出的成本和努力都不敢相信，但对于大多数客户而言，这需要花费数年时间，成本高达数千万甚至数亿美元。2007 年，沃尔玛决定用 SAP 替换内部系统，3 年后，部署的第一部分才投入运行！
到了更现代的时候，Salesforce 也展示了同样的前进步伐。部署这项工具与获取软件产品一样，需要整个公司进行流程重组。
作为平台的 app 的平台地位是怎么得来的呢？一般是通过自定义以及在长期部署过程中将 app 融入到现有数据和流程得来的。这些 app 功能是经过多年争取客户和部署的努力形成的，其结果是对坚不可摧的价值堡垒具有极大的粘性。随着时间的推移，企业的方方面面都要接触到这些平台，而企业本身基本上就是建立在平台的基础之上。整个工作职能都是很由工具能做什么，可以输入什么信息，从工具可以提取什么来定义的。以这种方式通过平台赢得销售，可以保证十年或更长时间的胜利。获胜还意味着对产品进行彻底改变的能力几乎已被淘汰。
大多数人在尝试针对这些类型的平台开展自己的销售时，首先观察到的是巨大的价值以及客户给予这类平台的信任，然后很快意识到最好的办法是跟这些平台做捆绑销售。
与 API 平台一样，在重大技术变革时期，app 平台的所有优势都会变成弱点。随着企业与其供应链的联系越来越紧密，SAP 被迫用更多的 API 以及不同安装之间的连接作为响应，以便供应链可以完全自动化。这些连接是沃尔玛部署的标志（虽然不是在那里发明的）。SAP 自己发现，将很多客户迁移到云模型很有挑战性。多年来，Oracle 一直抱怨本地软件的定制阻碍了向云端的迁移。然而，直到现在，大多数云部署都具备定制功能——尽管实现方式与 SAP 那样提供数据库访问不一样。
数据存储平台。在历史上，最早、最硬核的平台是数据存储产品。数据存储作为平台具有多方面的好处，因为它是面向最终客户与开发者的平台。多年来，在客户规模和收入方面，SAP 一直是Oracle 业务的最大驱动者，直到最后它搭建了自己的数据存储层。
许多企业客户和开发者对数据存储平台的感觉非常强烈，强烈到他们会将先修复数据存储层来作为项目或产品采购讨论的开始。在数据中心私有化的过去，这是因为只跟一个供应商打交道的话，获取和管理数据存储技术的成本伸缩性会更好一些。因此，Oracle 就因为自己是事实上的标准而实现了平台级的经济，每一个新产品都需要与这家公司的数据中心以及数据操作员很好地配合。今天，我们看到有很多企业会指定所购买的产品要用哪个云服务，尽管对于大多数供应商来说，这个实施要求并不是摆在台面上的。
“裸”数据存储平台的作用在云/SaaS 的世界里已经退居二线，现在重点已经转移到能够汇集组织各种不同工具使用的所有数据上。有了这个，我们已经看到数据平台开始复苏，只不过功能层面已经比块存储或 SQL 高了一个层次。
数据存储的平台性来自于作为公司单一的事实来源——那些重要的实际交易数据。随着存储经济的变化以及云计算的兴起，我们开始看到，交易本身转移到不同数据平台的方式已经发生了变化。新的平台，如 Databricks 与 Snowflake，已经具备传统事务后端的属性以及分析和报表功能，在过去，这些被认为是在战略数据库“之上”运行的独立产品。换句话说，事实来源开始变了了。随着事实来源的变化，平台杠杆与经济也随之改变。
水平平台与垂直平台。我们已经看到一些平台是如何用一个产品同时为开发者和最终用户提供服务的。这是同时充当垂直平台和水平平台的具体案例。一些产品是一系列合作伙伴的平台，这些合作伙伴或者是主产品的补充，或者集成了主产品，同时对位于产品之上的付费客户的工作流也变得至关重要。
属于这种类型的数据平台比比皆是。尽管很多现代 SaaS 应用试图避免严重依赖于云端的特定实现，比方说更喜欢使用低级块存储，但云平台的复制和地理托管功能却是云提供商向上突破基础设施身份的关键要素。用于管理数据以实现安全、备份、各种合规性以及在工具之间迁移数据（ETL 或数据搬迁，比方说 Fivetran ）的工具本身就是平台，同时它们也使用它们所合作的工具的平台。
垂直平台在现有产品之上提供了额外的平台能力，然后自己又变成了平台。营销自动化、数据分析以及客户体验就是部署在现有平台（比方说购物平台）之上的平台类别示例，同时它们还为这些领域的专业人员提供完整的体验，让后者根据这些工具跟踪的数据和交互采取行动。
此类平台为客户提供关键功能，但与此同时，它们经常会与所服务的平台直接竞争。它们还受惠于所连接平台的机制与功能。从客户获取的角度来看，产品需要同时匹配客户的底层平台以及所需要的流程集成。通常情况下，人们（作为提供商或客户）希望连接的最大平台最不可靠，或者甚至对横向和纵向集成的产品是不友好的，因此需要注意这种脆弱性。
插件、加载项以及可扩展性机制（定制）。如果说在平台方面有什么是我讨论得比其他都要多的话，那就是插件，或者更轻量级实现（定制）。我对这个话题的热情来自几个地方。
首先，插件似乎是一种轻松快速的取胜之道。早期用户总是要求做出细微的调整或提供一些简单（甚至是显而易见的）功能，因此看起来很容易做。即便是众所周知的产品到后面也会添加功能，但通过速胜尽早开始平台化似乎很有好处。一般而言，早期采用者或精通技术的高级用户也将是最重视对产品进行小调整（插件正好就是干这件事情的）的客户/用户。以这种方式围绕着新产品建立社区给人感觉很好。
其次，插件通常经过专门设计，非常容易创建。许多最新以及最令人兴奋的产品通常会大张旗鼓地快速引入插件架构。这种产品很快就利用了平台的模因，哪怕这个“平台”做的事情大部分都是些鸡毛蒜皮，而且工作量也微不足道。
第三，大多数插件都有能够卸载第三方所需工作的特性。这可能只是为了快速进入市场，或者它也可以用来将棘手的知识产权或许可问题隔离出去。大多数媒体编辑工具都有一个插件架构来处理各种格式，让开源工具得以避免处理 MPEG 许可等问题。
插件繁多的开发工具世界（从 Emacs 到今天的 VSCode ）、Chrome 或 Photoshop 可能会让人以为插件的战略意义很大，会取得很大的成功，但实际情况并非如此。一个困难的现实是，插件的火属于虚火，你很难找到一个大家说成功或者依然存在战略意义是因为插件的平台。这并不是说插件不受欢迎，而是说它们与平台的成功通常不具备因果关系。有几个因素往往会限制插件的战略价值。
简单。插件在设计上就是为了方便创建。当东西很容易创建时，意味着投资不高，也意味着能力有限。反过来，很多新产品，尤其是大公司的新产品，想通过堆砌大量功能琐细的插件来增强平台的价值。这种努力可以帮你弄出一份很棒的新闻稿，但却会把平台搞得一团糟，因为对琐细功能的兴趣会减弱，最终用户难以发现那些功能，开发者会放弃插件的开发，平台因此会变得一团糟。由此我想到了亚马逊的 Alexa 以及 Apple Watch。我相信事实将会证明，OpenAI 插件的耐久性将会与掌握 Alexa 技能的耐久性一样。
应用程序接口。插件 API 的范围在设计上几乎总是非常有限的。一般来说，插件的目标是为了让其他人能够轻松快速地进行集成，因此通过插件 API 公开的产品的表面积很小，主要限于简单的 UI 集成以及对某些数据元素的访问。有限的 API 意味着可以公开的功能少之又少，更重要的是，那些功能可能通过传统（并且更安全、可预测、可靠）的方法也能做到。
脆弱性。尽管 API 通常非常受限，但随着时间的推移，插件在持久性方面往往也很脆弱。它们往往要依赖于封闭的应用的实现细节或用“黑客”手段，才能突破 API 的设计，接触到更多的数据或用户界面。因此，app 进行了重大更新之后这些插件往往就用不了了。由于它们经常发布得很匆忙，或者在经济上不太重要，因此修复起来相当缓慢。
在有些地方，插件可以解决真正困难的问题，并且通常会导致高级且棘手的“解决方案”。 长期以来，Excel 一直都支持那些原先只支持 C++ 的插件，现在，已经有了一个完整的 JavaScript 框架。这些提供了与 Excel 数据类型以及 UI 控件的深度连接。长期以来，用来处理视觉效果的 Adobe 插件一直都是个蓬勃发展的照片和视频专用工具生态体系。
打赌插件平台战略可确保实现平台级经济，或者可以带来持久的战略价值可能还是不够的。
一个贸易展台，展示了 Alexa 集成在汽车的方方面面。有那么两年，Alexa 在 CES 上风靡一时。这是展会汽车/运输板块的一个展位，展示了汽车内置的所有技能。
并没有太多例子证明时间持久的插件架构也有助于打造独特的平台优势。经常是新闻发布得时候风风火火，鼓吹插件如何如何得强大，但却很少会吹捧这些插件的使用情况。随着时间的推移，插件商店/库里面的垃圾几乎总是多过精品。
连接器与集成。连接器与集成是一种特殊得数据存储变体或中间件平台，主要存在于企业软件/SaaS 之中。顾名思义，它们的存在是为了将一种产品连接到另一种产品。连接器与集成都是在产品内部使用并作为平台元素提供。当产品的市场覆盖面很大，并且别人也在做集成或连接的工作时，它们可以成为战略平台元素，但在大多数情况下，SaaS 产品要靠连接器与集成来作为产品的补充。
一些最成功的，获得了广泛部署的 SaaS 产品后来发展成了连接器与集成的平台。 Okta 就是个很好的例子，它绕开了传统本地部署的目录服务，而是搭建了一个与数千种其他 SaaS（及遗留）产品进行登录集成的平台，然后再将该功能提升为一个完整的身份平台。
集成往往要依赖于访问另一个程序的数据的能力，其目的要么是添加数据（比方说将数据从电子邮件或聊天工具推送给销售人员），要么是提取数据（比方说将需要跟进的支持工单从 Zendesk 转移到 Jira）。
在此图中，Okta 进行了超过 7000 项集成。 Shopify 有 5800项。Salesforce 有 3800项，最少的Workday也有 119。Pandium制作的图表（根据SaaStr 的数据），反映了每家公司的集成和扩展数量情况。 （来源：https://www.pandium.com/blogs/integrations-at-the-15-largest-saas-companies）
集成面临一个别人没有的挑战，因为集成意味着能提供完整或必要的用户体验，从而能进行数据验证，处理所有的可能值。大多数提供集成 API 的平台也会经常更新自己的 UX，有时候 API 的更新会滞后，或没有根本就没完全实现新的 UX。有时候当最成功的 SaaS 产品更愿意成为集成的汇聚端时，就会出现所谓的天然紧张关系，意味着数据流到的地方未必时最好或最可靠的信息来源。与此同时，大多数较新的 SaaS 产品都希望从现有的平台赢家那里提取更多信息。此外，从客户的角度来看，潜在的 SaaS 产品千千万，几乎每个客户都总会缺少一个集成或连接器。
在消费领域，连接器与集成与 Google Home 和 Apple HomeKit 等设备和附件平台或新 Matter 等标准一起出现。正如这些产品的任何用户所知道那样，集成的潜力和承诺往往比交付产品的功能更大胆、更可靠。
依赖连接器与集成的产品，无论是作为消费者还是希望以平台的身份作为生产者，往往最终会自己去实现最重要的第三方连接。在连接器型产品的早年，很明显很少有其他 SaaS 公司会做集成工作，不管集成再怎么轻量或者甚至有多少好处都没人做。不用说，最大、最成熟的公司在相当长的一段时间内从来都不会提供“私有 API”访问或任何的专有连接。他们会收到来自客户的太多阻力，要求开放的东西会越来越多，要连接的东西会变成一道长尾。
跟锦上添花但很少能定义一个平台的插件与定制不同，不管是作为消费者还是生产者，连接器与集成对于成功产品通常是必不可少的。因为它们的必不可少，所以只有在出现全新类别或平台转变的极少数情况下，连接器和集成才会自己变成一个平台。不过，这是搭建未来平台关键部分的好方法。换句话说，连接器与集成往往必不可少，但不足以定义一个平台。
应用商店。应用商店（或应用市场，或只是商店，不要与苹果的 App Store 混淆）在平台世界里占据着特殊位置。它们也是创建平台的新工具，已经从锦上添花变成了每个平台都会推出自己的商店。
关于商店，大部分的讨论都会落到负面看法上：看门人、任意规则、锁定，当然还有“收税”或“抽头”或简单的抽成。就本文的目的而言，我不会对这些负面发表意见，我只想说，在出现商店之前，我花了很多时间在软件上，我坚信商店可为客户带来的价值，并且会捍卫平台拥有商店的权利，将其视为平台整体不可分割的一部分。
一开始时，应用商店只是一个获取软件的地方。在 BBS，然后是 FTP，然后是 Web 下载站点的时代，软件获取用户最困难的部分是将产品分发给人们，在计算机尚未连接或软件获取还是物理产品的时代更是如此。凭借着 iTunes，苹果不仅打造了一个拥有 iPod 音乐播放器的人都得用的商店，而且还开始收费。商店内的各方都参与进来并因此受益。以前盗版的音乐可以在这里被发现和购买，收入流到音乐家的兜里。 iPod 可以访问全球各地的音乐。 iPod 的所有者可以建立合法的音乐库，等等。
随着 2008 年 iPhone 应用商店的推出，应用商店开始转型。一个完整的开发者 API 平台第一次实现了端到端的扩展，将应用分发、货币化、支付，以及最重要的，对消费者承诺的强制执行统统包括在内。最后这一点最容易被忽视。大多数人往往高估了分发的价值，但分发在互联网时代已经不算什么事儿。这种错位导致对抽佣率产生负面看法。
将平台扩展到商店的关键点是它如何用护栏覆盖平台的 API，从而恰当地使用好平台，所有其他现有技术平台缺的正是这个。这些护栏让平台得以旅行对客户的承诺，保证安全性、隐私、可靠性、外围设备使用、数据访问、app隔离、电池续航、稳健性、可访问性、本地化等。此外，商店还提供了一个安全的支付基础设施，带有包括家长控制在内的护栏。虽然 iOS 平台并非没有利用 API 或 app 护栏漏洞的软件，但相对于其他平台（包括 Android），可以说 iOS 上即便没有漏洞利用、恶意软件以及滥用的问题。
从平台的角度来看，做出对客户的承诺，保证 API 会做该做的事是一回事，但对消费者来说，将这一承诺扩展到“习惯于做该做的事”则是令人难以置信又无可辩驳的胜利。虽然从台式机/笔记本电脑计算转移到移动设备主要集中在外形因素上，但其实真正的转变是应用商店。不难想象，如果没有应用商店，我们所有人面对的会是另一个世界：每到周二就要打补丁、恶意软件、编辑注册表、不能安全地添加 app、也不能完全地删除 app、不断需要进行“全新安装”或重启等等。
苹果可能会说如果使用得当的话 API 代表了 iPhone 的现代平台，但他们确实在致力于建立一种价值主张，甚至被开发者诟病缺乏开放性也在所不惜——开发者以前总是想方设法用各种方式利用 Mac 平台，这种做法未必总能与最广泛的客户群保持一致。同样地，苹果本来可以效仿其他手机和运营商，只给平台提供一些有限的功能，或者将更加随意的商业安排强加给极少数争夺手机地位的开发者。但它们没有这么做，而是建立了有史以来最开放的移动平台——要知道，那时候他们推出才刚刚一年，在手机市场上的份额只有个位数，竞争对手还非常强大，并且通过运营商进行的分销还十分有限。
这些对初创的那个应用商店的热烈评论，主要是为了提醒平台开放者以及有抱负的开放者，应用商店是对下载 app 的那些人的承诺。这是一个机会，一个开放具有丰富功能集的 API，同时提供一种机制将这个 API 扩大到这种承诺的机会。这就是开放包含有商店的平台的意义所在。
也就是说，在急于将资产平台化的过程中，很多人设立商店时其实就是为了分销。一般是现有平台会这么做，通过营销努力显示支持的广度。比方说，一个带有连接器的平台可能会设立一个连接器的“商店”，或者有很多供应商开发监视、部署或管理工具的平台可能会设立一个这些工具的“商店”。虽然这种做法可能有一些价值，但我认为这是一种比较弱的商店形式。主要甚至大部分的价值都落到现有平台上了，最终受益的供应商寥寥无几。它们很少让这些工具的制造商受益，而且几乎都没有对客户的承诺甚至收益分享。事实上，由于无效的承诺以及缺乏真正的客户线索，围绕着此类“交易市场商店”展开的非正式讨论的调子往往是非负面的。一个好的经验法则是产品目录大全既不是商店也不是交易市场，其实只是罗列 logo 的幻灯片的网站版而已。
交易市场（marketplace）与网络。为了保证完整性起见，交易市场也是平台的一种，应用商店是连接软件开发者和设备所有者的交易市场特例。如前所述，交易市场已经有很多人进行过深入研究，而且也写出过比我要睿智得多的东西。今天的交易市场要靠软件和技术作为工具，将交易市场双边聚集在一起，并成功匹配到买卖双方。不过，与上述平台不同的是，它们主要不是科技公司。其基础商品是产品，并定义了市场，无论是交通、杂货、酒店房间还是其他都是如此。
网络与交易市场具有相似的特征，因为平台是由基础资产（例如社交网络）组成的，而网络则是应用该资产的结果。与交易市场一样，利用技术创建网络资产本身就值得拎出来讲，而且研究得已经很深入了。许多网络也有 API ，或者以 UX 作为平台元素。
开源。同样为了完整性，开源通常也被视为一种平台类型。有一种平台分类法的主轴是营销组合的分销或定价方面。开源提供了一种独特的分销和定价机制，利用了下面要讨论的营销组合的“价格”和“地点”。形成一个技术平台基础的开源项目会利用上述模型之一设立出来。有关开源的作用与面临的经济挑战的精彩讨论，可参阅 Peter Levine 的《为什么永远不会有第二个Redhat：开源经济学》（Why There Will Never Be Another RedHat: The Economics Of Open Source）。
关于粘性/转换成本的注释……
搭建平台的目标是给平台创造粘性，去做出大家想要，想尝试，然后继续使用的东西。虽然最好的情况是在某个份额指标上主导了市场，但建立一个伟大的平台未必就得占据主导份额。有很多市场都很大，大到可以容纳几个大玩家，或者足够多样化，多样到单一的主导玩家毫无意义，不管这玩家是如何自然或合法地形成的都没意义。
许多人在建立平台的时候往往会犯一个错误，就是一开始就知道粘性是自己的目标，所以把切换成本设计得很高。切换成本高的平台，没有哪个会一开始就把这个作为优先事项来进行系统架构设计的。客户比我们想象的要精明得多，没有哪个会明知道切换很困难还义无反顾地购买你的产品的。
甚至监管机构也是在事后才意识到这一点。人们想要坚持使用的产品也将是那些它们很难不去用用的产品。我总是说其实产品永远都不需要刻意去设计粘性，因为一个大家想要使用的好产品自然而然就会产生粘性。事实上，从长远来看，对于那些把使用要尽可能少，完成任务要尽可能高效作为设计目标的产品，客户往往会很重视。客户能完成的事情越多，使用产品的次数就越多，产品就越有粘性，而这一切都没有去刻意设计粘性。有些人会说我的这种心态太天真或过于乐观。它们爱怎么说就怎么说吧。
我在微软的时候，跟比尔·盖茨在一个问题上多年来一直都有争执，那就是要不要可以将产品设计成专有或刻意制造粘性。当客户喜欢产品时，我看不到有这个必要。比尔是他那个早期时代的产物，他看到了 IBM 是如何利用专有技术去发挥其巨大优势的，所以也一直在推动这一点。无论是开发编程语言的专有扩展，还是创建无法复制或翻译的数据格式都是这样。在《Hardcore Software》里，我写过一个发生在反垄断案审判期间的故事。Office 打算用开放的 HTML 作为文件格式，这引起了比尔·盖茨的强烈反对。
他的原话是“我们不能再做这件事情了，要确保 Office 文档对专有的 IE [Internet Explorer] 能力形成很强的依赖。对我们的平台来说，做任何其他事情都是自杀。在这种情况下，Office 必须避免做一些会摧毁 Windows 的事情。”
这么说吧，我不同意。
关于开发既能帮助到人们又能增加公司粘性的产品，我制定了一条经验法则，这条法则是这样的：事实来源 >> 代码 >> 流程 >> 个人技能。我的意思是，最具粘性的平台是业务流程的事实来源仅存在于那个产品之中的平台。一旦数据成为事实来源，无论数据有多开放（通过 API 或 ETL），其离开平台的能力都会受到数据或代码语义的限制，而不仅仅是磁盘上的比特。下一个最具粘性的平台是基于第三方代码开发的平台。编写代码是一笔巨大的投资，虽然传统上被视为一条很厚实的护城河（如微软反垄断案中所述），但我们也看到，公司看待代码的方式已发生了翻天覆地的变化。代码的寿命变得更加短暂，用更少的代码已经可以完成更多的工作。此外，云和浏览器大大减少了基于底层平台（例如 AWS）开发独特代码的数量。在企业内部，围绕平台使用的流程会建立起下一个最具粘性的平台。令人惊讶的是，一些被太多人认为相对简单的软件也能建立起一个非常粘性的平台。 大家（包括一些名人在内）往往认为 Okta、Docusign、Box 等都属于平台的简单功能的例子，但通过聚焦于工作过程，这些产品都打造出了极具价值和粘性的平台。最后一个是用户的个人技能以及对学习/使用一个平台的投资，这种平台的粘性最低，但仍然具有粘性。虽然个人可能会非常依赖一种产品，但组织和人们更愿意切换和学习新东西，而不是变更流程、编写新代码或传输数据。对一个组织进行再培训需要付出巨大的成本，在有数以万计的人执行软件实现的一系列自动化流程的领域更是如此，但可以这么说，人是整个技术栈里面是最灵活的。
为什么平台在推出的时候会失败？
既然身为平台好处如此之多，为什么会有那么多失败的平台？就像大多数的产品开发一样，定义和识别失效点很容易。但与大多数产品失效不一样的是，根据过去的行为预测开发平台的潜在失效点通常不难。换句话说，随着时间的推移，典型的平台会失效的地方几乎没有例外。例外总是有的，但理解例外的关键是要弄清楚例外的存在是否是平台成功的原因，还是出现在一个已经取得成功的平台上的巧合。产品与市场匹配是一股强大的力量。为什么平台在推出时会失败：
未能解决平台消费者真正遇到的问题
要求客户解决你的问题而不是他们的问题
没有人愿意利用平台
体验与 API 的关系以及“谁在上面”的问题
做得太多
做得太少
在错误的地方、以错误的方式收费
所有这些失败范例都有一个共同的主题，那就是缺乏理解，不知道一个平台要想取得成功，客户也需要付出努力。他们付出的努力越多——他们的机会成本就越高——成功的可能性就越大。客户付出的努力越小，潜在回报就越小。
未能解决平台消费者真正遇到的问题。这一条可能是最明显的，但即便平台是次要努力的结果，建设平台也要找到产品市场匹配。尽管有最好的意图，如果你需要投入的资源看不到机会，那么平台到头来仍会失败。再怎么推广或做机会营销都无法改变这一点。
要求客户解决你的问题而不是他们的问题。虽然这条没那么明显，但平台最常见的失败是不解决客户的问题，而是为了解决你自己的问题。Alexa 技能并没有解决客户问题，因为大多数设备都没有通过语音控制受益，但是却让每个人都要花 10 分钟的时间来形成一项基本技能，这无疑解决了证明 Alexa 具有巨大行业发展势头的问题。围绕着许多 SaaS 产品建立的交易市场通常不能推动客户或采用（或实现对客户的承诺），但确实让 SaaS 产品看起来发展势头不错。这种失败的最坏情况是平台（如插件）的存在是为了堵产品出现的漏洞。狂热者喜欢用各种插件组装出完整的产品，但大众市场很少会这么做。
没人愿意用。如果平台你搭好了，却没人来该怎么办？做出一个平台，甚至带着强烈兴致做了大量公关，但这个领域根本没有对平台的需求是很有可能的。这种失败的根源通常是过早平台化，在整体（整个产品+设备，或产品+体验）还没站住脚或者有明确的用例之前就匆忙动手了。这种失败的最困难的地方在于问题仍然存在，但提供的平台还不能将那把火烧起来。公司越大，就越难诚实地承认是否存在这种失败。大公司总是随时都能准备好一些粉丝，这帮人会以某种方式去用一下那个平台（还有人记得ActiveX 或 WinForms吗？）。在大型公司以及成功的公司那里，平台错觉是真实存在且很严重的问题。
体验与 API 的关系以及“谁在上面”的问题。从现有的专用产品衍生出来的平台通常无法“不挡道”。平台的开发者以及潜在消费者强烈希望能使用底层数据或计算引擎，但平台制造商认为自己的应用需要保持可见，需要处在显眼的中心位置。问题是开发者出于业务和可用性的原因希望拥有完整体验。在分层架构下，维持数据语义完整性需要知道用户访问数据的所有方式。如果硬是要给用户体验里面塞进平台应用，就很难对所有的访问路径进行质量控制。
做得太多了。为了让平台起势，消费者必须能访问平台。做到这一点不应该需要大量的专业知识或疯狂的前期投资。在设计平台时，“Hello World”的等价物必须是一小时或更短的体验，并且接下来的步骤必须显而易见。尽管计算机很酷，但向图形界面的过渡，尤其是针对 Macintosh 编程的情况下，对很多人来说都非常困难。后来直到工具升级之后，应用才真正开始起飞。一个聪明人，就算既拥有知识也具备经验，仍完全有可能开发出一个任何人都难以掌握的平台。好消息是，如果平台足够强大，就会有人投入进去，并做出产品来，而他们的输入可以帮助改进工具。
做得太少了。另一个极端是有太多的平台做的事情太少了。那些平台所做的事情也许很酷，但考虑到换取它们所做的事情需要付出的代价以及机会成本，就显得它们能做到的事情实在是太少了。当 Apple Watch 推出时，用手表打 Uber 的演示效果确实非常吸引人。但结果不奇怪，每当我想叫辆Uber时，我都会拿出手机。大量 Watch app 也可以说是这种情况。随着苹果扩大了 API 的范围，并大幅提高了开发 Watch app 的“税”，这些 app 开始从商店中消失也就不足为奇了。不过，至少它们是消失了，而不只是挂在那里什么都不干。无数的“插件”也属于这一类，尤其是当插件的主要功能是提供快速访问完整网站/应用的入口时。那些插件根本就没人用，而且几乎不是任何用例的难点。
在错误的地方、以错误的方式收费。好的平台不是免费的，但获得收入的方式有很多种——这是机遇也是挑战。找出适当的地方用适当的方式来获得收入，这件事情做不好通常是平台失败的主要原因或唯一原因。技术人员总以为技术上最先进的平台就是最好的平台。然而，技术可以有很多属性，人们可能会在哪些才是最重要的问题上存在分歧。MS-DOS 只是众多操作系统之一，而当时业界认为将会出现一些占主导地位的计算机制造商，而每一家制造商都会有自己的操作系统。虽然 IBM 给予 MS-DOS 照顾，但自己也提供了 CP/M 甚至其他几个古怪的平台。让 MS-DOS 脱颖而出的是它的商业模式，用低价授权给其他计算机制造商，然后一切都不同了。在大多数计算机制造商提供的选择很少且价格更高的时候，代价就会选择更便宜的计算机。在 1984-89 年期间，苹果的软件要好得多，但一直都没法跟无处不在的 PC 平台竞争。每一次平台的更新换代都会有一个关于定价错误或分销策略失败的故事。最大的教训是，上一代的成功未必就能保证下一代延续辉煌。最好的例子就是苹果 如何将失败的 Macintosh 策略用于 iPhone，并且取得了巨大成功。
关于未能考虑到所有 4 P 要素的注释……
平台是产品，而不仅仅是技术。不过，大家经常认为这主要是技术问题，成败往往被认为跟技术关系最大。记住这句话往往很有用：“最好的平台不一定总能赢，但能赢的就是最好的平台”。花时间去研究一下营销组合的 4 P（产品( Product )、价格( Price )、推广( Promotion)、渠道（Place ）），弄清楚平台该如何解决每个问题，以及竞争性的替代方案如何才能融入其中，可以帮助你决定哪种平台方法最适合你所追求的市场。
为什么平台能成功？
尽管面临这种种挑战，许多平台还是取得了成功。它们成为其他人的经济基础，也是人们完成工作或加入网络的地方，同时还为平台制造商带来经济回报。虽然了解一些成功因素也许可以作为有用的路标，但公式化的做法依旧不存在。产品开发仍然是一门社会科学。我之所以知道，是因为我失败过。
以下是成功的技术平台的一些属性：
开发者，开发者，开发者
实际上，你要建设的是一个生态体系，而不仅仅是一个技术平台
让别人成功，别成为负担
赋予特定领域蓬勃发展的能力
别挡道
可预测
实质性与粘性
份额犹如空气。快要死的时候要贪婪
开发者，开发者，开发者。史蒂夫·鲍尔默 (Steve Ballmer) 是微软前首席执行官， Windows、Azure 与 Office 365 的成功，他不是贡献最大的那个人。鲍尔默总是直截了当，从来不懂拐弯抹角。令人惊奇的是，无论是讨论合作伙伴、企业还是零售，鲍尔默都会用同样的技巧。重要的不仅仅是他的重复或大嗓门，而是他对取胜的疯狂重视，一个细分市场接一个细分市场，一条产品线接一条产品线。要想通过平台取胜，就必须设身处地为目标客户着想。这就是他不断重复想要表达的意思。唯一重要的是像你的客户一样看待这个世界，并向它敞开怀抱，为之而建。抛开你的自负，干好平台该干的事情。他还有一句口头禅，据他说是他父母的话：“如果你想做一件事，就全心全意去做好。。我一直都认为这句话的意思是如果你要搭建一个平台，那就得全心全意把平台做好。
实际上，你在构建一个生态体系，而不仅仅是一个技术平台。从生态体系的角度思考会让你思考各个部分如何组合在一起，以及没有平台是单边的（即便我们专门将交易市场定义为多边）或仅仅与技术有关。如果技术或代码就是平台，那么生态体系就是围绕该平台的一切，代码如何成为所有相关方的加速器。即便你用开发者用来开发应用的 API 来开发某些人所认为的企业软件，仍然还会有渠道合作伙伴、顾问、培训师、第三方支持以及围绕着要实现的工作流而开发的其他软件甚至硬件。这些构成了一个生态体系。这些都需要付出像开发者一样的努力和外展服务。 苹果，尤其是传奇营销人员 Guy Kawasaki，带火了布道者这个词，为了平台的成功而将各方聚集到一起所涉及的工作都属于布道者的工作范畴，相关内容可以看看《Selling the Dream: How to Promote Your Product》与《Company or Ideas and Make a Difference Using Everyday Evangelism》。对于生态体系在产品开发当中的价值的技术性描述，可以看看我朋友哈佛商学院教授 Marco Iansiti撰写的一本基础读物《The Keystone Advantage: What the New Dynamics of Business Ecosystems Mean for Strategy, Innovation, and Sustainability》。
让别人成功，别成为负担。平台的存在是为了让他人能成功。最成功的平台帮助人们用自己的方式取得成功，而不是以你的方式。一个成功的优秀平台感觉就像有一整支团队帮助你实现目标，而不是像个负担或在跟政府合作一样。这说起来容易，一开始确实也不难，但在规模做大了之后，你公司其他人的观点就会开始主导每一次讨论和动议。要跟那些人做斗争。
赋予特定领域蓬勃发展的能力。创建平台的乐趣之一是看到用户对它的使用方式超出了你最初的预期。做出能让你了解其他世界的东西会带来惊人的满足感。我当初在微软开发 C++ 编译器时，对我来说，最大的乐趣就是看到大家用它开发出我从未见过的东西。我见过一个人用 C++ 开发出来的 Windows 前端做出了一台 DNA 测序仪。我见过一些人开发业务线工具去控制制造车间工具（并连接上 SAP）。我甚至在伊利诺伊大学见过一个人开发一种新型的 web 浏览器。虽然 iPhone 上的一切看起来都是新的，但我永远不会忘记那一幕：展示医学大脑图像的 app 的那场布演示……在手机上！
别挡道。对于任何开发产品的人来说，最困难的事情就是默默地退后幕后，把舞台让出来。这样做可以让那些把平台当舞台的人大放异彩。成功的平台存在地意义是为了他人的利益，这一点从始至终都很重要。平台岗做出来地时候，不挡道很容易，因为东西本来就不多。随着时间的推移，随着复杂性和接触面的增加，这件事情会变得越来越难，甚至会与你自己的目标背道而驰。要抗争。重新设计 Office 用户体验平台是我做过的最困难的事情之一。我们的最大目标是让用户界面不碍事，让用户的工作占据尽可能多的屏幕。我们对 Windows 7 以及Windows 8 做了同样的事情。默默退居幕后。当我们设计 Windows 8 时，UX（以及开始屏幕和 app API）的主要设计目标是将整个设备交给应用，让 Windows 摆脱困境——开发者可以控制屏幕的每一个像素，就像设计游戏一样。无论是 API 还是用户体验，你认为自己能做的任何事情都没有平台用户想做的事情重要。
可预测。一旦其他公司把宝押在某个平台上，那么这个平台就得（也许是间接地）对其他公司的收入负责了。对于合作伙伴来说，一旦他们押注在一个平台上，唯一重要的就是可预测性。这种可预测性在成功的平台上有两种形式。首先，平台的工程合作伙伴对有关特性和功能的承诺极为敏感。其次，平台业务合作伙伴对有关定价和可用性的承诺极为敏感。成功的平台兑现承诺并如期交付。关于 2000 年至 2009 年间对 Windows 平台造成的损害，论述的文章已经又很多（甚至有些是我写的）。未能兑现承诺按按期交付是平台恶性循环的一个重要原因，只不过这个问题被产品市场匹配规模水平掩盖了。与此形成对照的是苹果对 macOS 和 iOS 的管理方式，不管怎么说，这都是 20 年来维持可预测性的非凡工程壮举。
实质性与粘性。到目前为止，这一条始终是最难衡量，最难讨论的。不管是具备实质性（可能会太过复杂、开销太大，或者太过宽泛），还是具备粘性（切换成本太高），都存在固有的负面影响。用这些形容词很容易让人感觉很糟糕。不过，现实就是现实。成功的平台是很有影响力的。它们解决了非常困难的问题，至少是一开始看起来很困难的问题。Windows 一开始是让打印和使用剪贴板变得很容易了，这在 MS-DOS 上都属于火箭科学。当某样东西很重要并且大家开始对其下注时，那么根据定义，它就是有粘性的。没必要刻意去设计粘性，这样做是玩忽职守甚至有点粗鲁。只要解决好难题并让解决方案使用方便，粘性就会随之而来。以后每个人都会认为你所做的事情是显而易见的，并没有那么困难，但没人能够复制你的工作。这样一来，平台就是了不起的平台。
份额犹如空气。将死之际要贪婪。成功的平台企业是硬核企业。他们会为每一块钱每一件商品而战。他们不是慈善机构。尽管如此，他们几乎总是会先关注普及性，赢得稳固的市场份额。这是因为往一个平台下注的实体越多，其他类似实体过来下注的也会越多。通过成为份额上的领导者，你将融入到这个行业，成为这个领域或技术空间的标配。你会删掉他们的决策点，并成为默认值。这是任何平台的最终目标。史蒂夫·鲍尔默在那些煽动人心的时刻总是会提醒销售团队“份额就是空气”。即便在我们取胜的时候，我们也为继续取得新的胜利而奋斗。生态体系的管理者为每一位 Windows 开发者、每一个 Office 席位以及每一位 IT 经理赞助人而战。很多人已经不记得事情的实际情况，但 Windows 始终都只占到 PC 价格的几个百分点。即使 Netbooks 问世了，Windows 的成本也远不及其他部件。关于平台，《创新者的窘境》从未写过的现实是，一旦平台失去势头，就是该贪婪的时候了。时至今日，IBM 的大部分收入仍然来自于大型机。Oracle 的价格在鼎盛时期和今天都很糟糕，有了一个成功的平台之后，他们表现贪婪的时间比你想象的要长得多。
关于平台护城河的注释……
关于平台的描述，没有比拥有护城河这个概念更容易被误用了。Investopedia 给护城河做了一个定义，后来这个概念被传奇人物沃伦·巴菲特带火了：
一个企业为了保护自己的长期利润与市场份额，维持对竞争对手竞争优势的能力。就像中世纪的城堡那样，护城河是用来保护城堡内的人及其的财富免受外来者的侵害。
通过衡量护城河有多厚实来评估一个成熟的企业，一个平台，是价值投资者、顾问、分析师以及 MBA 等人最喜欢的消遣方式。不断发展的平台正在制造护城河，但我们不会这么叫。我们称之为发展。萎缩的平台没有护城河，相反，周围的地基都在下沉。其实什么都不需要看，只需看看份额即可了解平台是否有护城河。平台不是商品，不能简单复制。就是这么简单，我承认我喜欢简单。
用“护城河”来描述平台会出现一个普遍存在问题，哪怕在价值投资圈里，护城河也是一种追溯修订，一种回过头来进行的构造。护城河是企业在取得成功之后，或者之前取得成功然后丢掉份额或萎缩之后，对企业的一种描述方式。没有“潜在的护城河”这样的东西。平台要么有护城河，要么没有。在平台开始衰退后，MBA 的案例研究才开始讨论护城河。
平台生命周期
通过对技术平台的类型、为什么平台会推出失败、以及为什么平台能取得成功有了共同理解之后，我们对技术平台生命周期应该有一个思维框架了。有了这个生命周期的概念之后，我们可以看出平台会有哪些失败的机会，或者平台管理在哪些地方会出错。
平台生命周期如下图所示。这是一个循环。循环上的 11 个点对应的是下面这篇文章的正文。
平台生命周期
需要注意的是，没有任何一个平台经历过这里的生命周期的每一个步骤。有些平台永远都走不到最后，而有的则越过了其中的某些潜在的陷阱，然后跑到了最后。有的在这个完整的生命周期当中途会萎靡不振，但在很长一段时间内仍然能养活自己。不过，这些阶段每一个都非常典型，足以说道一番。
推出一个“玩具”。大多数平台都是作为玩具而推出的。不开玩笑，看看一开始的 HTML/HTTP。任何领域都会有一群技术专家或爱好者不断寻找最酷的新玩具。他们把平台几乎所有的东西都玩一遍，很快就会对一个潜在的新平台表达自己的兴奋。最简单的了解方式是，有一群人真的会放弃一切，每天都会出现新的用例和“应用”（找不到更好的词了）。在今天的背景下，很容易看到 ChatGPT 以及来自 OpenAI 的相关 API 符合这个描述。一个新平台的出现就像一道闪电。
做一切事情。无论在哪个领域，平台到了这一点都发展得非常快，尽管玩具推出的前期准备时间都要花好几年。早期的进展似乎快得离谱。一旦有人提出要求，东西似乎就会出现。然后似乎在一夜之间，该平台做到了每个人认为它需要做的大部分事情。有争议的都是些旁支末节或者全新的想法，哪些尚未成为平台的一部分，但不一定具有普遍的吸引力的想法。尽管看似一眨眼的功夫，却需要几年的时间。同样地，思考 ChatGPT 的时候也需要考虑这些事项。
幻灭——什么都做不了。一个成功的平台最疯狂的时刻之一就是大家试图让它做它还不能做的事情。他们什么都想做几乎可以肯定是正确的，但时机完全不对，一些关键技术还没出现。马克·库班 (Mark Cuban) 因设法在互联网上播放体育音频而声名鹊起，而 RealNetworks 也做了同样的事情。那是 20 世纪 90 年代后期，大多数人仍在用 56K 的调制解调器。这种条件下根本是行不通的。但短短几年之后，我们都能在工作 PC 上观看实时流媒体视频了，再过几年，家里的每个人都能同时观看 4K 视频了，大家都可以在移动的汽车里面播放音乐了。尽管如此，当一个平台没法做到大家共同希望的一切事情时，总会有一段时间会变得令人失望。有时候出现这种情况是很重要的，就像我对 iPad 等生产力工具的看法一样。其他时候它的娱乐性更强一点，比如有人曾经尝试用 Visual Basic 制作 Windows 游戏。浏览器就是这样一个例子，大家不断尝试想让一切都能正常运行，而谷歌一直在努力让大多数的事情能正常运行，而所谓的一切其实在桌面操作系统早就可以正常运行了。
修补完所有的漏洞，但现在已经太复杂了。平台不断努力，试图通过修补完所有漏洞、添加新的子系统、改造现有功能等方式让它能做到一切。这个阶段大家将开始抱怨。开发者永远也确定不了使用平台的正确方法。性能开始下降。如果你用这个平台做事情，你很难找到添加功能的最佳方式。
合作伙伴/中间件引入了做旧事情的新方法。随着平台变得复杂，复杂到很难以正确或明显的方式添加东西，合作伙伴开始自己给平台添加功能，但不是在平台之中添加功能，而是在平台之上添加功能。中间件开始成为很多人的平台，因为它提供了一个更简单的沙箱给大家开发。这些解决方案提供了新的功能，但也开始提供新的方法来做旧的事情。有时候正是这些变化让人开始感觉发生了范式转变。平台正在失去控制。比方说，数据存储行业就从多维分析和 blob 存储的出现看到了这一点。当然了，对桌面 PC 来说，浏览器已经演变成了一种编写相当于桌面应用的东西的更简单方式。
似乎人人都在竞争，出现缺氧的情况。平台发展到了这个阶段，人们开始觉得平台本身就是一个战场。平台的不同部分都在解决同一个问题。或者，也许平台供应商对同一个问题有多种做法，通常只有新旧之分，但关于该使用什么的指导要么含糊不清，要么过于严厉，以至于无法遵循。到了这个点，关于该平台的最大新闻是平台如何与合作伙伴竞争。平台的新功能以前是生态体系其他人做的功能现在房间里面已经没有足够的氧气供大家呼吸了。
跟合作伙伴讨价还价，平台开始挡道。到了这个阶段，平台开始盘剥合作伙伴。最明显的地方也许是定价。技术方面可能也会出现类似情况，比方说过快淘汰各种 API。最重要的是，到了这个阶段，平台本身开始成为障碍。各种小请求或变更开始叠加，与此同时，平台造成的负担开始比解决的问题还要多。
做得太过火，对每个人要求太多。在平台的发展过程中，经常会在某个过渡阶段出现要求太多的情况。 “必须具备”的列表太长，或者维护兼容性和性能所需的变更太多。或者可能只是信息变得不稳定甚至承诺失效。当一个人回顾某个平台的失败史时，几乎总会提到开发商的手伸得太长得时刻。
复杂性成为常态，太烧脑了。平台已经发展到太过复杂的地步。最简单的衡量标准是，新开发者几乎不可能打入到整个生态体系。有太多的选择，需要太多的智商，要学的东西太多了。开发应用插件需要一支团队，而不是一个人。
合作伙伴只想要兼容性和稳定性。到了这个阶段，平台已经开始衰落。这几乎可以肯定已经不是企业得衰退，而是生存能力下降。生命力已经不复存在。热情、承诺，新的应用不再出现。所有的要求都只是为了保持兼容性和稳定性。 “请不要破坏任何东西”是最常见的说法。平台开发团队几乎总是以“我们正在倾听客户的意见”作为回应，“反馈”成为常态。
新东西没人用。到最后，平台推出的任何新东西已经没人愿意用或者没人能用。平台推出了新的 API、支持了新的场景、新的用户界面，但实际上却没有应用去用、没人对此下注，也没有生态体系来支持相关工作。剩下的客户只是在维护已经做完的事情。
当一个平台经历完整个生命周期时，最后的结局似乎林根悲伤甚至是一场悲剧。在经历过多次这种情况之后，我更愿意把它看作是 “生生不息”以及自然秩序的一部分。平台不应该永生。确实会有更好的方法出现。这没关系。与其尽一切可能让平台在周期的后期阶段苟延残喘，不如开发下一个平台。对于这一点，我的感受实在是太强烈了，我曾经下过一个重注，但没有成功，不过现如今这个平台已经变得更加确定了。这些都是非常困难的挑战，也许是产品开发当中最困难的挑战。
我们学到了一条，技术平台的人生分两个阶段。前半生是诞生并走向成功，这段路走得比看起来要快得多。然后是后半生走向衰亡，这与“颠覆”的叙事相反，不过走完这段旅程需要的时间比大多数人认为的要长得多。平台走出的这条长尾要归功于成功平台的产品市场匹配达到了令人难以置信的程度。一旦平台取得了成功，任何力量都没法让它很快失败。
鉴于我早些时候提到了沃伦·巴菲特，所以再提一下查理·芒格是公平的。特伦·格里芬 ( Tren Griffin) 写过一本关于芒格的精彩著作，《查理·芒格的原则》 (Charlie Munger: The Complete Investor)，这本书很值得一读。对于一般公司，查理·芒格有这样么一个的说法，不过其实这个说法对平台最适用：
从长期来看，美国公司的行为更像是生物学，而不是其他任何东西。在生物学中，所有的个体都会死亡，所有的物种也都会死亡。这只是一个时间问题。而经济其实也是这样的。
我年轻的时候那些看起来很棒的东西都已经淡出，新的东西会出现，然后其中一些会开始消亡。这才是长期的投资环境。这确实让事情变得非常有趣。
成功的平台可能具有生物学特征，但它们往往是精力最充沛的生物，就像真菌一样。它们很难被杀死。虽然我们喜欢柯达、黑莓或 5 英寸磁盘驱动器这类故事，但大多数平台更像是大型机、马匹或银行分支机构。
到最后，平台会屈服于范式转变。并不是每项技术创新都是范式转变，因为大多数的技术创新都可以归类为持续性创新。但范式转变会有的。这是不可避免的。希望这篇文章可以作为平台演进的参考。我保证会不断对这些论述进行修订和更新，因为我确信已经说过的话会有更好的表达方式，而成功或失败之道也需要不断修正。
译者：boxi。