it's not a good idea to announce new hardware in public before it is likely that a product will result. An announcements create hopes, and not being able to fulfil them, is worse than no hopes at all. Once I made the mistake to leak that I work on something FPGA based, but please don't push for more details.
As for the operating system(s) I use, they are open source and free of course. As for schematics and PCB data, they are unlikely to be pubished, at least before the one who builds/sells the boards had return on investment. For hardware, publishing these sources, does not make the boards "available". The effect goes more toward making them "unavailable" for everyone but hardware tinkerers. The one who wants to build them, could not invest in full quantities because someone else might reproduce the boards, too. This makes the boards more expensive, inefficient to handle production, and less likely someone wants to invest in series production at all.
The system would not be optimized for speed, mostly because the chips have aged during the time I lost with the OS/driver issues. It will be more important to have something working at all. If the system gets finished and well accepted, nothing forbids new boards using a faster FPGA a few years later.
The problem we work on, is triggered by Minerva, but a problem within the chip. Nobody can blame Minerva for that. Maybe it is even a problem with the FPGA synthesis tools. QDOS Classic works better but still not correct. It would be lengthy to explain, why debugging the faulty CPU is so difficult under the given circumstances. Sorry, but I won't, unless you are a hardware _and_ FPGA _and_ assembler specialist who has too much time and is eager to debug this himself

All the best
Peter