Why a Phone Company Publishes Its Code

When you give a company your business phone line, you are trusting it with something you cannot see. You cannot watch where a call goes, who handles it, or what happens to the transcript afterward. You take the company's word for it.

We think a customer should have to take our word for as little as possible. So we publish where every kind of data is kept, we name every outside company that helps us run the service, and as of this week we have put our open-source work in one place: distronode.com/open-source.

This post explains what is there, and why a phone company bothers.

We are built on other people's work, and we say so

District AI answers calls using software that thousands of people wrote and gave away. The system that carries the live audio of a call is open source. So is the database that holds your contacts and call records, the software that runs our servers in each of our four regions, and the small program that decides when a caller has stopped talking so the assistant knows it is its turn.

The new page lists ten of these projects by name, says what each one does for us, and shows the licence it is published under. Every one of them does visible work on every call or every page. None of them is there to pad the list.

One well-known name is missing on purpose. We use Redis, and its current licence is not an open-source licence, so it would be wrong to list it as one. The page says so.

Two things we built, now public

Along the way we wrote two pieces of software worth sharing. Both are free to use under the Apache-2.0 licence, and both are the real thing: the public repositories are the ones we deploy from, with their issues, changelogs and security policies in the open.

bridgewatch is a small app that sits in your menu bar and tells a software team whether their latest change actually went live. We wrote it because every tool we tried answered a slightly different question. Our own system runs an automatic check every hour, and the tools we tried reported on that hourly check instead of on the change we had just made. Worse, one change here starts several separate jobs, and no tool could tell us what the change as a whole had done. bridgewatch can. Version 1.0 came out on September 19, for macOS and Linux, and it works with both GitLab and GitHub.

District Scheduler is the engine behind every booking District AI makes, and behind the booking page included in every plan. It is our version of an open-source scheduling project called Calnode. We added one thing Calnode does not have: the ability to keep many businesses' calendars safely separated inside one system, which is what a service like ours needs. That addition sits behind a single switch. With the switch off, you are running plain Calnode.

We send the fixes back

This is the part we care about most.

When you build on someone else's software, you find bugs in it. There are two things you can do. You can fix the bug in your own copy and keep quiet, or you can send the fix back to the people who maintain the original so that everyone gets it.

Keeping quiet is tempting and it is a trap. A private fix has to be carried forward by hand every time the original project releases a new version, by the one company that knows it exists. Sending the fix back means the next release already has it, for us and for everyone else.

So a fix to Calnode goes to Calnode. Our fixes for duplicated appointment types, clearer booking pages, calendar reconnection and language handling are part of Calnode today, and every business running it has them, not only ours.

What this means if you are a customer

You do not need to read a line of code to use District AI, and nothing about your service changes. What changes is what you can check.

If you, or the person who looks after your IT, or a client who asks hard questions about privacy, ever want to know how the scheduling behind your booking page actually works, the answer is public. It is the same reason we publish where your data lives and who helps us process it. A company that handles your calls should be easy to check.

Where to find it

Everything is on one page, with links to both projects on GitHub and to our group on GitLab. Suggestions and fixes are welcome on either project. If you find a security problem, please use the address in the project's security policy rather than a public post, so we can fix it before it is widely known.