dave.page's picture
Author: Dave Page
1/4/2018

When it comes to enterprises deciding on whether to adopt open source software or commercial software based on open source it can lead to fierce debate about the relative merits of these different approaches. EnterpriseDB® (EDB™) provides a data management platform based on the open source project PostgreSQL and it stands at the junction of open source and commercial software. We have a number of executives who are also members of the PostgreSQL community so we are acutely aware of the fine line between open source software and proprietary offerings built on an open source foundation.

EDB believes open source and commercial solutions based on open source offer customers choices and different levels of value. For any software to truly be open source it must provide unrestricted access to the source code, allowing contributors to use it and adjust it according to their requirements. This also ensures a far greater degree of transparency than you might traditionally have with proprietary software, which is good when it comes to identifying vulnerabilities in software.

Where things can get confused is when commercial vendors, like Red Hat or EnterpriseDB, offer products, tools, and services on top of open source code, which come with subscription fees for both software and 24x7 support. Open source software is free of charge if self-supported, but may also come with a subscription fee for 24x7 support. The distinction between these options gets even more confusing when some vendors label their proprietary software as open source to indicate that it offers lower cost as a result of being based upon an open source foundation.

At EDB we are very clear that in addition to packaging open source PostgreSQL, we also offer products, tools, and support built on top of PostgreSQL that are proprietary. This means customers do not have access to the source code for our tools and cannot attempt to add to or change the products beyond using supported extension APIs. We offer this functionality because our customers want it. Their priority, particularly when adopting PostgreSQL in enterprise environments, is more direct control with a vendor for security patches and bug fixes, the ability to have more influence and visibility over future product roadmap features, and to have the reassurance of 24x7 support to maintain their mission critical applications. We also build new features in the community if we believe it will benefit the open source project, while some features remain proprietary to EDB. We believe in contributing to the PostgreSQL community project. We are committed to maintaining and growing the appeal of PostgreSQL because the more mature the platform the more likely it will be attractive to a broader set of users. This benefits everyone.

We also provide a version of our platform with open source PostgreSQL with 24x7 support and enhanced by our tools. This does mean there can be grey areas in the sense of how the software is adopted and used, but we believe our approach with customers is transparent, which we consider essential for any vendor providing commercial services in connection with open source software.

So how do you decide which approach is best? For some users, being able to access the source code is important as it enables them to be part of an active community that is regularly committing updates to the project. Additionally, as the software is not “owned” by one company there is less likelihood of vendor lock-in—an age-old problem in the enterprise software market. It also offers greater transparency, because one vendor is not attempting to protect intellectual property.

However, as Gartner has pointed out, most enterprise customers are not interested in accessing the source code but want the open source price point.[1] This is where EDB believes it adds additional value for enterprise customers; they can continue to use the open source version of PostgreSQL if they want, but EDB provides tools and support that offer relevant functionality, like high availability and disaster recovery, required for enterprise environments. This approach offers customers flexibility, especially for those wanting to move off Oracle®. Postgres has shared relational heritage with Oracle, which makes migration between the two easier.

An organisation migrating off the Oracle database platform might elect to pilot an application using open source PostgreSQL. However, as these organisations get more used to the platform or their applications become more critical, a migration to the EDB Postgres™ Platform often becomes that next step in their migration journey. This gives enterprises more than just the database—a complete supported suite of tools, utilities, drivers and more—but it does mean that some functionality is proprietary to EDB, such as the performance and security tools, and the Oracle Migration Toolkit. Equally, because the EDB Postgres Platform is based on PostgreSQL, it also means migration for customers back to the open source version is very straightforward. If a customer does decide to leave EDB, unlike traditional commercial licencing, there is no heavy handed audit process and threats to pay large outstanding bills. EDB’s subscription model means users have a transparent, predictable payment structure that simply comes to an end when the customer decides to terminate the contract. This helps to address a common issue with traditional commercial software, namely vendor lock-in.

If you are a business evaluating open source and commercial solutions based on open source, there are some critical questions you need to consider. First, your business needs to decide on your business objective and how the adoption of a particular software solution will help you to fulfill that goal. Particularly in a business environment, open source can provide access to a dynamic and innovative platform that can help your business to respond quickly to market opportunities. It can also lower the cost of investment in research and development. However, not every open source project is the same. Some are run by hobbyists or have been developed with a single purpose in mind.

Therefore, you need to consider these additional points:

  • Open Source Licence Type:  Are there restrictions on the open source licence that could cause problems? There are several different types of open source licences, each with its own set of limitations. For example, a GPL licence requires users to open source derivative works which can be problematic for some businesses. AGPL licences can be even more restrictive for many SaaS businesses. The PostgreSQL licence is one of the most open, with no restrictions on derivative works at all.
  • Community processes:  Does the community release regularly? Does it have a clear process for updates? How is the software supported? If it looks unclear how the community operates then you may not have the consistency and quality of approach you need when considering such software for a mission-critical business environment.
  • Community structure: How is it decided which code updates to accept? If the group is run by one individual or vendor this can lead to challenges. The agenda could be heavily skewed in the favor of one vendor, which could make it difficult to get updates accepted.
  • Software purpose:  What was the software originally designed for? Does it have the ability to evolve to meet a broader set of requirements? This is an important issue, because often an open source project was started by one individual, who wanted to solve a problem. For example, Linus Torvalds and Linux. It survived because it evolved.
  • Community size: Is it important that the group is large? No. Size isn’t everything. It is more important to ask, ‘how active is the community?’ While the PostgreSQL community is reasonably large it is not huge, but this is good, because it has a manageable structure and it has been able to instill a specific set of processes and guidelines that community members adhere to. The larger the group the more likely it is to become unmanageable and lead to forks.

Ultimately, our customers choose the model that suits their businesses best, because there are different benefits to open source and commercially backed software based on open source. We believe our strong and positive relationship with the PostgreSQL community offers great value to the community and its specific customers. It means more flexibility and choice in an era when budgets are constrained, but the demand for rapid innovation is growing.

Dave Page, Vice President & Chief Architect Tools and Installers, EnterpriseDB and Core Team member of the PostgreSQL Global Development Group

[1]The State of Open Source RDBMSs, 2015, by Donald Feinberg and Merv Adrian, published April 21, 2015.