第二象限购买对PostgreSQL社区的影响

这篇博客是关于我在Postgres开源数据库上的工作，并发布在Planet PostgreSQL上。PgLife允许监控所有Postgres社区活动。

上周第二象限被EDB收购，虽然这对这些公司来说当然是个好消息，但也会增加Postgres社区的风险。首先，有一条不成文的规定，Postgres核心团队的成员不应超过来自一家公司的一半，此次收购导致法国开发银行在核心团队中的代表性达到60%-核心团队正在为此制定解决方案。

其次，两家公司合二为一减少了Postgres用户对支持和服务的选择，特别是在北美和西欧市场。供应商选择的减少通常会导致客户服务质量变差，创新减少。因为Postgres社区进行自主创新，所以这可能不是社区软件的问题，而可能是Postgres周围的公司控制的工具的问题。

第三，有一种风险，即一家想要伤害Postgres的更大的公司可能会收购EDB，并将其带向对Postgres社区中立或负面的方向。员工互不竞争协议，以及缺乏其他Postgres支持公司可能会延长这些影响的持续时间。除了对问题保持警惕之外，社区也没什么办法将这些问题降到最低。

这篇长篇文章描述了管理开源项目的许多挑战，以及资源分配(例如，资金)和软件对经济活动的重要性之间的不匹配。它强调OpenSSL是一个例子，在那里，有限的资金导致了开发人员的倦怠和安全漏洞，尽管互联网的基础设施如此之多地依赖于它。

对于专有软件，软件成本和其经济价值之间通常是有联系的，尽管这种联系差别很大。(软件成本中有多少投入到软件开发、测试、错误修复和安全分析中，可变性更大。)。有了开源，联系就更少了。

本文探讨了增加联动性的多种方法。这是一个复杂的问题，既要获得资金，又要以一种有助于而不损害开放源码社区的方式分配资金。

Postgres在这方面是幸运的。来自红帽和日本公司(富士通，NTT，SRA)的资金帮助支持了社区早年的关键邮政活动。数据库软件的特殊性质形成了Postgres社区十多年来拥有健康的基础设施、治理、管理和贡献者的环境。

在个人层面上，我们确实看到了这些问题。一些贡献者承担给他们带来很少或没有短期好处的任务，同时招致巨大的时间和情感成本。一些用户要求社区提供最少的信息，假设我们会猜测他们的意图，或者我们会在他们不做任何研究的情况下深入研究他们的错误报告。我经常干脆把这样的电子邮件从我的邮箱里删除。我有时会收到请求帮助的私人电子邮件，因此我创建了一个常用的电子邮件回复，由于时间限制，我不会直接回答PostgreSQL的一般问题以及从哪里获得帮助的信息，例如电子邮件列表、IRC、FAQ。这篇Slashdot帖子很好地描绘了如何处理开源开发的许多需求。

开源已经成为主流至少有十年了，所以看看是否能找到被普遍接受的解决方案，或者即使开源软件的使用在继续增长，这是否会继续成为一个令人困惑和令人头疼的领域，这将是一件有趣的事情。

在看到Postgres多年来变得越来越受欢迎后，我发表了一条评论，我看到我的组织中有一些竞争团队，一些人提拔Postgres，另一些人则对此不屑一顾。我想出了这个图表(幻灯片23)，其中显示了通常参与决定Postgres采用的三个群体。这些组是管理者、管理员和开发人员。在这个图表中，每个小组都有激励他们的事情列在小组名称下面。

当三个群体都看到Postgres的价值时，Postgres的采用最顺利。当与公司中的不同群体交谈时，你应该考虑是什么激励了你正在与之交谈的群体。您还会发现该图表有助于确定哪些团队对Postgres不感兴趣，以及如何激励他们。

发表评论自从开源成为软件界的一股强大力量以来，它已经经历了几个阶段。第一阶段是围绕大学和志愿者建立的，几乎没有商业参与。随着开源的发展，像Red Hat这样的公司被创建来简化企业中开源软件的部署。随着开源的流行，以开源方式分发软件，但由公司控制的公司开始激增，比如MySQL。开放开发的开源软件和公司开发的开源软件之间的区别仍然没有得到广泛的理解。一个很大的区别是，对于公司开发的开源软件，公司控制着开发过程，并承担开发的全部成本，这会导致更大的客户锁定和潜在的未来成本，因为公司会最大化其利润。

云供应商已经颠覆了许多围绕开源构建的公司的计划。虽然开放源码经常因为其快速的扩散和部署而受到供应商和客户的重视，但人们总是希望开放源码软件的专业知识能够产生足够的收入机会。颠覆了他们的计划的是云供应商，他们已经通过提供云框架建立了客户关系。他们使用开源软件作为向云客户的追加销售，绕过了专门从事开源的供应商。这篇出色的文章揭露了这种转变的大部分内容，特别是下面这句话：

从经济的角度来看(这也是所有行业的想法和类比)，与围绕特定项目建立的公司相比，云似乎从开源中创造了更好的业务。如果你眯着眼睛看，开源可以被视为对地球上一些最大和最富有的公司的非常慷慨的慈善捐赠。

它不是开放源码供应商提供的供潜在客户使用的软件，而是被实际的竞争对手使用，这些竞争对手通常要大得多，也更显眼。这就是开源的问题，以至于你不能轻易地控制它的使用方式，尽管一些公司开发的确实控制软件许可证的开源公司正在采取措施避免这种情况，云供应商的反应是可以预见的。

在阅读这篇文章时，对我来说最重要的时刻是对红帽的分析。公司开发的开源公司总是面临风险，因为它们承担了软件开发的全部成本，并且有一个明确的货币化战略-增长，然后最大化货币化，但红帽不同。它是纯粹开源(从别人那里收集和捆绑)的典范，本应该更不受云的影响，但博客中的图表清楚地表明，IBM收购RedHat是因为RedHat上的云竞争。这篇来自同一个人的博客文章涉及到更多血腥的细节。

目前还不清楚开源货币化的发展方向。如果云供应商够聪明，他们就会让致力于开源的公司生存下去，并有足够的收入继续为开源开发和创新提供资金。虽然开源公司的估值往往很高，但它们很少获得高利润，或许除了几年前的红帽(Red Hat)。对于开源公司来说，高利润的世界现在似乎更遥远了，因为云供应商凭借现有的客户关系、大规模标准化的基础设施和服务以及规模经济，从这些业务中吸走了更多的利润。

发表评论，云供应商就像百货商店一样是障碍，超市也是障碍。哈?。人们将这些实体与在一个地方提供种类繁多的商品和服务联系在一起。那怎么可能是障碍物呢？

嗯，你是从消费者的角度来看待它的。对于制片人来说，它们是喜忧参半的。这些超级卖家可以让大多数单一产品生产商进入更大的市场，但对生产商来说也有负面影响：

作为实体产品的生产商，与百货商店和超市合作是积极的还是消极的，这取决于你。然而，有了开源软件，就没有微积分了。除非您的开源许可证禁止在云服务器上修改或未经修改地托管您的软件，否则您无法控制云供应商是否是消费者与您所管理的源软件交互的方式。云供应商负责下载、配置、可能支持软件，并保证正常运行时间。云供应商可以利用软件收入机会。为避免使用云，一些软件生产商选择或创建了限制此类使用的许可证：

为了响应Elasticsearch的许可证处理，AWS(1，2，3)派生了Apache2.0许可的Elasticsearch源代码，并开始编写代码来替换专有功能。有时，即使更改许可证也不能保护开放源码项目免受云供应商的障碍。

这不是什么新鲜事。像RedHat这样的商业公司从一开始就支持开源软件，并从这种关系和捆绑中获得了收入。云供应商与其他一组使开源更易于使用并从中受益的公司完全不同。虽然像Red Hat这样的软件捆绑包供应商可以为他们的捆绑包定制软件，但是云供应商也可以为他们的硬件和基础设施优化软件。这对客户来说是显而易见的价值，软件生产商很难与之匹敌。

本文讨论了开源商业模式的历史，本文将云供应商的行为描述为露天开采。甚至在最近的一次会议上，开源供应商开会讨论如何应对云供应商的竞争(由AWS赞助)。

在我上面列出的所有开源软件产品中有一个很大的区别-它们都是公司控制的开源，这意味着开发大多由一家公司控制，该公司将软件的使用货币化，同时将其作为开源分发。这与Postgres等社区控制的开源项目截然不同。来自云供应商的社区控制的开源项目面临的挑战要少得多，主要是因为没有盈利目标。有些人担心云供应商与用户的关系会减少社区的贡献，但目前还不清楚这是否属实。云供应商显然增加了社区控制软件的使用，并且在一定程度上，云供应商在与客户的交互中引用了开源社区，这对社区有所帮助。

就像面包店、花店、农产品市场、肉类、奶酪和海鲜销售商在超市提供方便的(尽管多样性较低)产品时挣扎求生一样，公司控制的开源将受到云供应商的影响。对于开源社区来说，唯一真正的风险是支持其开源开发人员的公司会举步维艰，从而减少从事开源项目的付费开发人员。从开源项目的角度来看，这种联系很难衡量，所以我们只能拭目以待。

发表评论大多数公司都有营销和销售人员作为他们公司的可见部分。技术人员，即使是在技术公司，也经常被留在后面，只有在需要的时候才会被带出来短暂的时间。开源则不同--没有营销或销售团队，所以软件开发人员是项目的代言人。这给了技术人员一个机会，让他们的努力得到世界范围的认可。没有多少地方可以让技术人员真正大放异彩，但开源就是一个这样的机会。

发表评论Postgres今年就34岁了。迈克尔·斯通布雷克(Michael Stonebraker)在2015年图灵奖演讲(我之前曾在博客上谈到过)中，包括了帮助撰写原版Postgres的39名伯克利分校学生(加上联合领导人拉里·罗(Larry Rowe)的名字)。我原本希望将此列表添加到Postgres发行说明中，但我们最近不再在当前版本中包含Back分支发行说明，所以现在没有放置它们的好地方。为了感谢他们，并在社区的帮助下，我将他们罗列如下：

我从C评论中知道了一些名字和首字母。就像我们这些在Postgres上工作了几十年的人一样，我怀疑他们是否怀疑他们的代码会在这么多年后被使用。

发表评论我最近写了一篇演示文稿，名为Postgres and the Artially Intelligence Landscape，它涵盖了人工智能的基础知识，并展示了Postgres如何用于这一目的。本周，我在芝加哥PostgreSQL Meetup Group上展示了它，所以我现在发布幻灯片。

查看或发布评论Postgres在添加与专有数据库相匹配的功能方面取得了很大进步，它拥有许多其他数据库所没有的复杂功能。然而，这并不意味着它是最适合每个组织的。仍然有理由不使用Postgres：

为您不想修改以使用Postgres的另一个数据库编写的自定义应用程序

这个电子邮件帖子有很多关于这个话题的讨论。有趣的是，几十年来关于缺少功能、可靠性和性能的抱怨不再被提及。

查看或发布评论数据库应用程序最初是使用尽可能简单的查询编写的。在测试和生产过程中，某些应用程序任务的性能可能无法接受。这是重新架构发生的地方，也是简单查询和数据模式布局可能变得复杂的地方。它们可能会变得复杂，因为它是完成任务所必需的，或者可能是因为数据库软件处理某些查询的方式的限制。数据库和工具升级可能需要进一步复杂的添加。

当切换到Postgres这样的新数据库时，所有的复杂性都随之而来。有时，为解决其他数据库中的缺陷而添加的复杂性在Postgres中工作得很好，但通常必须删除这种复杂性才能在Postgres中获得良好的性能。在Postgres中也可能需要增加复杂性才能获得良好的性能。

底线是复杂性对应用程序不利，因此只有在必要时才增加复杂性。明智的应用程序开发人员定期删除不必要的复杂性，但很难知道数据库升级是否使某些复杂性变得不必要。移植到新数据库是重新评估是否可以简化应用程序的理想时机。

查看或发布评论我最近写了一个演示文稿，名为Postgres in the Cloud：The Hard Way，它展示了如何创建云实例，以及如何完全从命令行安装和运行Postgres。这有助于显示所有部件是如何装配在一起的。我最近在pgDay以色列会议上展示了这一点，所以我现在发布这些幻灯片。现可提供演示文稿的录音。

查看或张贴评论如果我经常开同一辆车，那会很容易，但由于我的家庭规模和出差，我没有那种奢侈品。我开的一些车有智能钥匙，一些机械钥匙。一些汽车的油箱门位于司机一侧，另一些则位于乘客一侧。它们的方向盘不同，加速能力不同，甚至服务要求也不同。我已经习惯了换车，但当我必须给车加油时，我仍然感到困惑，因为我必须记住哪边有油箱门。

如果我多年来一直开同一辆车，换辆不同的车会更难--这就是人们从其他数据库迁移到Postgres的情况。他们经常驱动相同的汽车/数据库数年，甚至数十年。他们知道这些数据库如何运行的错综复杂，即使是普通的数据库供应商员工也可能不知道。切换到另一个数据库可能是背叛的，特别是当他们的工作依赖于可靠运行的数据库时。他们可能有各种各样的技巧和程序来确保正常运行时间，而且，当切换数据库时，是否应该修改或放弃这些程序以及需要哪些新程序并不总是很清楚。

有一些任务对于所有数据库都是通用的：SQL、备份、故障转移、性能监视，但是如果有从一个数据库移动到另一个数据库所需的所有更改的小抄，那就更好了。有一些从其他数据库切换到Postgres的指南，但它们不能涵盖所有细节，而且许多用户过程都是基于他们的工作负载。甚至不可能总是知道工作负载在Postgres中的行为。

目前还不清楚我能给转向Postgres的用户提供什么确切的建议，除了审查所有现有的程序，以确定它们是否仍然有必要或需要修改，以及是否需要新的程序。有一件事是肯定的-将需要更改，严格遵循以前数据库使用的过程不是一个明智的计划。

查看或发表评论我在开源领域工作了几十年，每一个成功和失败都是众所周知的，我一直想知道专有的开发是如何做的，特别是对于数据库。我从以前的员工那里了解到了这个世界，但这个Y Combinator主题是我见过的关于Oracle开发的最广泛的观点。它为所有开发人员提供了有用的经验教训，并对其他关系数据库的源代码进行了评论。

我首先想到的是，员工们似乎被源代码的复杂性搞得不知所措。代码清理从来都不是一件有趣的事，但它对于高效编码是必要的。对于公司来说，很难证明开发人员花在代码清理上的时间是合理的，因为清理的好处对于每项任务来说往往微不足道，但随着时间的推移，总的来说是巨大的。代码清理很少能与直接交付内容捆绑在一起，因此它经常被忽视。对于开源来说，干净的代码鼓励开发人员将他们的空闲时间花在编码上，所以有更直接的动机去做清理工作，而且开源的交付内容是不那么僵化的。帖子里提到了Postgres：

我确信其中一些差异(2500万个[Oracle]比130万个[Postgres})可以归因于PostgreSQL中缺少Oracle功能的代码。但这在很大程度上要归功于仔细的开发过程，作为常规PostgreSQL开发周期的一部分，无情地消除了重复和不必要的代码。

一开始有点让人心碎(你花了几个小时/几天/几周的时间在某件事情上)，然后一个(Postgres)黑客同伴来了，砍掉了不必要的部分，但从长远来看，我很感激我们这样做了。