Standards are great. Your toilets at home and our toilets here in New York and California all use 1.5 gallons of water per flush. Our cars all use the same windshield wipers, save for their lengths. And computer standards ensure everything actually works when you sit down to get something done in a development environment. Well, they’re supposed to do that, anyway.

Trouble is, when a technology is evolving rapidly, it’s difficult to peg a standard on it. Even worse, sometimes standards are undertaken before any coherent landscape has emerged in the marketplace. Take for example the Web Services standards known as WS*. A convoluted mess of cart-before-the-horse thinking dragged along for five years just because an actual standard hadn’t emerged for turning data into Web-digestible applications.

(Related: Intel, NVIDIA take different HPC paths in 2014)

After years of standards work on WS*, the world discovered REST. Almost overnight, hundreds of pages of standards and protocols were thrown out the window in favor of encoding everything into the URL of the target site. Simple, elegant, and it worked without anyone having to buy any new hardware or software.

OpenMP is far from simple. But in a world where high-performance computing was tightly coupled to the specific compilers each platform used, it was a necessary step to save everyone a great deal of headache. While it’s not a “standard” as stamped and approved by an international body, it is the standard way scientists have for years saved themselves all the trouble of having to look up every possible nuance of every possible compiler on every possible platform.

Any step taken away from that goal is surely a step backward. And while OpenACC has made overtures of merging with OpenMP for years now, nothing has really happened to make this a reality. Just as Intel has been asked for years to remove the “cripple AMD” function from its compilers, NVIDIA is being asked to bring its innovations to OpenMP. If all this hardball the big chipmakers are playing doesn’t stop soon, we’re going to be right back where we were in the 1980s and 1990s when it comes to code portability. And that’s not good for anyone.