Once upon a time, hardware people designed all of their circuits. But in the vacuum tube days some wise engineer created modules. An example was a dual triode flip flop that would generally plug into a standard octal socket. Now others could reuse that design by buying the module and including it in their product.

Later the integrated circuit formalized this notion, and today there's a veritable ocean of standard parts available. Datasheets carefully characterize their behavior; we buy them and wire them onto a board.

That's the holy grail of reuse, and in some cases the software community does the same thing. We recycle an object module and link it into a new application. Alas, for reasons both good and bad we often monkey with the source instead, even though NASA has shown that once one changes more than about 25% of the source lines there's little benefit to reuse.

Traditionally, vendors who supply proprietary code that will be included in a production system (like protocol stacks, operating systems and the like) provided libraries compiled on a particular CPU architecture. You link these into your code. But for as long as I can remember engineers grumbled that the provided API was both interface and insulation. Insulation, because who knows what boundary conditions lurk behind the often-inadequately documented API? Insulation, because it can be impossible to track down bugs that live in the nebulous region between your own code and that of the vendor.

Who hasn't gotten frustrated by the poor docs that sometimes cause us to prototype an API call, tossing almost random data at a package in an attempt to understand just how one goes about properly interfacing to a package?

We see it in the hardware, too, when a peripheral's control registers either don't work as advertised, or there's some bizarre combination of bits that drive the thing into a crazy mode.

And yet there's a part of me that doesn't want exposure to the internals of some other company's code. I really don't want the source; I want a clean, clearly-defined interface that works as advertised. Returning to the hardware analogy, it's fun but unnecessary to look at the schematic of a flip flop. The interface at the pins is really all that's important.

But in the software world we've all been burned enough that trust is scarce.

Then there's the stability issue, especially in these strange economic times. If I have a package's source there's much less risk if the company goes out of business. I may not want to support the code, but that's better than getting set adrift by the seller's bankruptcy. Yes, it's possible to set up a source code escrow, but what are the legal implications of dealing with that escrow? Why add layers of hassle?

What do you think? Is not having the source a deal-breaker? Or, conversely, does the source make a vendor's product more compelling to you?

Published July 27, 2012