Standards and Roadblocks to Manufacturing Software Development

Standards and Roadblocks to Manufacturing Software Development

Looks like there is a debate in the software development community again. This time around node.js

Dave Winer is a pioneer in software development. I used his first blogging platform, Radio Userland, from 2003 until about 2009 when it closed and I moved first to SquareSpace and then to WordPress. Below I point to a discussion about whether the node.js community needs a foundation.

His points work out for manufacturing software development, too. Groups of engineers gather to solve a problem. The problem usually involves opening up to some level of interoperability.

This is a double-edged sword for major suppliers. They’d prefer customers buy all their solutions from them. And, yes, if you control all the technology, you can make communications solider, faster. However, no supplier supplies all the components a customer wants. Then some form of interoperability is required.

Therefore, technologies such as OPC, HART, CIP, and the like. These all solved a problem and advanced the industry.

There are today still more efforts by engineers to write interoperability standards. If these worked, then owner/operators would be able to move data seamlessly, or almost seamlessly, from application to application solving many business problems.

Doing this, however, threatens the lucrative market of high-end consultants whose lock-in of custom code writing and maintenance is a billion-dollar business. Therefore, their efforts to prevent adoption of standards.

Winer nails all this.

I am new to Node but I also have a lot of experience with the dynamics [Eran] Hammer is talking about, in my work with RSS, XML-RPC and SOAP. What he says is right. When you get big companies in the loop, the motives change from what they were when it was just a bunch of ambitious engineers trying to build an open underpinning for the software they’re working on. All of a sudden their strategies start determining which way the standard goes. That often means obfuscating simple technology, because if it’s really simple, they won’t be able to sell expensive consulting contracts.

He was right to single out IBM. That’s their main business. RSS hurt their publishing business because it turned something incomprehensible into something trivial to understand. Who needs to pay $500K per year for a consulting contract to advise them on such transparent technology? They lost business.

IBM, Sun and Microsoft, through the W3C, made SOAP utterly incomprehensible. Why? I assume because they wanted to be able to claim standards-compliance without having to deal with all that messy interop.

As I see it Node was born out of a very simple idea. Here’s this great JavaScript interpreter. Wouldn’t it be great to write server apps in it, in addition to code that runs in the browser? After that, a few libraries came along, that factored out things everyone had to do, almost like device drivers in a way. The filesystem, sending and receiving HTTP requests. Parsing various standard content types. Somehow there didn’t end up being eight different versions of the core functionality. That’s where the greatness of Node comes from. We may look back on this having been the golden age of Node.

Follow this blog

Get a weekly email of all new posts.