ASICs generally aren't flexible enough that you could simply emulate another controller in firmware, while FPGAs suck too much power to use on commodity network adapters. Writing a new driver (or bringing an existing neglected driver up to scratch) is going to be quicker than trying to make hardware that's compatible enough to work with a driver written for another vendor's controller.

(Besides which, as that other driver is probably maintained by your competitor, do you really think they're going to make an effort to ensure that their later updates are compatible with your clone controller? You'll still have to maintain your own fork.)

I have often wondered why there isn't a vendor-neutral register-level standard for Ethernet controllers, along the lines of AHCI and xHCI. There is the virtio networking standard, but as it's designed for VMs I assume it does not cover Ethernet link management. I seem to remember that VMware tried to promote a common interface for SR-IOV virtual functions at one time, but that didn't get very far. Again that would not have included link management.

Qt by default uses native widgets wherever possible

I believe it imitates the look of native widgets but doesn't actually use them. This should allow for consistent behaviour on all platforms (unlike, say, WxWidgets).

>education is too low for just about any high tech work

Really? Places like Huntsville (NASA), Ann Arbor (U. Michigan), Raleigh (IBM), and Austin (Everybody these days) don't have top talent for tech work?

Maybe not Detroit, but definitely not in Northern California - it's way too expensive to do business there. For an R&D/Skunkworks style office, perhaps drawing on the local talent is worth the cost, but putting general office workers and blue collar labor there is silly when you have nice states like Texas, Alabama, North Carolina, and Michigan which have friendly labor laws and cheaper labor pools, along with some top minds in places like Austin, Huntsville, Raleigh, and Ann Arbor.