Going back to the primary goals of Amateur Radio, first among them are education, community service, preparedness, and then the other more usual goals such as ragchewing, pizza & beer. This ties into technology, science, engineering, math and computer science as well. Thus the reason organizations like ARDC and many others prioritize support for organizations who facilitate these larger community goals. Trends in STEM, maker/DiY communities, ham radio, electronics, software, etc., seem to imply that what people who are new to these areas want to see is simplicity, elegance (not a word you hear often in ham radio) and user-friendliness.
Younger people want to be able to just look at something and have it make intuitive sense what it is, what it does, how to use it and how to change it or adapt it. If it doesn't interest them in the first few minutes they have no shortage other potentially more interesting things to devote their attention to.
As pointed out by luminaries such as Alan Kay, father of the term Object-Oriented Programming (OOP) ( Alan Kay - Wikipedia ), the software industry has tended to do the opposite of the above.
Does a Radio-over-IP app need 2 Million Lines of Code? Is that conducive to the longer-term goals of amateur radio? If that size of a codebase was doing something very well and efficiently, and doing so in a way that was clear and intuitive, then sure, but if the same thing could be done with a more modern approach in 20K LOC, then clearly the 1st approach was not efficient or optimally conducive to the goals of the hobby.
If I were to try and figure out where exactly in App-rpt and Asterisk jitter buffering was done, which algorithms were used, and what tradeoffs are made with latency, and if I wanted to be able to view that information in real-time as I use a node, it would probably take days of digging through code and dozens of forum posts to figure all that out and enable/implement the appropriate log messages. Probably everyone just assumes it's good and fine, and maybe it is, but from my experience with a wide range of VOIP systems I would bet ($20?) that some very significant latency optimizations could be made. It is thus very refreshing to see &-ASL making such great progress and to see discussion of these kinds of details, and know that if I wanted to know more I could find these functions in probably 5 minutes of work in the & github repo. Thanks again Bruce!
There is now increasing awareness in the software industry of how to better achieve the goals of what might be called "modern" software. As new approaches emphasize simplicity, observability, precision, reliability, and open standards and best practices, they tend to be more successful and become more popular. This is hardly new in just about any other industry. The software industry, and those employed by large software companies, however tend to drink their own Kool-Aid and create overly complicated software and processes that make it difficult to scale to the level of individuals, hobbyists - and hams.
The beauty of FOSS ham radio software is there's no rush, no deadlines, and no tradeoffs required. We can make it as simple, clear and intuitive as we'd like. People often have the idea that software is supposed to be complex, poorly documented, and opaque, and seem to have lost sight of the fact that software, particularly in embedded communication systems, is nothing more than an abstraction of hardware, which is comprised of simple electronic components that follow simple physics concepts. Repeater systems, telecom systems, and audio systems existed long before the internet and PCs. In the olde days these things used switches, potentiometers, level meters, Op Amps and copper wire to do everything, and this underlying simple meta-structure has not fundamentally changed.
The thing I like about designing hardware is that everything is clear and precise. A one-page schematic can clearly document an entire product, with very little abstraction. Software can be just as simple, when people are able to step outside of legacy ways of thinking. Most software developers are like most politicians in a way, they seem to always think that more of whatever service they provide is always the solution to everything. The 2nd-order effects of complexity, unsustainability and inefficiency seem to be enthusiastically overlooked.
AllStar is here to stay, ASL3 works well, much of its complexity makes sense in context, though some doesn't, but longer-term there's room for other approaches that leverage its strengths and address its weaknesses in a truly modern way, and bring it closer to a highly optimized, stable, modular, extensible ROIP system that "just works", where things are properly optimized with clear and easily accessible instrumentation at every interface. The required pieces are already all there in Linux, Python, SciPy, GNURadio, IAX, other latency-optimized VOIP codecs, modern audio drivers, etc. Just a matter of integrating these pieces in the right way. Having used Asterisk and ASL for a few years now I don't see Asterisk as a very useful part of that, at least not as a platform. Sure maybe tie into it as a module if needed eg. for autopatch, SIP or PSTN purposes, but otherwise it seems, well kind of like a 1990's PBX system. Anyhow, just some food for thought. Signed, Looking forward to further innovations in ham radio...