I agree it could be a viable business model, but the trick seems finding a market.
Since QUIC exists, most people (including virtually all client-side apps) will just use that. But QUIC is still TLS and HTTP, which is unnecessary for a lot of use cases and adds complexity. I think if you created developer-friendly tooling/libraries/servers/etc that were dead-stupid-simple, people would use that over TLS/HTTP, for anything other than a web browser. Android apps and tunneling applications might use it on the client side, and MQTT would be a great use case on the backend.
The one thing I think would be a stumbling block to the simplicity is the use of public keys. It's just super clunky compared to basic username/password or PSK auth. I don't have any suggestions here, I know Wireguard is pretty much wedded to public keys, but anything you can do to eliminate the many problems/limitations with public keys would help drive adoption.
I think you can lock up the control plane if you want for an implementation, but keep the interfaces loosely coupled and part of an open standard with the library having simple hooks for everything. That way those that have some money and just need a fix now, will pay for your thing, and those that can't will write their own implementation and grow the ecosystem which you can then market off of.
Like, Terraform could have been a closed-source tool, but the fact that anyone can write a provider means Hashi didn't have to write them all, and as more providers and modules were written, the tool cemented itself ever more as indispensable. (Which pisses me the hell off because Terraform sucks so bad, but it was a good business strategy heh)
Last thought: I would also quietly advertise the library as as "TCP evolved" or something similar, because that's how I see this. Assuming you deal with NAT, I would absolutely use a protocol like this over TCP by default for all my applications. QUIC was almost there but the TLS and HTTP is so unnecessary for 99% of applications.
