Dharmesh Shah at OnStartups.com wrote an interesting article 'Code is not a commodity: Why software is not like soybeans' arguing that Software is not a commodity. You can read the full article here.
I fundamentally and totally disagree with argument. It seems to be an imminent confusion in differentiating the means from end. It is not uncommon for software developers to be frightened and threatened by the notion of 'Software being commoditized'. But unfortunately it is true that software is commoditized, very fast.
To understand with any kind of clarity it pays to see how we define a commodity. Wiki explains the commodity as follows on its page for Commodity:Â ( I took the simplified version to avoid any confusion. You can read the whole discussion on wiki for better understanding.)
...electricity (most users of electric power are only concerned with overall energy consumption; only a minority of users are concerned with the quality and technical details of voltage and frequency deviations, phase imbalance, etc.),...
In the original and simplified sense, commodities were things of value, of uniform quality, that were produced in large quantities by many different producers; the items from each different producer are considered equivalent. It is the contract and this underlying standard that define the commodity, not any quality inherent in the product. One can reasonably say that food commodities, for example, are defined by the fact that they substitute for each other in recipes, and that one can use the food without having to look at it too closely.
So in summary, what makes commodities
- things of certain value to the customer
- of uniform quality ( please read carefully, it is uniform quality, not SAME level of quality)
- produced in large quantities
- produced by many different producers
- it is the contract or function that define commodity not any quality inherent in the product
- ability to substitute
Now we have a common understanding about what can be treated as a commodity and what not. Let us discuss about software and the arguments (+ comments) in the original article. Keep in mind the following sample applications: database, OS, a word processor, a blog application and more complex ERP application for the rest of discussion.
- Software should provide certain value to the customer. Yes, most software does add value to the customer. The focus here is on the value it is providing, not how it is implemented. From a user perspective, it really does not matter how the developers implemented it(programming language, design internals and so on), only value it creates matters. While every program written by a developer is an expression of art, for the user it is not. So as long as the value it provides is uniform, it is a commodity once it satisfies all other conditions.
- Uniform quality not EXACT SAME QUALITY: Most software performs the required function with an uniform quality. Think about any application that is available in the world for any given function, like word processing, it works in a uniform manner with reasonable quality.
- Produced in large quantities: This is little immaterial to software, since once the software is developed, it is easy to produce the same software in large quantities. All it takes is a disc copy for most.
- Produced by many different producers: This is the most important point of the discussion. Any software solution can be produced by different companies, different programmers from across the world with reasonable quality with uniform function. Take database for example, almost all databases oracle,sql,mysql, postgre all provide the database function with reasonable quality, though they are produced by different companies and programmers all over the world.
- To be a commodity, it is not important to consider the quality of the function, but just the function. Because, not everybody wants highest quality of any product for that matter. Not every body needs a high resolution 44" lcd monitor. For most a 15" CRT monitor is just fine. The function is more important. Do you say LCD monitors are a commodity? or not. Because they are.
- Ability to substitute : This is very easy one. You can easily substitute any database server with minimal or no changes. In some cases, it is not so easy, this is not because the other product does not offer the uniform function, but because of lazy programmers who don't understand what an abstraction is about. One of the readers on the original post mentions about Nike shoes and its differentiated quality. I think that is not true. If am an athlete and want to buy shoes for jogging, nike, adidas, reebok, new balance and whole lot of other shoe companies offer reasonable quality shoes for almost the same price. The price difference, if any you pay for a nike's shoes is for the brand not for the quality. Lance Armstrong changed the brand after the cancer therapy. Many power basket ball and football for that matter any player changes his shoe brand, every time his sponsor changes. Doesn't that tell you that they all are of same quality?
One may argue that software built for a customer is so special and customized, so you can not commoditize this special application. You are wrong. If you follow building block approach, most applications in this world can be built using pre-existing frameworks, components and off-the shelf software applications with little integration and coding. Thesedays, most applications are opening up more and more interfaces for easy integration. Take any application you are building you are already using those building blocks. You are only applying a glue in between to deliver the business function. C++ STL, vast Java libraries, .NET framework libraries, Boost C++ libraries, specialized components from firms like Infragistics, 10s of Middleware, Messaging solutions, Databases, Topcoders, and 1000s of frameworks for PHP...and so on. Today, if yopu ask a consulting company to build a blogging platform, they might build a wonderful platform from scratch in 1 year, but I can just download movableType and start using it right away. If someone says, no my application is so special, please go and read concepts of abstraction. You will immediately realize that most part of the solution is already available as part of libraries and frameworks or in other applications. You just need to apply the glue to hold them together to solve the problem. Many consultants and software firms disagree. But I understand, why they say so. Update: Ning let you create simple social apps without any programming background. CogHead soon will let you create even complex business web applications without any programming background.
Software programmingÂ is so commoditized. You may argue this is not true. Let me ask you one question. If we have to build a house, how many people with a masters degree in architecture are needed. One or two for a reasonable house. How many interior decorators. One or two again. How many workers with a degree in construction engineering you need to construct the actual house. None. Once the house is designed and material is available, all you need is experienced masons/construction workers to build the house. So in software development. We need one or two excellent designers, one or two excellend architects, one or two DBAs and a whole bunch of software programmers, who just know how to produce the code as per the design.Â And the whole point is that this entire team is so replaceable, that makes it a commodity software development team.
Software is believed to not a commodity, because;
Software developers tend to think software as a very customized solution to each customer. That is not true for 99% of the software applications and 99% of any product out there in the world. Let me explain my understanding with a simple realworld example.Â
We want to a build a house. So we hired a firm that can build houses. The firm asked its architect to design the house. Design is ready. To build the house as per the design, the firm started working on preparing the material required for the house. They manufactured a single brick wall in the shape of the architects design with place holders to keep doors and windows. They manufactured windows and doors exactly as designed but as single pieces. House is finally ready as per the spec. After a few years, the house owner decided to change the window position slightly for better air inflow. Oh my god, you can't do it, because the entire wall is a single brick. So, the firm designed another single brick wall with the updated position of the window. This way, every house is so special, and the firm has to build every house seperately.
But imagine, if the firm created bricks in a reasonably small sizes so that you can build any shape of the wall with the same kind of bricks, not only you can build most buildings with the same brick but it is also easy to modify the shape with little reconstruction. Same goes with the windows, doors, safety systems, water supply, electrical wiring and so on.
NowÂ understand the key differences here, between the two approaches. One follows a single customized system approach while the other follows modular, flexible and evolutionary approach. Despite everyday applications, most of the software, even today, is built as in the first approach. A very specific solution that fits only for a single customer. For another customer, man you need another 2 year contract to build the same again.
But this is changing very fast. We are getting more and more generic frameworks and libraries. Most often, pre-built applications. So software is fast becoming a commodity.