C-Kermit is, depending on your age, either a tool you used to move files between very different computers in the early days of the internet, or something you have never heard of. The project started at Columbia University in 1981, the same year the IBM PC shipped, which should give you a sense of the timeframe. Kermit 11 is the first non-beta release in fifteen years, and it exists because one Debian maintainer decided that “kept working on life support” was no longer a sufficient status.
The framing matters. C-Kermit is not dead, has not been dead, and was probably never going to die. It just stopped getting new releases when Columbia ended active development in 2011. The license changed at the same time: from a commercial license that required payment to the Revised 3-Clause BSD License, which made it possible to put in a distribution without a per-seat fee. The source tree kept compiling. The maintainer was Frank da Cruz, the co-creator, who continued to push changes through last year. There was no flame-out, no acrimonious fork, no “the community took over” narrative. Just a slow taper.
What changed is the hardware. Kermit was designed for serial lines, character set translation, and the kind of 96-byte-at-a-time buffers that defined the early era. None of that has gone away, but the layer underneath has shifted enough that “compiles on a modern Linux” is no longer something you get for free. The work to make it work again is what landed in 11.
Who actually did the work
John Goerzen. He is a Debian developer whose day job is keeping the Debian archive coherent, and along the way he has been the upstream for C-Kermit’s Debian packaging. Somewhere in that process, he went from packaging to patching to rewriting, and at some point the patches became a release. He has written a long technical post on the work, and a full changelog lives on GitHub.
This is a story about what happens when an infrastructure project is small enough to be carried by one person, and that person is patient. It is also a story about how “still works” and “useful on modern hardware” are different claims, and how the gap between them can sit open for a decade without anyone noticing because the audience is small.
What is in C-Kermit 11
The changelog is long and you should read it directly if you care about the specifics, but the categories of work break down cleanly:
- A real build system that works on current toolchains, replacing the configure scripts that had drifted past what autoconf is happy with.
- Character set handling that covers modern Unicode, not just the ASCII and EBCDIC pairs that were the original target.
- Serial line handling that knows about USB-to-serial adapters, which is where most of the “I need Kermit” use cases now live.
- Packaging and build artifacts for current Debian and Ubuntu.
- A new project home at Open Kermit, intended as a neutral coordination point so that future work does not have to bounce through one person’s personal Git tree.
The release notes from Goerzen describe 11 as “a major new release, the first non-beta since the last 9.x release in 2011.” That is the part worth quoting, because it tells you the gap was 14 years between non-beta releases on the C branch. The 9.x line kept getting fixes; the major-version bump did not.
Why this matters and why it doesn’t
If you are reading this on a phone or a modern laptop, you do not need C-Kermit. The protocols it implements have been superseded by SSH, by HTTPS, by a dozen different things that ride on top of TCP. The Kermit protocol itself is still useful in a narrow band: when you have a serial line, when you have a system that cannot speak modern protocols, when you have a 7-bit clean path and you need to move an 8-bit file across it. That band is narrower than it used to be, and it is mostly filled by industrial control, embedded systems, and the long tail of “I have a piece of equipment with a serial port.”
For that audience, the gap between “C-Kermit still compiles” and “C-Kermit works on the hardware I am trying to connect to” was getting wider. Kermit 11 closes the gap. The work is real, the use cases are real, and the maintenance model is now sane.
For everyone else, this is a curiosity and a useful reminder. The reminder is that the long tail of open source has more depth than the headlines suggest. Projects from 1981 still ship new releases. The license change in 2011 made that possible. Debian’s structure made it survivable. One maintainer’s patience made it happen. The protocols Kermit implements are not in fashion, but the engineering discipline required to keep a forty-five-year-old codebase current is the same discipline that keeps any long-lived project current. If you have ever wondered what “small but maintained” looks like in practice, the answer is in the changelog.
Trade-offs
The trade-off here is structural, not technical. C-Kermit 11 is a one-maintainer release in the same way the previous 9.x releases were one-maintainer releases. Goerzen has done the work, but the bus factor (the risk of a project collapsing if one person steps away) is still one. Open Kermit is the proposed mitigation, but the project is a coordination structure, not a staffed organization. If Goerzen steps back, the next person inheriting the work inherits a working codebase and a long changelog and no clear second author.
There is also a scope question. The work in 11 is modernization, not new features. The protocol is stable on purpose. If you are looking for “what’s new in Kermit in 2026,” the honest answer is that the implementation is new and the protocol is not. That is fine, because the protocol was always the point. But it is worth being clear about.
A third trade-off, which is more about the surrounding space than the project itself: Kermit 11 ships in a world where most developers have never seen a serial cable. The maintainer has done the work of writing for an audience that does include current Debian users, but the documentation assumes some baseline familiarity with the protocol. New users will have to read.
What to actually do
If you maintain industrial control software, embedded systems, or anything that still talks over a serial line, Kermit 11 is worth a look. The download is on the Kermit project downloads page, and the source is on GitHub. The changelog is the right place to start, because the changes are extensive and you do not want to find surprises at integration time.
If you do not work in that niche, the practical takeaway is smaller. Watch the Open Kermit project. If a second maintainer shows up and the project stops being one person’s spare time, that is the more important long-term signal than any individual release. The code matters. The structure matters more.