Owning Your Code: How to Automate, Manage Records at the Get-Go

By Mahshad Koohgoli  |  Posted 2008-12-05

Owning Your Code: How to Automate, Manage Records at the Get-Go

Code isn't what it used to be. No one buys into a whole package of anything. Even if you don't outsource code, developers are the chefs of IT, using an array of ingredients and creating a proprietary pot of stew. A few Google searches and you can find anything out there, tools and service repositories galore. So everyone picks and chooses, tailors and customizes and ...

Wait. How do you possibly keep track of this? How can you make sure you're licensed for these on-the-fly creations?

It is estimated that 90 percent of the code being used now is open source code. The use of that code is governed by rules and conditions associated with licenses. With open source code, there are up to 100 main licenses and up to 1,000 variations on these licenses. Developers would practically have to be licensing attorneys to know when they're breaching a contract. But, if you don't follow the license demands of each and every bit of code you mine and throw into your recipe, your company may find that its competitive edge and product line isn't exactly theirs.

The financial impact is enormous. If you talk to VCs, any one of them can tell you about an investment that went sour because of contamination or ambiguity surrounding the intellectual property. In the Microsoft-VeriSoft case, for example, some poor chap at Microsoft had taken 53 lines of VeriSoft code and included it in 160,000 lines that made up the code base. So it was 0.03 percent. Microsoft had to change 50 of the lines from C to C++. So there were only three lines of VeriSoft code left. But the judge gave it to VeriSoft. There is no reason Microsoft would have intentionally plagiarized it, yet they paid dearly.

Sometimes the infraction is as benign as searching the Web for a particular functionality, and cutting and pasting it from a file. ZDNET in the U.K. did a study that shows how the problem is exacerbated: 70 percent of developers carry code with them from company to company. They want their intellectual property, even piecemeal. My guess is the proportion is much higher than even that. And developers walking in the door with code from another company are difficult to detect or track. It only becomes an issue when a disgruntled employee leaves and some similar code appears in the marketplace.

The only way to protect against this sort of nightmare is to create good, automated records that are completely operationalized at the outset. You cannot rely on educating personnel. Period. You could scramble at product launch time, bringing in teams of experts to look at each line of code and certify it, but it's inaccurate and expensive. It's expensive to detect and expensive to rectify after the fact, if there's an infraction.

An Operationalized Management Library

An Operationalized Management Library

You need a management library, and a system that checks everything and automatically takes action when an infraction is found. And you need to have ownership policies that are the condition of employment, so you can keep track of what gets made inside the organization before developers leave. There are four steps involved in setting this up.

Step No. 1: First, you set up a management library that tracks all versioning. This part isn't new. Go back 30 years and these tools-Concurrent Versioning System, Clear Case by IBM, Terforce-all managed the code library. CV is free-so is SofVersion by Collabnet. It must be a managed library system so that all code resides within the library. Developers must check out any code from the library, and after they make changes, they simply check it back in. The system automatically does version control, history and changes. This is especially important if there are two people on a project who are changing code. This system could consolidate versions.

Step No. 2: Second, make sure you incorporate a bug management system such as Mantis or BugZilla.

Step No. 3: Third, integrate the management library into the network. The whole due diligence system must be based on the proposition that external content management is part of your quality management.

Step No. 4: Fourth, and here's the hard part: You must check all the code against company policy and have an automated system that takes action when there's a violation. The management libraries do not do this. Up to now it's been a manual, after-the-fact process. Ideally, make it part of the development. Have a solution that detects all code as it comes into the organization. It doesn't matter if that code is cut and pasted from the Web or whether developers bring it in on a memory stick from home. Create a system that identifies and checks-in real time-who brought in the code, where and when. It must recognize the IP attributes, log them, and identify the copyright and license data. It must also check them against policies you establish and then take the appropriate action if it detects a violation.

Yes, this is time-consuming to set up, but it must be thought of as part of the product quality process at the operational level. If you do all this and someone sues you, you can bet that the judge will look a lot more kindly upon your company if you've gone to this measure.

One of the best side effects of such a system is that someone is always responsible for any action taken. For instance, if there's a violation, maybe the system sends off an alert e-mail to Legal. Or you program it to pop up a dialogue box on the developer's computer so he can comment: "I only used that illegal code for testing. I will take it out." The developer is alerted and reminded to take responsibility.  


That's it. Remember, don't talk yourself out of it because the industry dynamics in place now demand that it's part of the development process: Bidding software on the Web, unprecedented access to code, Google search, increased regulatory guidelines and governance-these factors have converged. An operationalized library system is not only a natural at this point, but it has a very interesting trajectory. Think of the ways it can apply to digital content-and it will.

Dr. Mahshad Koohgoli is co-founder and CEO of Ottawa-based Protecode. Mahshad is a serial entrepreneur, with more than 25 years of experience in the telecommunications industry. His specialty is in technology startup businesses, having successfully managed three companies from the ground up. A visionary who holds several patents in the computer and communications field, Mahshad's current mission is to bring safe software development practices to the tech world. 

Previously, Mahshad was founder and CEO of Nimcat Networks (acquired by Avaya in 2005), as well as founder of Spacebridge Networks and Lantern Communications Canada. Prior to these ventures, Mahshad held various technical, marketing and senior roles at Newbridge Networks, Bell Northern Research and Nortel. Mahshad has a BSc and a Ph.D from the University of Sussex, England. He can be reached at koohgoli@protecode.com.


Rocket Fuel