JS8CALL
I've written a lot about JS8CALL over the years, and was an early adopter when the developer, Jordan Sherer, KN4CRD, first released it back in 2019. It's weak signal keyboard-to-keyboard chat properties were unmatched at the time, and I always thought the program had a lot of potential in the EMCOMM world. Jordan took JS8CALL through several development cycles, all the way up to version 2.1 or 2.2, then development stalled. My guess, and it's only a guess, is that life simply got in the way. Jordan's a young guy and family, work and other interests likely pulled him away from ham radio and JS8CALL development. JS8CALL remained good software, but there was no forward movement. No new features, no bug fixes. It was going stale.
From the beginning, Jordan published JS8CALL as open source, and the code and packages were always available on Github. I think he understood that the time would come when another developer or team would have to carry JS8CALL forward. Starting in 2025, a small development team began work on an improved version of JS8CALL, which led to some 'Improved' releases in late 2025. In February 2026 the newest Improved version was released, version 2.5.2.
It looks like Joe Counsil, K0OG, is herding the development cats on the Improved versions, and it's interesting to read the developer discussions on the Github threads. The team, particularly Joe, have a clear-eyed vision of what JS8CALL's role is, what is good at, what it's not good at, and likely never will be good at. This is a refreshing perspective. The developers understand there are better formal messaging applications available (Winlink, VarAC and even Fldigi), so their goal is to make JS8CALL a very robust weak signal chat tool, not a do-everything application.
Here's a screen capture of part of a discussion thread regarding building an automatic missing message frame request tool into the application. I think Joe and Chris, AC9KH's comments are refreshing in their honesty about JS8CALL functionality:
Joe, K0OG, notes: This was discussed at the beginning of JS8Call, and I think the conclusion was (and I still agree with this) that there are better tools already available to do this, and JS8Call is not intended to be the best tool for formal messaging. This is partly due to upper-case-only text. In my opinion, JS8Call is good for coordination, informal chat, and very-light messaging duties, strong points being the mesh network and weak-signal capability. For more-reliable messaging, at the time I recommended the Fldigi-based toolset. I would still recommend that (there are some excellent weak-signal modems with FEC, and ARQ can be used with some of the tools), but also now Vara-based tools are good. I suggest that as a strategy, this is not something we need to do with JS8Call. (My emphasis)
While JS8CALL was sitting dormant I dropped my support for the platform as a standard emergency communications tool. The weak signal chat and coordination mission was still there, but if JS8CALL was approaching orphanware status, I really couldn't recommend it. Now that development has ramped back up and a serious development community is plugging away at improvements and bug fixes, I think it's time to give JS8CALL another try.
W8BYH out
