Your tale reminds me of a similar story: I had a very senior co-worker at a company I worked at years ago who was bitten by a bug in an OpenG VI once, and his solution was to proclaim that no one at the company be permitted to use open source reuse libraries. Most of the other developers were relatively junior, so they all took his lead. A couple of years later I started working at that company, someone asked for my help on something, and I told them there was an OpenG VI that did exactly what they wanted. He told me the story, so I went and talked to the guy that was originally bitten by the bug and he told me his story of woe. I asked him why he didn't fix the bug and upload it back to OpenG? Or maybe even just post a quick couple of lines to the forum to let everyone else know about it? His reply was that his job isn't to help others outside the company to profit.
The code you get from OpenG may not be perfect. The code you get in vi.lib may not be perfect. The code you write isn't perfect. don't tell my boss, but the code I write isn't perfect. But that's part of why we're all here: to accept challenges and make things better. Now, if you can't tolerate any code that doesn't do exactly what you want it to, then you need to start coding in assembly. Otherwise, accept that what you get from OpenG, NI, etc is best effort from the developers, and (and this is the bottom line here) is created to try to help you. If it doesn't, drop them a line and let them know why, but don't write it off because it wasn't a perfect fit. Better yet, get involved so that others can benefit from the code you write.
I'm not saying that OpenG shouldn't be criticized: in fact, the OpenG architects and developers actively encourage it - it's only through constructive criticism that it will grow and better serve the people it was created for: you!