by Christopher Lindquist

Could “Found Code” Cripple Your Company?

Apr 18, 20064 mins

Koders, Codase, CodeArchive, Gonzui, SourceBank. These are the tools of the modern programmer. Pressed for time, facing an overwhelming backlog, worried that your job is about to get offshored, and stuck on some small piece of a project that should have been finished two weeks ago, what’s the harm of visiting a source-code search site like those listed above and snagging a snippet to help you get ahead? Maybe plenty.

(Full disclosure: I’m working on a story about open source licensing and recently had a conversation with Doug Levin, CEO of “software compliance management” vendor Black Duck Software. Doug’s the one who pointed me to the world of source code search engines and their potential threat. Knowledge of that threat, of course, could lead people to purchase Black Duck compliance products (or those of their biggest competitor, Palamida). As such, you should consider my…source. )

The fact that code search engines let developers cut and paste code faster than they could write it themselves is a big temptation. But beyond the moral issue, there’s the legal problem such activity can raise. Black Duck and Palamida both claim that their tools can discover copied code even if programmers tried to hide their tracks with new variable names or modified white space. So even coders who think they’re being careful could be opening up their companies for trouble.

Worse yet, it’s quite likely you have at least a couple programmers who believe code theft is simply wrong (or a coder you just fired who’s looking for payback.) What if one of them decides to blow the whistle and turn you in to the likes of GPL Violations or the local district attorney? How would that look on the front page of the Wall Street Journal?

It amazes me that some companies are quite open in talking about their use of found code. In a March column, Michael Schrage discusses the development techniques of an entrepreneurial friend, Hans Peter Brondmo. 

Brondmo’s favorite development discovery occurred when he was stuck for a few lines of code. He realized that by Googling he could see if anyone anywhere had posted something he could use. He and his team found quite a few virtual solutions this way. “But what about context?” I asked. After all, not everyone documents their C++ in English. He dismissively waved his hand: “Code is code. I found something that looked like what I needed in the middle of what looked like a bunch of Chinese. You paste it in and see what happens. It worked.” 

What if the Chinese surrounding that code was a license that said “By using this code you agree to transfer to Bob Smith all rights to all software ever touched by these lines.” Heck, what if it was simply licensed under the GPL? (I’ve been trying to contact Brondmo about this but have yet to hear back. If I do, I’ll post his response ASAP.)

It’s easy to understand the temptation. Code search tools and open source can be the steroids of software development, turning journeyman programmers into stars and making superstars look all the more spectacular. And like steroids, the “everybody’s doing it, so I need to in order to stay competitive” attitude is sure to surface.

As a manager, keeping a lid on “found source” isn’t going to be easy, either. Unless you plan on filtering every potential source code site and locking down your programmers’ workstations to the point of making them useless, your developers are going to have ways to add code that they didn’t write to software that you need.

The key seems to be–no surprise–training and communication. First off, developers need to be aware of your awareness. If they know you’re keeping an eye out for copied code, they might be less likely to use it. Second, you need to develop policies around the practice just as you do around all other aspects of development. Do you forbid all external code? Do you allow code from software released only under certain licenses? Do you have a process for developers to submit external code for review?

The one thing you shouldn’t do is take the head-in-the-sand approach. Sure, what you don’t know might get that project out the door faster, but if the right people dig up that found code later on, it could be you who’s headed out the door.