Software Products: Own vs. Rent & Create vs. Get (Incorrectly Called Build vs. Buy)

Understanding the issue

Technology executives are often asked about their preferences on build vs. buy. This question would be better articulated as two separate questions: 1. own vs. rent and/or 2. create vs. get.

Why? The usual problems a company is trying to solve when they ask this are:

1. How can we have the products, features and/or functionality we want sooner?
   • This is a create vs. get question, i.e. Will it take longer to build it or to get an existing product then install, integrate and configure it?
2. How can we have a product that not only meets current requirements, but is also more likely to continue to develop to meet future requirements (foreseen and unforeseen)?
   • This is a own vs. rent question, i.e. Who do we think is more likely to innovate, continue to invest and do better future upgrades to the products: us, or a vendor?
3. Which is the more economical and cost-effective option?
   • This is a create vs. get question, i.e. Which option has better ROI, in-house or a vendor?
4. Which option will give us more business flexibility?
   • This is a own vs. rent question, i.e. Which option will give us a product that we can later decide to use for other purposes (e.g. sell or license to others)?

Building and buying are often part of the same concept of owning. For example, Google (the company) bought Android, Blogger and YouTube. Android, Blogger and YouTube programmers (builders) became Google employees. As a direct result of Google purchasing (buying) and thus owning YouTube, Google now builds and maintains it. In this example, buying and building are the same thing!

When people ask about companies buying software, they are almost always referring to licensing, leasing or renting software.

So instead of calling the debate build vs. buy, which is inaccurate, ambiguous and confusing, we should consider it in two dimensions: own vs. rent and/or create vs. get. Even these distinctions aren’t complete, however, because there are different types of ownership (e.g. owning a product vs. owning a license to use it) and different types of rental or leasing agreements.

Owning a product is different from owning a license to use it. For example, you don’t own Microsoft Word (unless you are Microsoft). You own a license to use it on a certain number of computers. Another example: While you may own the physical DVD disk, you don’t own the movie on it: the rights holder¹ does. You only own a license to play the movie for personal, non-commercial purposes. You are not allowed to play the DVD in a theater where you charge people to watch it. Nor are you allowed to distribute the film via a file sharing service. You are also not allowed to copy a long scene from the movie and use that video footage to create an advertisement for a product you are selling.² These examples are relevant to the incorrectly named “build vs. buy” decisions, because the type of ownership governs what you can do and cannot do with the product. That has consequences for the future of your business.

Open Source Products

When asking the own vs. rent question, using open source products falls in the own side, because open source licenses permit you to do as you please³ with your copy of the open source software and no one can take it away from you. Open Source software licenses grant you rights similar to those you’d have if you owned it.⁴ Open source makes owning even better. It enables owning and sharing at the same time, which benefits the community at large.

When considering create vs. get, however, open source products fall in the get side because just like paid products, open source products are developed by someone else; are already made; and they can be implemented and supported by third-party vendors.

The popularity of open source products is another reason why build vs. buy is not the right question. Open source products are both “build” and “buy”, in the ‘own’ and ‘get’ senses respectively.

Having a preference is a good thing

Sometimes technology executives try to answer this question in a way to avoid seeming biased. They claim they have no preference towards either owning or renting software. However, a preference (a good thing) is not the same thing as a bias (a bad thing). When a person provides such a noncommittal answer, it might indicate they lack leadership, vision and a clear philosophy, or the courage to give an honest answer.

I generally prefer owning over renting. This applies not just to software, but to other things in my life like owning a home and owning a car. There are other people who prefer to rent apartments and lease cars. Neither philosophy may be better in general than the other, but one of them is always better depending on the circumstances. That’s where leadership comes in. A leader has learned from experience and from others and thus has preferences, principles and a philosophy. Good leadership is based on evidence, research and science. Leaders who prefer either one of owning or renting can be equally successful in the same organization and circumstances.

The nine main reasons I often prefer my organization to own the software it uses for its core business functions are:

1. Competitive advantage via exclusivity, if desired.
   • You have an advantage over others who don’t have your software. They can’t just buy the products and services from the same vendor as you.
   • When an employee leaves your company to join your competitor, they can’t do the same thing they did for you there without your software.
2. Business flexibility. When you own the software you use, you can:
   • White-label and license the products and/or services implemented using it to other companies, generating revenue.
   • License some of your software itself to other organizations, generating revenue.
   • Open source it, giving back to the community (a charitable thing to do)
3. Economy and cost-savings when growing. When you own the software you use, you can use it without buying additional licenses for:
   • Companies that you acquire in the future
   • Implementing new products
4. Control over your data.
   • When a vendor manages your core business data, in most cases you have practically relinquished control of your data even though your contract may say on paper it is yours.
5. Superior integration and Time to market
   • When you own the products you use, it is often easier and cheaper to integrate with your other systems.
6. Faster time to market
   • Your timelines are less at the mercy of outside vendors whose interests may or may not be aligned with yours at any given point in time.
7. Superior integration
   • When you own the products you use, it is often easier and cheaper to integrate with your other systems.
8. Choice. When you maintain a great software engineering team in-house:
   • You keep your vendors on their toes, knowing that they are not your only option.
   • You have the in-house expertise to evaluate the vendor products, solutions and claims. The in-house folks’ interests are best aligned with your company’s.
9. The most successful companies have great software engineering teams that develop their core software.
   • Google, Facebook, Twitter, LinkedIn, Netflix, etc.: They all have great software engineering teams who build their core products.

The practice of renting too much of its software used for core business functions has run many companies into trouble.⁵ There are numerous examples of vendor solutions in search of problems. A vendor will often wow a team of executives with a product presentation and demo. The company will agree to rent the software not anticipating the cost increases over time. Later, the company will find it wasn’t worth the investment.

Vendor Evaluation Checklist (Starter)

When you do decide to use a vendor, consider using the following checklist.

When you meet a vendor trying to sell you a product or service, you must manage the meeting, instead of letting the vendor manage it. Ask the vendor the following questions.

1. What business problem does your product solve?
2. Who are your competitors?
   • If they claim they have no competitors, be cautious since it is unlikely to be an honest answer. Never assume that have no real competition like they claim. Do your own research on this regardless of how they answer the question. Compare their answer with your own findings.
3. Please give us a live demo.
   • Do they use another customer’s data in their live demo? If yes, did they have permission from the customer to show it to you? If not, it implies they are callous about data privacy and how can you trust them not to show your data to others in a demo or even use your data for other purposes?
4. We’d like to try before we buy but with no obligation to buy. Are you willing to do a test implementation (spike) with us at no or minimal cost to us?
5. Explain your pricing in detail.
   • Ask for this at the first meeting.

This is a just a starter checklist. I plan to write a more thorough vendor evaluation checklist in a future article.

Caveats

My preference to own applies only to software products for the company’s core business functions. For non-core back-office functions like corporate email, human resources, financial management, etc., I prefer to license software instead of owning it.

The future shape of software is changing.⁶ With Web-based applications and utility computing (“cloud” computing) becoming popular, even home users may increase the practice of renting software on a pay-per-use basis. I may write on that subject in the future.

[Authors Note: I expanded this post in July 2013 to provide more detail, but I purposely didn’t “update” it in the sense of making it current with respect to the times because I want to preserve this as a record of the philosophy I had back in 2007. To reflect the evolution of my thinking on this topic, I may write a separate article in the future.]

1. usually a studio [↩]
2. …except as allowed as fair use under copyright laws. [↩]
3. within reason [↩]
4. except the right to restrict its use by others [↩]
5. E.g. Vendor Lock-In https://en.wikipedia.org/wiki/Vendor_lock-in, Abandonware https://en.wikipedia.org/wiki/Abandonware , etc.  [↩]
6. Konary, Graham & Seymour; 2004; The Future of Software Licensing: Software Licensing Under Siege http://www.softsummit.com/library/white_papers/futureofsoftwarelicensing_idc.pdf  [↩]