When Open Source Goes Closed: Commercialisation, AI, and the Future of Software Dependence

Open source software has been a cornerstone of modern development for two decades. It’s fast to adopt, battle-tested by communities, and, most importantly, free. But lately, “free” has started to come with fine print.

From infrastructure tools to developer libraries, many open source projects are turning commercial. For developers, software buyers, and architects alike, this raises difficult questions: Can we still rely on open source? What happens when our dependencies change terms? And could AI eventually free us from all of this?

The Shift: Open Source Is Growing Up and Charging Rent

In recent years, open source projects have increasingly adopted more restrictive licences or introduced paid options. Notable examples include:

• HashiCorp’s Terraform, now under the Business Source License (BSL)

• Redis, shifting to dual source-available/commercial licensing

• AutoMapper and MediatR, mainstays in .NET development, introducing licences to support sustainability

Why? Maintaining open source software, especially popular ones, has real costs. Support tickets, feature requests, bug reports, and security updates can consume thousands of hours. Most maintainers aren’t compensated for this unless they commercialise, get funding, or sell services.

The result: a growing number of open source tools that either go closed, introduce commercial models, or become abandoned altogether.

What’s at Risk for Engineering Teams and Decision-Makers

The impact of this trend isn’t theoretical. When a widely used dependency shifts its licence, organisations can find themselves in difficult territory:

• Compliance risk: You may unknowingly violate a new licence’s terms

• Unexpected cost: A once-free component now adds a line item to your budget

• Reduced flexibility: Forking or modifying may no longer be legally or practically viable

• Delivery impact: Removing or replacing a core dependency can stall projects

So how do you choose open source tools wisely, and prepare for the possibility of change?

How to Choose (and Use) Open Source Safely

Here are key criteria to guide the selection of open source components:

1. Evaluate Maintenance and Activity

• Look for projects with active commits, recent releases, and responsive maintainers.

• Check GitHub issues and pull requests to assess health.

2. Prefer Foundation-Backed or Commercially-Supported Projects

• Tools backed by neutral foundations (e.g. CNCF) are less likely to go closed.

• Commercial support may provide predictability, even if not free.

3. Review the Licence Carefully

• Not all “open source” licences offer the same freedoms. Stick to OSI-approved licences when possible.

• Be wary of “source-available” or custom licences masquerading as open.

4. Test for Replaceability

• Consider how easily the tool can be swapped out.

• Choose libraries with clean boundaries, clear interfaces, and minimal coupling.

5. Document Every External Dependency

• Keep a register of open source libraries, their licences, and your usage model (dev-only vs production).

• Include it in security, compliance, and procurement reviews.

What to Do If a Dependency Goes Commercial

If a key tool changes its licensing model mid-project, you have options:

1. Migrate to an Alternative

• Evaluate forks or community-led continuations (e.g. OpenTofu as a Terraform alternative)

• Switch to functionally similar tools if long-term compatibility is at risk

2. Buy a Commercial Licence

• If the licence is fair and the tool is core to your product, paying may be the path of least resistance

• This also brings support, SLAs, and legal clarity (benefits not always present in free tools)

3. Isolate and Refactor

• Minimise exposure by isolating the dependency in your architecture

• Abstract it away to give your team flexibility to switch later

Understanding Commercial Licences: What They Mean

Not all commercialised licences are created equal. Here are common types:

Licence TypeDescriptionRisk LevelGood Fit ForBusiness Source (BSL)Source available, becomes open after X yearsMediumNon-core tools with stable release cyclesElastic/SSPLSource available, but not open: restrictions on useHighInternal use only; avoid for SaaS or redistributionDual LicensingFree for some use, commercial for production or scaleVariableStartups or teams with low-scale deploymentFully CommercialClosed source, pay-to-useLow risk (with contract)Strategic infrastructure with full support

Choosing to pay can be strategic, especially when uptime, compliance, and longevity matter. But that decision must be made consciously, not by accident when terms change.

The AI Alternative: Build Without the Baggage

This is where AI enters the equation.

Generative AI tools like GitHub Copilot, Cursor, Claude, OpenAI Codex, and others can generate production-grade code, integrate common patterns, and replace lightweight dependencies.

Instead of importing a library for logging, parsing, or HTTP retries, what if you just asked your AI assistant to write it for you?

Benefits include:

• No licence risk or hidden terms

• Fully in-house ownership and control

• Custom fit for your architecture and domain

• Easier long-term maintenance when designed with your context in mind

AI won’t (yet) replace sophisticated or deeply integrated tools, but for a growing number of common use cases, it removes the need to depend on third parties at all.

The Future: More Tools, More Choices, Less Dependency

We’re entering an era where software teams must be *intentional *about the tools they use, and ready to pivot when circumstances change.

• Audit dependencies regularly

• Understand licence terms deeply

• Build internal capability to reduce risk

• Use AI to minimise reliance on external libraries where it makes sense

Being free from dependency is the most robust option. AI can help get you closer to that ideal, if adopted with care and oversight.

In Summary: Open Source Isn’t Dead, But the Rules Are Changing

• Open source going commercial is no longer rare, it’s a trend

• Choosing well and preparing for change is essential

• Sometimes it makes sense to pay; sometimes it makes sense to walk away

• AI opens a new path: building what you need, on your terms

The best strategy isn’t open vs closed, it’s control. And today, AI gives you more control than ever before.

Frequently Asked Questions

Build software you can rely on

Talk Think Do is a UK-based custom software development company. We help businesses build and maintain cloud-native applications with full source code ownership and no proprietary lock-in.

If you are concerned about open source dependency risk, or want to move away from software you do not fully control, book a consultation to talk through your options.