这是传统开放核心模式的倒置，传统开放核心模式是企业应用层产品的许多商业开源策略背后的模式。在开放核心中，产品的核心是开源的，而在企业版中，供应商提供和支持专有增强功能。使用API方法，产品的核心通常在云端不可见，进出产品的唯一方式是通过API。
由于API，我们看到企业版本通过工具、小部件和组件迁移到边界后的区别、增强和价值。这些可以是闭源和/或开源，但是我们会在边界上看到更多的开源，因为许多供应商可以通过支持核心和对调用API或交易收费来赚钱。两个最好的例子是Twilio和Stripe。
这就像装修房子
了解这种情况的一个简单方法是将其与装修房子类比。如果你想在现有的房子里加一个新卫生间，通常需要雇佣一个水管工和总承包商。水管工带来管道，并将它们装好。然后，承包商围绕这些管道建浴室。
大多数人通常不在乎，甚至压根不想知道这些管道从哪里来、如何连接到普通管道系统。我们只是知道输入是什么和输出会是什么样（干净的水）。我们需要它们能正常工作。我们有一个被普遍接受的服务水平协议（SLA），这是一个关于如何管道应该工作的性能预期。如果我们冲厕所，一切都应该消失在管道（API）中。当我们打开水龙头时，饮用水需要以一定的压力流出来（另一种API性能SLA）。
这里的要点是，我们需要的唯一信息是API（管道）如何执行。这个业绩预期就是SLA。如果你正在设计卫生间，你要花时间考虑要购买的水槽的风格、要安装的瓷砖类型，以及新浴室的整体布局。这种“外观和感觉”是我们为家增加的价值。我们还需要付钱给水管工人，但如果你每次要装修卫生间或厨房都得重新折腾整个房子的管道，你会发疯的。这里的创新已经从核心转移到了边界。
这正是伴随着API的兴起所发生的。开发人员意识到，从供应商那里采购高性能API可以让他们专注于增值服务。
典型的开放核心应用
来看一些使用开放核心模型的开源企业软件的典型例子。
- Sugar：Sugar CRM使其源代码可供客户和合作伙伴使用。Sugar的企业版增加了特定的企业级功能，例如增强报告、更好的工作流和其他企业特定功能和附加组件。
- JasperSoft：JasperSoft提供开源商业智能报告。早在2007年，就有超过30,000个开发者在其社区注册。Jasper提供SDK和RESTful API来与其产品进行交互。
- Odoo：Odoo的开源企业资源规划（ERP）应用已经成为专有软件的一个非常受欢迎的替代品。围绕其开放核心，Odoo及其合作伙伴渠道已经增加了数百种不同的付费模块，扩展了开源核心。核心框架包含大约30个模块，社区还创建了数千个模块。其中一些是免费的，但许多其他的是付费和封源的。
- ProcessMaker：ProcessMaker提供开源业务流程管理（BPM）和工作流软件。开发人员可以使用JavaScript和PHP来增强开源版本。ProcessMaker提供了一系列企业插件，包括Advanced Active Directory集成、仪表板和增强的开发人员工具。
采用开放核心模式的许多软件公司在初始开源项目获得了显着牵引力（即数百万次下载）之后就这样做了，所以他们组建了一家支持开源代码的公司。逐渐地，这些公司根据开源开发出扩展和订阅。随着云和软件即服务模式更加突出，这些公司通常根据开源核心开发出云端版本，以进一步把自己的产品和开源版本区别开来。
也许许多开源产品被迅速采用的两个最大的驱动因素是开源许可，和通过像SourceForge这样的下载站点实现的无摩擦分发模式。
有什么变化
这种商业化开源模式在20世纪90年代末和21世纪初变得普遍。然而，业界正在发生改变：API兴起。 API由于以下几个原因而变得越来越重要：
- 需要构建更多可扩展的软件
- 需要构建更多的连接软件
- 需要加快创新步伐
- 需要应对日益增长的复杂性
软件越来越复杂，必须连接到更多类型的应用程序，并且必须扩展以处理更大的需求（数量级上的变化）。结合这三个因素，你很快就会意识到为什么API非常重要。
开发人员不能再开发单片代码库并允许其他应用程序连接到它，不论他们多么希望并期望维护软件和确保它在规模化时表现良好。API是两个或多个服务彼此交互的明确的和被推崇的方式。通过了解另一个软件期望如何与你的软件一起工作，你可以保持质量，并根据这一期望进行判断，即使你的软件发展壮大。
基于API的商业模式
一些公司已经适应了基于API的商业模式。这里有几个：
- Twilio：Twilio提供与通信相关的API，以支持消息、语音和视频。 Twilio在市场上提供了通过其API与Twilio集成的第三方加载项。附加构建器利用Twilio提供的内容，并利用来自自身来源的信息进行增强——产品随后作为API发布。
- Stripe：Stripe的付款处理平台提供一个RESTful API来提交付款，每年处理数十亿美元的付款。第三方扩展通过为用户的Stripr帐户提供API请求来提供其他功能。还有第三方库支持开发和插件，使Stripe能够与其他产品一起工作。
- Factual：Factual为移动广告和其他移动应用提供基于位置的数据。它提供了一组API，开发人员可以使用它们构建与Factual的产品集成的扩展。一些Factual的位置数据可通过下载许可证提供给合作伙伴。
- ProcessMaker I / O：ProcessMaker I / O提供了一个工作流即云微服务。企业ISV可以使用ProcessMaker API将企业工作流功能添加到其产品堆栈中。工作流API可以连接到任何后端，并可以扩展到每秒数百万个交易。开发人员可以使用Java、Python、JavaScript、PHP或其他语言的SDK来连接到API。
- Form I / O：Form.io提供强大的API来管理Web表单。这些Web表单可以填充任何类型的无服务器架构的数据源。
API模型的优点
API模式对开发人员有实打实的好处。开源和开放核心意味着不断变化，会产生因为不定期的副作用而导致的风险（不管有没有测试，多少测试）。通过忽略产品内部核心而偏向API模式，开发人员可以专注于使用提供可靠行为保证的已暴露功能。这样可以在应用程序的外围实现更快的创新（而且更多），而不是慢慢地修改核心——这样的话你需要更深入地了解项目才能实现创新。
由于API可以提供与不同后端系统相同的功能，因此API方法可以访问供应商支持的应用程序，同时长期来看可以降低供应商锁定的风险。当然，在短期内，与供应商的API挂钩意味着你将依赖该API。如果这个API挂了，你的应用程序必须知道如何处理它。但始终不符合SLA的API提供商将被更可靠的提供商所取代。竞争对手复制API相对容易，这为开发人员提供了安全性——如果需要，可以替换API。
开发人员可以独立于后端测试API的功能，并专注于将这些专门的微服务组合到需要创建的更大的应用程序中，从而支持业务用户。他们可以专注于核心竞争力，即专门的业务知识，而不是基础设施。更重视业务知识意味着最终产品更符合业务需求。
小供应商将发挥更大作用
考虑到API是应用程序的新管道（因此也是互联网的新管道），很难想到小型提供商可以改变。但他们绝对可以。API服务以惊人的速度增长；它们是长尾创新的真正新驱动力。原因是API可以暴露真正的微服务。然后，开发人员将这些微服务混合到有意义的应用程序中。
预计经过几年的大规模API扩散，我们可能会开始看到API整合。但是离这种情况出现还有一段较长的时间，在这之前，较小的供应商会在API经济中扮演重要角色。
