While the idea of opensource hardware is laudable, it's really hard to make it work.
There's some significant difference from Open Source Software, and it goes to things like economic viability.
The "reproduction cost" of software is essentially zero. It costs only time so a *volunteer* who is working on the software is not "out of pocket" to experiment and develop. In particular, you can make small changes easily, and try them almost instantly.
This is not generally true of hardware - you have to buy something - for anything of moderate complexity there are also significant "first article" costs and delays. It takes at least a few days to turn around a board and parts, and at that speed, it's not cheap. There's quite a few people around like me, who have been through the "make boards at home or at work" with photoresist, and then the fancy PCboard milling machines, etc. And that's for a 2 layer board, maybe with eyelets or if you're really ambitious plated through holes. Any non-trivial RF design (like the VNA or SAA) is going to be a 4 layer board, which means "go to someone who does this for a living and write a check".
There's also the design process itself. For software, there are comments, or some sort of description of how it works, or at least the structure of the code reveals how it works and where one would make changes. I'm able to pick up the NanoVNA software listings (which aren't huge - about 20,000 lines total) and in a matter of a few minutes, figure out where the various functions are, what's going on internally, and so forth. It helps that I have a lot of experience with both VNAs and software, because then I know what it's supposed to be doing and what functions are needed, so I know what to look for. If I really wanted to add a function or change how something is done, I could do it, spend maybe a day (part time) getting the build environment to work, and over a weekend, add that function. All without any money out of pocket, other than the original NanoVNA purchase to test it on. (part of that setting up the dev environment is figuring out how not to brick the part).
For hardware, and in particular RF hardware, it's not quite so easy - Most open hardware projects do not have extensive design notes, nor do they record the rationale for particular choices. RF layout is idiosyncratic, you can't put the parts just anywhere, and a decent designer has a sort of conceptual model in their head they're using as they lay out the board and do the routing. That's not easily put down as documentation - normally it's not. I've worked with quite a few RF board designs at work (JPL) as a "consumer" of the design (that is, I didn't do the layout - I'm reviewing it, or I'll use the board when it's done, or I wrote the requirements) - not one of them has been accompanied by design documentation that says *why* anything was done - you might get that in a design review in response to a question about some specific instance. In a collaborative development environment, there are usually some interactive conversations, either out loud, or by email, about the design: "Is it ok to parallel these LT3042 regulators? How did you do the layout for thermal dissipation?"
But, in general, it is difficult to take someone else's design and board layout, and make changes, particularly if the form factor is dense. You don't know if moving something will make it not work - maybe the original designer moved it to reduce coupling, or get the ground planes laid out, or to make room for something else.
Then we get to the "trial and error" aspect - it costs money to get the board, it costs money to buy the parts on the board, it costs more money to put the parts on the board. And it takes time. So the "investment" required to modify that open source hardware is easily climbing into the hundreds of dollars range, if not thousands.
And that gets to the economics of it.
In open source software, there are companies that make money - by providing support, customization, convenience - people would rather PAY RedHat to get "plug it in and run" distros than "roll their own". Companies, in particular, are happy to pay someone to track bugs and vulnerabilities on their behalf. And there's a huge market for custom (proprietary) software development that lays on top of an open source base - so the income from the (not necessarily open) application development subsidizes the work on the open source, freely copyable, base. And, because the "cost of entry" to the software is very low, lots of people can get their feet wet.
The same is not true of open source hardware:
1) there isn't as much opportunity to make money by providing service, training, and customization.
2) there's more of an investment needed to get started - tools, test equipment (actually, I hope that the NanoVNA and TinySA spawn interest in RF design.. those two products, both needed for RF development, are inexpensive enough that the barrier to entry is reduced - heck, I spent more on my soldering iron than on the NanoVNA)
3) there's more of an investment needed for each "trial spin" - open source software is something you can do on the side, in a few hours in the evening or on the weekend, and get something done. Not so for most non-trivial hardware.
I mean, philosophically, open source hardware designs are great. It's just that I don't see a way to make a living at it, like you can with open source software. The way you make money with hardware designs is by selling the hardware (or selling your design to someone who will sell hardware), and part of being able to make money (without being undercut by copiers, some of whom are being predatory on general principle) is by having unique and special knowledge so that YOU can make the ones that work, and the copier can't. Otherwise it's a race to the bottom and ruin.
So open-source hardware will almost always be a "labor of love" you do it to scratch an itch, to provide something useful to the community, and you make your living doing something else. (or the same, at a company level).
