Perhaps the solution is to fix FIPS instead of berating the people forced to use it.
So it makes a lot of sense for each party to do what they are good at: OpenBSD developers write a clean, secure library, and contractors lobby to be allowed to use it.
BTW, even some core OpenSSL developers think that the FIPS validation process is worse than useless. Here's OpenSSL developer Steve Marquess arguing that a FIPS-validated version of something will generally be less secure than the non-validated version (citing, in particular, how delays and cost of recertification can prevent deployment of fixes for known bugs):
http://veridicalsystems.com/blog/secure-or-compliant-pick-on...
But OpenSSL, as an organization, has so far been willing to play along with the process anyway. The difference is that the LibreSSL folks have enough of the courage of their convictions that they are not playing along.
That's also a huge number of people (and companies).
Because it isn't just getting a body of code certified once.
Someone has to maintain that specific code and either upstream or backport important changes which require a re-certification, neither of which LibreSSL is interested in helping with.
For example, create a fipssl project which is patches to a specific version of LibreSSL; take the result (LibreSSL v1.x + fipssl v1.2 = libfipssl v1.2) and then get that certified. Companies/contractors which need FIPS certification then use libfipssl v1.2.
The fipssl maintainers then just have to track LibreSSL changes until their next release, which (for a series of small, maintainable patches) shouldn't be too difficult. The grsecurity project has been doing the same thing with the Linux kernel for years.
Well, need & money, both of which Red Hat has. I am unclear how a company that maintains an enterprise distribution and writes a lot of code cannot find the folks needed to do FIPS if it is that important for their government contracts.