Having worked on several open source projects, I’m never surprised that people think of open source in a positive way. What does surprise me is that people always tend to think of it as a universal solution to whatever you see ailing with any specific piece of soft- or firmware. It’s not. In some cases, it’s just a preference for a developer to do so. In a case like goTenna Mesh, there are significant issues that tend to limit the feasibility of applying open source to a project. In the case of the GTM, there are two big ones that are specific to it, regulatory and hardware.
Keep in mind that most open source projects are entirely internet based. So long as it fits within the very few limitations the internet presents, open source is viable, even preferable. The problem with applying that the GTM is that the GTM is a radio and is thus dependent on fitting within the FCC regulatory framework. To do that, the radio side of the equation here is locked down and I cannot foresee this changing barring the FCC significantly revising its “rules of the road” limiting output power, frequency choice, the permanence of the antenna’s attachment and a number of other specifically defined aspects of the design that are part of the GTM’s certification for use. And it’s not just here in the USA that this applies to, it’s the 40-some other nations that all have a regulatory dog on this fight.
The other major aspect of this is that it involves hardware. This is also subject to FCC compliance, so won’t rehash what was just written other that to say that certain aspects of the hardware are also the way they are because of the FCC’s requirements. Even if the software and firmware on the GTM became open and public and you could hack away to your heart’s content, then what are you going to run it on? Do you plan to build and operate your own radio? Unless you’re a ham, that’s not really possible - legally. And the GTM doesn’t use ham freqs, either, so even that is a problem for someone trying to imagine this as an open source project.
But there’s more. An open source project generally goes it’s own way, because that’s possible as well as desirable. When you’re talking about a mass of users trying to communicate with each other, then compatibility is as important as diversity. The cool open source hacks you are perhaps anticipating making are really only valuable to the extent that they begin by being compatible with the existing system. That also tends to limit what’s possible, because many of the issues that are often brought up in such comments, such as wanting more than 6 hops, allowing Shouts to hop, etc, would directly impact a mesh network’s functionality if implemented willy-nilly. I bring this up because it seems that you’re already thinking about nationwide meshing as being limited by the way that goTenna chose to handle this, thinking the 6 hop limit is an arbitrary number when it’s actually pretty much a technical limitation taken to ensure network reliability and functionality. If you haven’t read it yet, Ram Ramanathan’s “Understanding Mesh Networking, Part 1” and it’s Part 2 are very helpful.
https://inthemesh.com/archive/understanding-mesh-networking-part-i/
https://inthemesh.com/archive/understanding-mesh-networking-part-ii/
The issues that concern you have received a lot of discussion here already, so you will probably find some deeper reading here of benefit to gaining the context necessary to fully appreciate why things are the way they are and what is possible in the future. Look through things and then you may have a more nuanced grasp of how goTenna works in practice, versus the idealized space some wish it were in. The SDKs that are available allow a great deal of latitude for open source implementation, also, to the extent that is possible. There’s still an enormous amount of flexibility in functionality available, so don’t let the perfect be the enemy of the good here when it comes to goTenna Mesh.