What Is Core to Your Product?

By Ed Carroll, Agilis Solutions

An R&D executive at a large software firm was recently lamenting that he felt as though his hands were tied when he tried to be a good corporate citizen by reusing code owned by another development or product group within the company, let alone using code that is available as open source, shareware, or commercially available – either as a third-party product or from a commercial code library source.

Why do you want to own it?
Whether or not to own all of the code within your software product is a question in reference to owning your core intellectual property (IP). To most software engineering executives this may be a dumb question, which likely means that most VPs of engineering would prefer to own everything. Interestingly enough, there are just as many CEOs who are a little too eager to give away, buy or outsource core IP. Like most decisions, the best answer is somewhere in the middle. It is worthwhile to think through this issue before the situation occurs, so that when it does the CEO and VP of engineering can both sing from the same sheet of music. A large percentage of an executive’s job is to weigh the trade-offs and competing pressures caused by limited budget and exposure to various risks. The decision whether or not to develop a component of software in-house can be viewed as a classic make-versus-buy decision.

1. Price: Price can be a complex influencer in a decision. For example, is the component free (shareware), or does it carry a license fee that you must pay with each sale of your product? Is there a one-time development cost, or is this free code, but part of the open source General Public License (GPL)? Free software often seems compelling, as long as free also means free access to the source code so that one can be sure it is also free of defects, as well as easily maintained and extensible. Unfortunately, free does not always mean free in every capacity. Free might also equal junk code, or require significant integration work to make the free stuff work properly with the rest of your code. For example, I once had a marketing department so determined to “improve” our product faster than my engineering team could handle, that they hired another firm (without my knowledge) who promised to integrate their software into our product “for free.” Needless to say, the marketing department was a little disappointed and embarrassed when our entire product crashed and I had to pull engineering resources off a company-level top-priority project in order to solve the integration problem caused by this “free” third-party software – an expensive adventure.
   
   
2. Uniqueness: The most obvious reason to develop software with strictly internal resources is because that code is unique, patentable and sellable. No question there – the uniqueness of software code is where it often derives value. However, uniqueness does not need to be driven throughout an application. For example, an interesting start-up company is building a new product that promises to revolutionize content publishing. Recognizing this uniqueness trade-off, the VP of engineering is carefully incorporating small (non-GPL) open source snippets into his code base for those features that are generic to software applications and do not significantly contribute to the uniqueness of the company's offering. This approach allows his own team to focus on those features that truly do make his product unique.
   
   
3. Competitive advantage: Like the previous item, sometimes code should be written with internal resources in order to maintain a competitive advantage. On the other hand, there might be competitive advantage to using a third-party product. For example, few today would develop their own Relational Database Management System (RDBMS). However, a third-party RDBMS can add significant processing overhead to an application. If processing overhead is an important issue, then perhaps an alternative internally developed solution would make more sense.
   
   
4. Maintenance: One area that often is missed by those not directly involved in engineering is the high cost of software maintenance. Free or third-party products can have a devastating effect on product quality, mostly because of the unknown aspect of the code. Defects in third-party products always seem to be a surprise, and fixing the defects is never as important to the third party as it is to you and your sales efforts. An example of this was a product developed by a software company which utilized a leading RDBMS as its database engine. This software company had been successful in selling its product into ever larger server farms, and one day a customer with thousands of servers and even more thousands of transactions hit the transaction ceiling of this leading RDBMS. When the RDBMS provider was queried, they responded with something like, “Yeah, we know, that’s our transaction limitation,” leaving the software company to solve the problem some other way while its customer (a very large company) waited patiently. Product maintenance cost can be a very painful problem, because it often appears after sales are closed and there is usually no way to recapture the expense of fixing a field problem. Once that problem arises, having deep knowledge of the code makes problem resolution significantly easier than trying to debug and fix someone else’s (often undocumented) code. The ease of maintenance by knowledgeable internal engineers is offset when the resources within engineering who have that deep product knowledge are working on future products. Taking them off new product development, which means a delay for the new product release, can be a very expensive solution.
   
   
5. Schedule: There are times when a market opportunity will not wait for an internal team to develop a solution. However, that assumes that a software component or product (yours or theirs) is static. The problem is that usually either your product or the third-party product is constantly evolving. This evolution is a problem because it builds in a dependency between product releases that are often in conflict with each other. Your product requires version 5.3 of their product, but version 5.3 will not be released until 2 weeks after you need it, so you adjust your schedule to accommodate their release schedule. Then two days before their release is due, they announce a one-month delay. Had they told you a month earlier, you might have been able to compensate for the delay, but their schedule is not your schedule. A good example of this is the Microsoft Vista product suite. Microsoft has said that when Vista is released, they will sunset some of their older underlying technology. If your product is dependent upon one of these technologies, when should you spend the money to re-architect your product (Vista was delayed almost 18 months)?

Reusing someone else’s code
Is there an easy way to reuse someone else’s code? Probably not, unless you are willing to absorb the risk of their code containing defects that will impact your customer relations, cost and release schedules. If you cannot absorb this risk and you do reuse someone else’s code, take the effort to thoroughly test and perhaps even break down the code so that your engineers understand just how robust it really is, know its limitations, confirm that it integrates smoothly into your product, validate that there are no hidden surprises, and know how to fix it if it breaks. Then check it into a code library with good version and configuration controls applied. In other words, break the dependencies to the originator that will cause an impact to your cost, schedule or customers.

Licensed, open source or shareware
Sometimes it makes good marketing sense to buy someone else’s software and embed it into your product, even if you do end up paying a license fee that adds to your cost of goods sold. If your market value is not in the area of the licensed code, then it might be better to license than to reinvent. For example, I once developed a product that incorporated a linear programming module, which we licensed from a third party. This was worth the licensing fees to us, because we were not in the business of developing and selling linear programming. We figured it would cost us much more, and add a lot of time to our release schedule, to develop the module ourselves. On the other hand, we could have done so if the footprint or performance of the module were an issue. In this case, the third-party product was stable and did not have a lot of bells and whistles, which we would not have wanted.

Similar trade-offs exist for shareware and open source, with their added advantage of being free (or nearly so). If the free code comes as source code that can be thoroughly vetted, then there may be very low risk to embedding it into your code. It is important to actually take the time to walk through the code, understand what each line is doing and to test it thoroughly. If it will take as much effort (cost) to do this sort of vetting as it would take to develop and test new code, then develop the code with the internal team (so that your team knows how to fix it if needed).

To embed open source software into your product has the legal ramifications around free use of the GPL (issues which I will leave to the lawyers). An important advantage to open source code is that it has presumably been validated by many others, making it more trustworthy. That might be true, and probably is true the closer one gets to the Linux kernel, but I would still run my own code reviews and validation tests on any third-party code before integrating it into a product.

Conclusion
The net-net of reusing someone else’s software is to think through all of the potential risks to your product that might impact your product cost, schedule and customers. If those risks can be mitigated, the dependencies broken or are significantly outweighed by the advantages of using the code, then reusing someone else’s code might make good business sense, but let the buyer beware – free is not always free.

About the author
Ed Carroll has been building software products for more than 20 years, with particular expertise in automating economic analyses, decision support and supply-chain management processes. He has provided strategic technology leadership in roles such as the vice president of engineering for Egghead.com, director of technology at Nike and director of software engineering at Boeing. He can be reached at EdCarroll@AgilisSolutions.com.