译者：boxi
划重点：
回顾当年对微软的反垄断案，让人感觉五味杂陈
Teams 是微软新服务战略的那个 Windows，这个平台变瘦了，但控制力变强了
无独有偶，Stripe 也要做金融领域的操作系统
胖客户端模式日渐黯然失色，也许意味着科技行业的黄金时代结束
1998 年，美国司法部对微软发起了诉讼案，指控该公司将 Internet Explorer 浏览器与 Windows 操作系统捆绑在一起构成垄断：
互联网浏览器是独立产品，在一个不同于 PC 操作系统的产品市场上互相竞争，分别提供这两种产品是行之有效的。事实上，微软本身一直都是独立提供、推广和分发自己的互联网浏览器的，而不是把它作为 Windows 的组件，并且打算在 Windows 98 发布之后继续这种做法……
微软将自己的互联网浏览器与自己构成垄断的操作系统捆绑在一起，降低了客户在具有竞争性的浏览器产品当中进行选择的能力，无论OEM 等买家是否想要微软的互联网浏览器，这种捆绑都将迫使他们必须许可或获得这种捆绑组合。由于 Windows 的垄断力量，微软可以实施这种捆绑，而这种捆绑会削弱其浏览器竞争对手让 OEM 将其浏览器预装在新 PC 上的竞争能力，从而极大地阻止了这些竞争对手进入到一个重要的浏览器分销渠道。
回想起来，这份诉状感觉很古怪，原因有以下三点：
首先，微软赢得了浏览器大战，但无关紧要； 在 2004 年拿到 95% 的市场份额后，Internet Explorer首先遭遇了 Firefox 的挑战，2010 年IE的市场份额下降到 32%，然后到了 2012 年被 Chrome 超越了。
一种辩解认为微软有行动的自由。而微软赢得了浏览器大战但无关紧要这一点既可以是对行动自由论的谴责，也可以是对行动自由论的认可，具体是哪一种要看是在哪个时间段：当然，微软确实利用自己在操作系统的主导地位攫取了浏览器的市场份额，但这家公司确实也开发出一款出色的浏览器（我个人是在第 4 版发布后开始用的）。然后，随着第 6 版的推出，IE 的地位似乎已经稳固，而微软也停止了开发；也正因为此， Firefox 和 Chrome 才有了机会，最终用户为了能用上更好的东西而自行下载安装这两种浏览器。市场最终还是发挥了作用。
当然，市场之所以能发挥作用，是因为 Windows 是开放平台：是，微软是控制着（并且据称是滥用）新计算机上可以预装的内容，但一旦上述计算机交到用户手中，他们就可以安装任何他们想装的东西，包括第三方浏览器。这就是为什么那份诉状感觉古怪的第二个原因：时至今日，预装浏览器已是操作系统的必需品，而苹果的 iOS 比仅仅预装 Safari 又更进了一步：所有的备选浏览器都必须使用苹果内置的渲染引擎，这意味着那些浏览器只能在用户界面功能上参与竞争，基本功能根本没得选。（苹果声称这是出于安全起见。）
第三个原因与微软本身有关。
胖与瘦
正如我上周所指出的那样，微软 CEO 萨蒂亚·纳德拉（Satya Nadella）在 Build 开发者大会所做主题演讲最重要的主题之一，便是关于瘦客户端与胖客户端之间看似没完没了的技术之争（出于大幅简化的考虑，并冒着引发激烈论战的风险，这里姑且定义瘦客户端为中心式计算机的终端，而胖客户端本身就是计算机）：
看完这个主旨演讲，最大的收获是这个：对于开发者来说，至少是微软所追求的那些开发者来说，瘦客户端模式已经赢了——尽管事实上，就像技术圣 战经常出现的情况那样，最终的获胜者往往是处在中间的某个位置。关键的区别在这：本地还会继续处理大量事情；然而那些事情又给人感觉都是在服务器端完成的。比方说：
GitHub Codespaces 是一个显式的在线环境，但也可以在本地临时使用。
Azure Arc 为本地开发环境提供了 Azure 的控制平面。
Azure Container Apps 以及 Azure Kubernetes Service 让开发者在本地的编程环境跟部署到云端的环境一模一样。
此外，其他几项公告涉及的是修补云端开发相对于本地的限制：比方说， Microsoft Dev Box 支持在云端部署虚拟机，让这些虚拟机模仿本地的开发环境进行应用开发；（之前已发布的）Microsoft Cloud PC 可以对客户端应用做同样的事情。
这种向瘦客户端的转变之所以如此引人注目，是因为明确将其提出来的居然是微软自己。毕竟，Windows（以及英特尔）是胖客户端时代的主要赢家。是，Windows Server 是微软统治企业市场不可或缺的一部分，但正如在与 Netscape 的斗争中所采用的策略所证明的那样，这家公司战略的基石是这个事实，那就是 Windows 是大家使用的设备上的操作系统。扯远一点，这正是移动设备对微软如此具有颠覆性的原因——突然之间，Windows 只出现在大家使用的部分设备上； 还有很多用的是iOS和 Android。
我曾用很多篇文章的篇幅谈斯蒂亚·纳德拉让微软摆脱了以 Windows 为中心的战略；但与本文比较相关的来自那篇《Teams OS 与 Slack Social Network》：
不过，微软以 Windows 为中心的做法的终结，以及云优先战略的转变，这些并不意味着微软对一体化的关注或微软努力成为操作系统的尝试结束了。这家公司只是改变了对操作系统的定义；萨蒂亚·纳德拉在 2019 年的一场新闻发布会上曾经说过：
对我们来说，另一项工作是我们所谓的 Microsoft 365。我们要做的是让这样一种概念回归，那就是这一切都与用户有关，用户要与其他用户和其他人建立关系，他们会有一堆的工件，有自己的日程安排、项目、文档，以及许多其他的东西，还有他们的待办事项，他们还将使用各种不同的设备。这就是 Microsoft 365 的全部意义所在。
有时候我认为这套新的操作系统不会从硬件开始，因为按照我读过的那本《操作系统》的作者之一 Tanenbaum 的说法，经典的操作系统的定义是：‘操作系统做两件事情，一是对硬件进行抽象，二是创建了一个应用模型’。现在硬件的抽象必须从抽象你生活当中用到的所有硬件开始，所以“这是一个单一设备”的概念很有趣也很重要，但这并不意味着启动设备的内核就消失了，内核还在，但我认为对我们的生活来说真正有意义的点在于 ‘嘿，我生活当中用到的所有硬件的共同抽象是什么？’ ——其中有些是共享的，有些则是个性化的。然后，它的应用模型又该如何？怎么才能写出超越所有硬件的体验？这正是我们追求 Microsoft 365 的真正意义所在。
这就是微软的 Teams 可以发挥作用的地方：如果你完全用的都是微软的生态体系，那么一个应用就可以用‘就是管用’的方式把你的联系人、对话、电话、文件访问、第 3 方应用等统统结合到一起。这就是 Slack 以及广义的硅谷所不能理解的，但却是微软的竞争优势所在：这家公司不仅仅因为它的捆绑，或者因为它拥有出色的地面战能力而获胜。就凭借着什么都做，即便做得普普通通，微软也能带来部分之和大于整体的优势，尤其是对于实际上占市场大部分的非技术出身客户来说更是如此。 Slack 可能确实为它的聊天客户端注入了爱，但聊天只是达到目的的一种手段，而微软似乎是唯一理解这一点的企业公司。
请注意前面提到“第三方应用”的那句话：如果 Teams 是微软新服务战略的那个 Windows 的话，那么对于微软生态体系的开发者来说，平台机会本身就是以 Teams 为中心的；纳德拉在 Build 主旨演讲里面正是这么说的：
我们来谈谈工作的未来，以及我们如何让应用更具情境性，更加以人为本，这样就可以开发一类新的协作应用。这类应用从 Microsoft Graph 开始，它是 Microsoft 365 的基础，可提供关于人、人的关系及其所有工件的信息。今天，我们看到世界各地的开发者都在利用 Microsoft Graph 来丰富自己的应用。事实上，有超过一半的 Microsoft 365 租户正在使用由 Graph 提供支持的定制应用与第三方应用。借助 Graph 连接器，ISV（独立软件供应商） 可以扩展应用，无论用户是在编写电子邮件、在 Teams 上开会还是进行搜索，这些应用都可以作为用户日常任务的一部分被发现。比方说，来自应用的数据可以直接出现在组织的搜索结果当中，正如你从 Figma 打造的体验所看到的那样。你可以撰写邮件，然后把嵌入到这些应用的文件@给某人，也可以在 Teams 聊天当中访问它们。建立交互式体验还有一种方式，那就是像我们的合作伙伴 Zoho 那样，用适配卡片来开发实时可操作的循环组件。用户可以做出决定并采取行动，比如在工作流程当中更新工单的状态，并且更新始终是实时的，就像这条跨越 Outlook、Teams 和 Zoho 之间的同步更新一样。
一旦把 Microsoft Graph 与 Microsoft Teams 结合在一起使用，就可以将描述人们如何共同工作的数据与他们一起工作的地方结合到一起。这种做法非常强大，开发者正在将他们的应用扩展到 Teams，并将 Teams 嵌入到他们的应用里面。事实上，在过去两年里， Teams 上面的第三方应用与定制解决方案的月使用量已经增长了 10 倍，越来越多的 ISV 从客户身上赚到了数百万美元的收入，而这些客户用的正是基于 Teams 开发的应用。
“Graph 连接器”是新的 API。
Windows Vs Teams
如果 Windows 平台看起来是像这样的话……
……那么新的 Teams 平台看起来就像下面这样：
关于这两者的差别，有若干重要观察。
首先，在 PC 时代，能带来实际意义的垄断是成为单一设备上唯一的操作系统。需要明确的是，在技术上这是必然的，虽然 PC 支持双启动，可以进入不同的操作系统，但每次只能运行一个操作系统（虚拟化除外，但在 Windows 正在掌握主导地位的当时，用户级的 PC 做虚拟化基本不可行），但它是 Windows 市场垄断的基础。毕竟，大多数设备大多数时间内跑的是哪个操作系统，那个操作系统就是开发者的目标。特定操作系统上的开发者越多，这个操作系统在最终用户当中的流行度就越高，从而形成良性循环，也就是双边网络，或曰锁定，也即垄断。
然而，随着移动设备的出现，不仅设备的数量激增，而且对新的用户界面、电源要求、硬件再想象等的需求也在激增；微软错过移动设备是必然的，因为这家公司从完全错误的角度处理了这个问题。与此同时，设备的这种激增意味着企业仍然渴望的集成点开始向上移动。我在 2015 年的《雷蒙德与现实》中写道：
那是因为其实在移动设备端需要有集成解决方案。比方说，不妨看看 Box：这家公司显然有一个云组件，但在每一个相关或不相关的平台上他们也有多个应用，其结果是功能性方面要比微软之前的产品要好得多。把这种优势推广到一系列的服务上，对于 CIO 来说，将后端服务模块化就有意义了，因为访问这些服务的时候能够集成到一起了：
云服务出现前后的对比
这正是微软要用 Teams 继续开发的东西：就像任何社交产品一样，聊天应用的美妙之处在于，它的用处取决于使用者的人数，也就是说，只有在垄断，也就是公司人人都需要参与进来的情况下，聊天才管用，除此以外，再也不需要用其他任何东西。引申开来，Teams 就可以扮演 Windows 的角色，但它垄断的不是个人 PC，而是整家公司。
其次，开发者在旧模式下权力和灵活性更大，因为他们可以直接访问底层 PC。这种模式既有优点也有缺点。优点是人人都可以开发可以做任何事情的应用，用户可以直接安装使用；缺点也是人人都可以开发可以做任何事情的应用，用户可以直接安装使用。换句话说，PC 的开放性为 Firefox 和 Chrome 提供了取代 Internet Explorer 的机会，还有为 Netscape 的存在提供了机会，但也为病毒、恶意软件和勒索软件提供了机会。
这最后一点是苹果再三为自己的应用商店模式辩护而诉诸的理由，尽管移动设备安全性的提高，在很大程度上是由于在设计底层操作系统时做出了根本不同的架构选择。话又说回来，这些观点其实是紧密相关的：正是 iOS （以及 Android）设计当中做出的那些架构选择，才使得应用商店的控制成为可能；就更广泛意义而言，是移动设定了这样一种预期，即开发者的自由——以及进一步的机会——都将受到操作系统所有者的限制。
像 Teams 这样的瘦平台又更进了一步，因为现在开发者甚至连设备都无法访问，至少是在对企业来说很重要的东西无法访问（比方说，如果手机上的 app 不能连接到公司的目录、文件存储、网络等等的话，那还有什么用呢）。这意味着，问题不在于哪些系统 API 被禁止使用，而在于平台所有者打算开发哪些“连接器”（connector，用微软的话来说）。换句话说，微软不仅把自己的新操作系统开发成了一个瘦平台，而且与他们所用的旧平台相比，他们最终获得的控制权也要高得多。
Stripe 的操作系统
Build 不是最近召开的唯一一场开发者大会：Stripe 也举办了 Stripe Sessions，主旨演讲的主要内容之一叫做“Finance OS”。来自 Stripe 联合创始人兼总裁约翰·科里森（John Collison）表示 ：
我们讨论了支付，以及支付是如何具有高度的战略性，还有正在快速的碎片化，我们还讨论了适配能力强的企业与金融科技无所不在的商业模式创新。这些趋势对互联网经济来说是个好消息，但对财务和业务运营团队来说却是挑战。对于那么多的新机会来说，限速器并不是好产品的点子，而是司空见惯的那些基础。 ‘我们能为这些机会打造出来东西吗？我们能开展国际业务吗？如果我们仍然不能按时结算的话，还可以扩大规模吗？’这不只是有没有好产品的点子的问题，而在于点子能不能实施，所以我们正在开发一套现代的金融操作系统，就像任何好的操作系统一样，我们专注于打好基础。
这些基础包括开票、计费、税务、收入确认以及数据管道等功能，所有这些都位于 Stripe 已经抽象出的各种资金的收集、存储和分配手段的基础之上：
Stripe OS 操作系统
鉴于与前面微软的那张图的相似性，这张图其实已经清楚地说明了接下来会发生什么：
刚刚我们介绍了核心的收入管理功能，如开票、订阅计费以及税务处理等。就算你没用过 Stripe，这些应该也都是你希望能运转顺畅的东西。
但是其他一切呢？就像任何的操作系统一样：核心功能需要开箱即用，但平台功能的广度也很重要，要有一个应用可以搞定每一个用例。对于类似客户沟通之类的事情来说，你也许想要像 Intercom 这样的东西；对于签合同来说， 也许希望有 DocuSign ；或者，你可能就想自己开发工具。但是这些工作流往往是高度集成的，所以这些年来我们的用户一直都希望 Stripe 能够实现跟他们选择的工具进行互操作......
所以，很高兴地在此宣布，我们今天推出了 Stripe Apps 以及 Stripe App Marketplace，在这里，你可以找到或者自己开发能与 Stripe 顺畅协作的同类最佳工具。
不过他们的拼图还不完整！
Stripe 的瘦平台
“与 Stripe 顺畅协作”并不只是意味着访问 Stripe 的 API；还意味着适配 Stripe 的仪表板—— Stripe 甚至内置了预制的 UI 组件，这样第三方应用看起来就像是由这家金融科技公司设计出来的一样：
Stripe 提供了用于集成到 Stripe 仪表板的预制 UI 组件
这就是又一个瘦平台：开发者既没法访问一家公司的核心财务数据，而且 IT也不希望他们这么做；相反，机会出现在一个抽象层之上，这个抽象层涵盖了一家公司所有与资金流动的部分，而且要尽可能地适配。
当然，我之所以要把 Build 和 Stripe Sessions 的主旨演讲放到一起讲，是因为这两场大会正好都是在同一周举办；但同时，这也是一次偶然的巧合，因为 Stripe 的发布为微软的方案提供了重要背景。毕竟，我用到了“垄断”这个咒语；不过，事实上，操作系统的垄断不仅不可避免，而且从用户的角度来看，类似浏览这样重要的功能与核心操作系统集成在一起是完全合理的。
科里森解释了为什么类似的考量应该是瘦平台的首要考虑因素——有些事情“你应该希望能够运转顺畅”。对于 Teams 以及整合文件存储和沟通手段等，微软也会提出类似的辩解，而且我认为，相对于 Slack，Teams 在市场上取得的成功证明了微软的辩解对客户来说是令人信服的。微软似乎往往是唯一一家真正为企业的目的而打造的企业，它并没有自顾自地痴迷于成为某种特殊手段的同类最佳，这似乎值得颂扬和效仿，而不是谴责和抱怨。
同时，胖客户端模式的黯然失色也值得哀悼。是，类似恶意软件之类的东西令人烦恼，是对生产力的消耗，而 SaaS 模式使得企业不需要 IT 部门就能用上大量新产品，胖模式的一大缺点是可能会出问题的地方，所以需要有 IT 的存在，而这又为巨大的优点创造了条件，在本文背景下，这一优点是指为不需要任何许可、“连接器”或预制 UI 组件来开发新应用（以及引申而言的新公司）提供了机会。唉，科技行业“开始的终结”已经过去了。人近中年，唯一变胖的只有你的腰围。
（36氪）
