“You can’t get there from here” is probably the most famous bit from Down East humorist Marshall Dodge. Having spent a good bit of time living in the North Country (that being how northern New Englanders refer to their environs), I’ve come to appreciate Yankee humor and wisdom. A nugget I gathered from a Norwich VT farmer comes to mind when I think about the “free” nature of open source.
“One time my neigh-buh, gave me a free truckload of topsoil,” Raymond told me. “By Gawd, that was the most expensive dirt you ever saw.” He went on to describe how he first had to dig out the big rocks, and then had to sift out some small ones. Weeks later the weeds started growing…and growing.
Free code comes with burdens, just like Raymond’s dirt. Some of them may be quickly obvious, like big rocks, and others might take a little more time to find, like smaller rocks. The most insidious are the latent ones, lurking like germinating weeds.
Companies absorbing open source should look at doing so as a purchase decision. Most companies “get it” when it comes to bringing in Linux or an open source complete application like SugarCRM. When we are talking about developers mixing open source code with their own proprietary code, however…not so much. It’s inherently hard to control what components and code fragments developers may grab because for anybody with a browser, literally tens of billions of lines of code are only a click away.
The good news is that IT professionals are pretty well equipped to work around or fix quality issues in the code they download. But any time they spend doing that is clawing back the cost savings and productivity gains they were aiming for by re-using code. IT pros are typically less able to anticipate problems that may be meta to the code itself—such as legal issues with the license or future support problems due to a lame support model in the project community.
Such use of open source components is an invisible part of the software supply chain. Through policies and processes, development organizations need to make it visible. And developers need the kind of proactive guidance and support that a purchasing organization would insist on receiving when purchasing commercial third party code. There is a cost associated with the use of open source that has to be weighed against the alternatives. But the more proactive and up front, the less the cost.
If Raymond had known what he was getting into, he would saved effort by sifting out the rocks up front and sterilizing the soil. Or, he might have said, “Thanks, but no thanks.” By the way, someone recently asked Richard Stallman if he’d been working with open source his whole life. His response was, “Not yet.” OK, not really, but if he was from Maine, that would have been a good joke.