When your vendor goes silent: lessons from reviving an open-source platform

In early September 2025 I flew to Chicago to give a talk at ClueCon, the open-source telecom conference. The talk was about Kazoo Classic, a community project we started to keep an abandoned PBX platform alive. The full video is on YouTube: Community Revival of Open Source Telecom.

Most of the lessons in that talk apply well outside open-source telecom. They’re really about what happens when your software vendor goes quiet, what your real options are, and what it takes to build a workable alternative when the obvious paths have closed off. Worth writing down for anyone running business-critical software they don’t fully control.

The setup

We’ve used a platform called Kazoo to run our voice infrastructure for about ten years. Open-source PBX, big architecture, stitched together from a stack of other open-source projects (FreeSWITCH, Kamailio, RabbitMQ and so on). It powers a lot of telecom worldwide.

Around 2020 the company behind it, 2600Hz, made a series of decisions that quietly closed the platform. Public commits stopped. A version 5 was promised but never shipped. Pull requests against the live version 4.3 went unanswered. A 2023 acquisition by another telecom company came with reassurances about being open-source-first. Nothing was released.

By 2024, the version we were running was based on CentOS 7. CentOS 7 reached end of life. The platform was running on an end-of-life operating system, with an end-of-life codebase, with no supported upgrade path that was ever actually delivered.

I run a managed services business that sells cybersecurity. We can’t keep production workloads on end-of-life software. That makes us hypocrites. I needed to do something.

Three bad options

The honest options as I saw them:

Pay for the enterprise version. Reasonable on paper. Two problems for us. Enterprise support was US business hours, which is overnight in Australia: phones drop at 9am Perth, and the helpdesk that owns the platform doesn’t open for another twelve hours. Not viable. Latency between Australia and the US is also high enough that a US-hosted instance would have noticeable voice quality problems for our clients.

Migrate to a different PBX platform. Asterisk, FreeSWITCH directly, FusionPBX, anything. Workable, expensive. We’d need to rewrite every integration we’d built (billing, provisioning, customer portal), retrain the team, and lose a few features our clients had come to rely on. Months of work, quality drop in the interim.

Maintain Kazoo 4.3 ourselves. Simplest from a customer-experience point of view. Hardest in every other way. Kazoo is mostly Erlang, which is a less-common skill. Maintaining it would mean either hiring Erlang engineers or wearing the risk of a complex platform with no upstream support and a small internal team.

I was about to write to clients and quietly hand the voice business off to a competitor.

The fourth option

The thought that changed it: I cannot be alone in this. There are other businesses running Kazoo, in production, watching the same vendor go silent. Some of them must be more capable than I am at the parts I can’t do alone.

I went hunting. There are about 500 forks of the Kazoo repo on GitHub. I spent a few days reading the substantive ones. People had updated Erlang OTP versions. People had solved the proprietary database integration. People had patched specific security issues. All of it in silos, none of it shared.

I tracked those people down individually, found their contact details (felt mildly stalkerish, owned that), and asked them to join a community effort. Not a single one said no. They’d all been carrying the same load alone and were relieved to share it.

That community became Kazoo Classic. About eighty contributors now. Donated infrastructure. A real roadmap. Critical security fixes shipping. STIR/SHAKEN implementation in flight. Newer Erlang OTP support. The platform our clients depend on is alive again, owned by the people who depend on it.

The lessons that travel beyond telecom

A few are worth repeating because they apply to most software a business depends on.

Vendor silence is information. A vendor that stops shipping is telling you something. The longer you wait to plan around it, the fewer options you have. We waited three years. Most of those three years were us giving the vendor the benefit of the doubt because the alternative was uncomfortable.

Sole-source dependencies are an exit-plan problem. It doesn’t matter whether your platform is open source, proprietary, cloud-hosted or on-prem. If only one party can keep it alive, and that party loses interest, you’re holding the bag. The right time to think about your exit options from a critical platform is well before you need them.

Community is sometimes the only exit. When the vendor is gone and the migration cost is prohibitive, organising the other people who depend on the platform is the remaining option. It’s slower than a vendor-led path, but it’s real, and it works.

Version one is better than version none. A line my old business coach used to repeat. It applies to everything. We launched Kazoo Classic with no website, no governance, no formal roadmap. Just a Discord server and a forum post. That was enough to start. The rest we built as we went.

The leadership shape of a volunteer community

A few specifics that worked well enough to be worth naming:

• An advisory group of people who knew the platform. Held the technical direction. Differences of opinion got argued out there.
• A contributors group of people who could write the code. Held the actual delivery. Avoided the duplication that had been happening across silos.
• A shared roadmap. Even an imperfect one. Gave volunteers something to plug into rather than asking them to invent their own work.
• No “you have to do this”. Nobody on a volunteer project responds well to obligation. The job is to share a vision, name what’s important, and let people self-select. They will.

Three months earlier this year I was laid up with a torn ACL and a fractured arm. Couldn’t work. The community kept moving without me. That’s how you know the structure is right.

The point for our clients

Most CCP clients don’t run Kazoo. Most of you have never heard of it before reading this. The reason it still matters is that every business depends on software it doesn’t fully control. Microsoft 365. A vertical CRM. A practice management system. A cloud accounting platform. A specialised line-of-business app no one else uses.

Sometimes those vendors get acquired and quietly run down. Sometimes they go bankrupt. Sometimes they pivot to a customer segment that isn’t yours and stop investing in the features you depend on. The pattern is consistent enough to plan around.

What we do for clients on this:

• Keep an inventory of the platforms each client depends on, and an honest assessment of vendor health on each one.
• Flag vendor risk early, not after the fact. A vendor going quiet is a conversation starter, not a wait-and-see.
• Maintain a real exit plan for the platforms where switching is expensive. Knowing what the migration would cost, and how long it would take, is part of due diligence.

If you’d like a hand running that exercise across your stack, get in touch.