To build or to buy: Customize an open-source tool or license a commercial product?

When teams across data-driven organizations need to work faster, more efficiently, or in new ways, they’re faced with a difficult and critical decision right off the bat:

Should we purchase an off-the-shelf solution or choose a free open-source option and upgrade it in-house with necessary features using internal development resources? 

Another common scenario: experiencing growing pains with the open source software that has suited the team’s needs well for years. When it gets too difficult or costly to maintain and enhance customized open source solutions, teams find themselves asking each other:

Do we continue to invest in this custom build – or is it time to license a purpose-built platform?

Developing homebuilt solutions on top of community-driven open-source projects is sometimes the best way to get the custom, purpose-built capabilities a team needs. Yet costs like development time and resources to build, optimize, maintain, and enhance the project might reach a breaking point as business units and pipelines scale and evolve. 

Should you build or should you buy? That’s the question posed to Liquibase’s VP of Product Loreli Cadapan and Stephen O’Grady, principal analyst and co-founder of the developer-focused analyst firm RedMonk. In an on-demand webinar, these two seasoned tech leaders discuss:

• Why open-source options are appealing and expanding
• Signals that teams are outgrowing their custom open-source tools
• The crucial discussion that determines build vs. buy

Explore some of their insights below. Plus, examples of how Liquibase users approach the decision and when it makes sense to upgrade from Liquibase Open Source to Liquibase Pro. 

The age-old question: To build or to buy

Open-source projects are growing. The 2024 State of Open Source Report puts data behind what experts Cadapan and O’Grady observe as a general increase in the number of open source options available. Nearly all of those surveyed (95%) are increasing or maintaining use of open source tools. Interestingly, enterprise respondents noted more significant increases than start-ups.

Leading reasons for choosing an open source option include:

• Lower costs (no license cost) – which jumped from the #9 reason in 2022, indicating economic pressures
• Improving development speed
• Available support from the community
• Stability supported by the community
• Reduce vendor lock-in

The State of Open Source also measured open source software investments by category. What category had the most open source investments?

“Databases and Data Technologies”

Open source adoption is expanding, including data stores & infrastructure

This prevalence of open source investment in database and data tools is no surprise to Liquibase’s product leader. Cadapan saw application development tools lead the open source charge for much of her career until the past few years when infrastructure-as-code tools have also swelled. Continuing that momentum, she sees database and data store services growing as the cloud-first approach reduces cost and increases flexibility. 

Cadapan and O’Grady agree that tech teams take the transparency of code in open source solutions to mean better quality and stronger security. They can easily lean on the community for support when needed and dive into the code to develop their custom features. 

But eventually, teams relying on open source solutions can reach a tipping point when the value of transparency and flexibility starts to wane as in-house development costs rise and need for advanced capabilities increases. 

O’Grady, who has worked with countless technology organizations, has seen teams outgrow open source projects quickly – and other times get by with them for years until they rethink their approach. They might be enticed by commercially supported platforms that offer:

• On-demand technical support
• More advanced features
• Training, support, or features that enable best practices
• Security and compliance assurance

He encourages teams to ask themselves certain questions to help guide their decision.

Build or buy? Ask these questions

After years of hearing from development and IT teams at companies around the world, O’Grady has some pretty clear advice: don’t build it yourself if you can avoid it. 

Why?

Catch the webinar replay for the full discussion, but turn to these questions as a starting point. O’Grady finds that after answering these, most teams find it’s an obvious choice to go with a paid platform built and maintained by category experts. 

Of course, some teams build upon open-source tools because there’s just nothing else available or because there’s other business value in that actual research and development of the in-house platform. Otherwise, before teams expand on an open source project, they should ask themselves:

• Can our team do a better job than the companies who build the paid tools?
• Can I sustain the internal support and development in the near, medium, and long terms?
• Do we have a plan for internal support if/when the existing project SME leaves?
• Is this a good use of the company’s resources – or should we focus on writing code unique to our line of business?
• What’s the total cost to build compared to buying a license?
• At what point will the return on internal investment materialize? What would make ROI go negative?
• Does this fit into the overall strategy of our company?

Essentially – is your team in the business of building enterprise infrastructure software or are you in the business of solving your customers’ problems?

Yes, building features and sharing them with the community is an encouraging industry trend and beneficial to everyone involved in the project. But developing your own unique feature code and then maintaining it, puts a lot of effort behind something not directly related to your competitive advantage in the market. 

Outgrowing open source

When the time comes to evaluate the build vs. buy decision, it typically takes a bottom-up or top-down approach based on practitioner needs or leadership directives. 

Bottom-up: practitioners need more

Developers love open source projects and often bring them aboard at their hands-on, practitioner level to solve discrete, unique problems in their pipelines. The open source tool works great – with a little tweaking, maybe – and gets the job done for weeks, months, even years. 

Then things change – the team needs more. So they develop what they need on top of the open source foundation. 

Eventually, complexities, regulations, security/compliance, and evolutions to the rest of the pipeline make it so that the open source solution needs a big internal development investment to keep it viable. It might also become so well adopted that it permeates the organization and becomes critical to business operations. At that point, developers and leaders all the way up to the C-suite might start asking, “What happens when something breaks?”

As requirements get more complex and the stakes get higher, teams using open source tools start to realize they need commercial support to turn to for problems, bugs, features, and best practices. It becomes evident that the investments needed to elevate security, adhere to compliance policies, and meet tactical needs is not a cost-efficient investment. 

What started as a solution to a developer’s tactical pipeline problem now becomes a barrier to the organization’s growth – and it's time to evaluate commercially supported software solutions. 

Top-down: leadership directives

In other organizations, the C-suite or other managers and leaders might question the value and scope of open source projects. On new or existing initiatives, this group might want to lead with strong commercial support for implementation, onboarding, best practices, troubleshooting, and ongoing guidance. 

In these cases, the value of comprehensive capabilities and rock-solid technical support outweighs the possible cost benefits of building a smaller, nimbler in-house tool. Especially in highly regulated markets, technology leaders have security, compliance, and reliability front and center. They need to have capabilities for auditing, governance, and compliance available from the start. 

Often, these advanced features and security protections are not available from open source projects, so teams turn to paid platforms for full-suite solutions. 

Here’s a clear example of the benefits that come with an off-the-shelf solution: choosing Liquibase Pro instead of developing a custom database change management tool in-house based on Liquibase Open Source. 

Time to buy example: Liquibase Open Source vs Pro

Liquibase originated more than a decade ago as an open-source project. It’s been downloaded more than 100 million times and has since branched out to Liquibase Pro, the paid advanced version. 

For some teams, the simple automation of database change management provided by Liquibase Open Source fits their needs in the long term. Many others, however, soon realize the added value database DevOps capabilities bring and hop aboard a Liquibase Pro license. 

Liquibase Open Source users considering the upgrade often tell us:

• “Our homegrown solution no longer allows us to scale the business like we need to”
• “We have a homegrown solution, but the expert no longer here - we can’t maintain or enhance it”
• “ROI – the cost of maintaining this is starting to outweigh the benefits, especially as other products and pipelines evolve”
• “We’ve reached the limits of our internal SMEs, in terms of both availability and expertise”

The three most common reasons Cadapan sees users migrating to Liquibase Pro are:

• The peace of mind that the product is secure and compliant
• The expertise that comes with commercial technical support
• The need for advanced features beyond automation: standardization, governance, and observability

To further explore the advanced capabilities and enriched value of Liquibase’s premium version, check out this guide to choosing Liquibase Open Source vs Pro as well as the benefits of using Liquibase over a custom-built database tool. 

Head to the webinar replay for the full “Build vs. Buy” debate from two industry leaders with more than 50 years of combined experience in software development, leadership, and consulting.