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 phone platform alive. The full video is on YouTube: Community Revival of Open Source Telecom.

Most of the talk applies well outside open-source telecom. It is really about what happens when your software vendor goes quiet, and what your options actually are after that. The rest is what it takes to build a workable alternative once the obvious paths have closed.

How our phone platform got stuck

We’ve used a platform called Kazoo to run our voice infrastructure for about ten years. Open-source PBX: the software that switches and routes a company’s calls. 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, which are code fixes offered from outside, went unanswered on the live version 4.3. 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, which means no more security patches. 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 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. Hosting in the US also adds enough delay on the line to hurt call quality 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, setting up new services, the customer portal. Then 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 for our customers. Hardest in every other way. Kazoo is mostly Erlang, which is a less-common skill. That means either hiring Erlang engineers, or carrying the risk ourselves: a complex platform, no vendor behind it, 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: everyone else in the same spot

The thought that changed it: I cannot be alone in this. There are other businesses running Kazoo live, 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 Kazoo on GitHub, which are copies people had taken and changed themselves. I spent a few days reading the substantive ones. People had moved it onto newer versions of Erlang. 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. Caller-ID verification (the STIR/SHAKEN standard) underway. Support for newer versions of Erlang. The platform our clients use is alive again, and the people who depend on it now own it.

Lessons that apply outside 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.

Depending on one supplier is an exit-plan problem. It doesn’t matter whether your platform is open source, proprietary, cloud-hosted or on your own server. If only one party can keep it alive, and that party loses interest, you are the one left with the problem. 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 moving costs too much, one option is left. You organise the other people who depend on the platform. 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.

How we organised the volunteers

Four things worked well enough to copy:

• An advisory group who knew the platform. Held the technical direction. Differences of opinion got argued out there.
• Contributors who could write the code. Held the actual delivery. Stopped the same work being done twice in separate places.
• A shared roadmap, even an imperfect one. Gave volunteers something to join, 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 knee ligament and a fractured arm. Couldn’t work. The community kept moving without me. That’s how you know the structure is right.

Every business depends on software it cannot control

Most CCP clients don’t run Kazoo, and most of you had never heard of it before reading this. It still matters because every business depends on software it doesn’t fully control. Microsoft 365. The CRM built for your industry. A practice management system. Cloud accounting. Some specialised app nobody outside your trade has heard of.

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 a client depends on, plus a straight assessment of each vendor’s health.
• Raise vendor risk as soon as a vendor goes quiet, while there is still time to plan.
• 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 the software you depend on, get in touch.