Code Is Not A Commodity: Why Software Is Not Like Soybeans

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Code Is Not A Commodity: Why Software Is Not Like Soybeans


Author’s note:  I am a big admirer of Paul Graham and his writings.  Mr. Graham  is an exceptionally gifted  writer and thinker.  This is my first attempt at writing a longer, essay-style “thinking piece”.  Though my writing will likely never match his, it is hopefully of some interest and value to you.   Thanks for your patience as I experiment with this new format.  I would appreciate any feedback or comments you have.

Code Is Not A Commodity:  Why Software Is Not Like Soybeans

Every now and then, I hear someone say:  “software is becoming commoditized”.  The idea is that as the tools have gotten better and it has gotten easier and easier to build software products, the end result becomes a commodity to the point that it is no longer possible to differentiate a business based on the software.  Software, the thinking goes, is easy to replicate and as such, any potential competitive advantage that can be gained is temporary at best.  

I fundamentally disagree with this line of thinking. 

One of the core elements of a commodity is that various offerings are almost indistinguishable from each other.  This is why the classic commodities are things like soybeans and other agricultural products.  In many of these cases, commodities can (and are) traded on some sort of exchange.  What makes this trading possible is that the products are more or less homogeneous.  One ton of soybeans is about the same as another ton of soybeans.  When dealing with commodities, the market determines the price.

Now, let’s take a look at software.  One of the common arguments given as to why software is becoming commoditized is that the “tools are getting better”.  The thinking here goes that as the tools get better, it becomes easier and easier for people to create software products.  This leads to commoditization because software is less and less differentiated.  Since it is so easy to replicate a software product, the result is homogeneity.  I think this is misguided thinking.  Just because the tools get better and creating software becomes easier does not mean that the products are less differentiated and becoming commodities.  

As an example, back a long, long time ago (in computer years), the software industry evolved from using low-level languages like assembler into some higher order languages like COBOL, Fortran and C.  As a result, it became much easier to create software that solved similar problems than it was before.  The higher order languages allowed for better abstractions which in turn made it possible to write larger, more complicated programs – all other things being equal.  So, inarguably, back then, the tools for creating software got much better.  But, did we see a commoditization?  Were all software products practically the same because they were written in the same set of languages?  I would argue not. 

Given a relatively complicated problem to solve, even equally gifted programmers will come up with solutions that are often radically different in their implementation.  I’m not talking about just the user experience, but also the underlying design and architecture of the software is radically different.  Software development is often a series of tradeoffs and those developers that succeed over the long-term are the ones that understand the subtleties of the trade-offs and tend to make better choices for their given situation than their peers.  What makes a great programmer is not just picking the right tools, but in understanding the tradeoffs and making the right choices. 

One of the outcomes of good software design and making the right trade-off choices is that over time, the better designed product “wins” as it is easier for that team to adapt to market conditions and exploit future opportunities.  Manyy successful software startups that I have seen can trace a large part of their survival and success to a core set of developers that knew what they were doing and were able to build a body of code that could be leveraged for future opportunities.  One of the biggest advantages of these small, well-knit teams is that there was a shared understanding of some sort of “meta framework” that made it possible for this group to do spectacular things that others could not.  Those companies that treated software as a commodity believing that simply hiring “the best programmers” and throwing them together to write code often failed.  They didn’t fail immediately, but they failed eventually because another group could leverage their code and exploit future opportunities better than they could.  Only a part of the value of software is what it does today in the form of a product that can be sold.  A large part of the value is what can be done with the underlying code in the future.  

Now, let’s look at the code itself as an “asset”.  Let’s assume we are looking at two different code-bases, written in the same language and that are more or less solving a similar problem (like a social book-marking website).  How does the market value the code itself?  That is, if both of these bodies of code were written by now bankrupt companies and being sold on the open market, how does the code get valued?  What would people pay?  The answer is, it depends.  What does it depend on?  Well, it depends on what can be done with the code.  Chances are, if the code is separated from its creators, its value goes down dramatically.  The reason is simple.  Code and its creators are inextricably intertwined.  The people that created the code are the ones that can best leverage it to create future value.  If you’ve ever tried taking over someone else’s software and maintaining it, you’ll know what I’m talking about.  

If code were a commodity, then it should be easy to value it and determine a “market price”.  We should have some way of calculating the relative difficulty of the problem, lines of code used, technical choices made (language, platform, etc.) and measure the “usability”  of the product through user testing and come up with an approximation of the value of the product.  If software were a commodity, it would be easy to do this.  But, as it turns out, it is not.  Much to the dismay of folks outside of the software industry, software assets are notoriously hard to value.  The reason, I think, is quite simple.  Software is not like soybeans.

Posted by Dharmesh Shah on Fri, Jul 07, 2006


Dharmesh, I am confused. Is this your post or someone else's? The author's note says: "This is my first attempt at writing a longer, essay-style “thinking piece”. " - But ALL (most?) your posts so far have been exactly that: essay-style "thinking pieces."

posted on Friday, July 07, 2006 at 11:38 AM by

I think all of this stems from the fact that most managers fundamentally don't understand software. They try to come up with metaphors in their mind to try to cope with this lack of understanding. Classic examples include cars, tools (hammers, wrenches), building construction, etc. Not only are these terrible metaphors, they lead to the commoditization argument.

I don't think that the whole scope of software has ever seriously been argued as commoditized. I think that most managers understand that the architecture and design of software is an artful skill that is valuable and differentiatable. However, I think that most managers believe that any old programmer, once given a design and architecture, would subsequently crank out an exactly identical program. This is where the commoditization argument is most popular, and explains the outsourcing boom. After all, if a programmer in India creates the exact same code as a programmer in America, why not outsource? This is also why many Universities (mine included) concentrated on systems analysis/design over programming, as it is considered an uncommiditized skill.

Of course, this is completely incorrect. What 99% of managers don't realize is that software development (the actual construction) goes hand-in-hand with design and architecture, and separating the processes between teams (especially CONTINENTS) is a recipe for disaster. Coding, therefore, is just as artful a skill as design, and uncommoditizable.

posted on Friday, July 07, 2006 at 11:42 AM by Erik Peterson

@Eric: I believe that Neal Stephenson, in <cite>In the Beginning Was the Command Line</cite>, argues that it is the fate of all operating system code to become commoditized. (He goes on to point out that this is partly because an OS needs to have a published API in order for it to be of any use, which probably has a bearing on this discussion.)

Of course, Stephenson's argument is <em>much</em> weaker than "all software is becoming commoditized", or even than "all OSes are already commoditized".

Other people may, however, have made the broader contention that Dharmesh argues against.

posted on Friday, July 07, 2006 at 12:38 PM by Kai MacTane

It seems to me, that software commoditization proponents don't say that better tools, languages or any other kind of improvements in software development itself underlie coming software commoditization.

Their point is that commoditization will come from wide range of interoperable tools, provided as a service and their mashups. Those tools will be available to everybody, will have rich functionality, and high development pace, so you won't be able to create and sustain competitive edge by developing your own proprietary software. It doesn't really matter what kind of tools will be used to create these applications.

I myself don't think that this kind of commoditization will come to all domains and applications, but for some domains (with enough "mass", to overcome some threshold) things will probably go that way.

UPD: Some interesting thought has just popped up: better tools development may lower aforementioned threshold as the time goes.

posted on Friday, July 07, 2006 at 1:54 PM by Vladimir

I dont think i can fully agree to the point that Software is not commoditized. Again i think it depends from where you look at software as such.
In todays world, we see more and more applications that are being built that have so many customizationa and DIY features built in that it is very easy for almost any company to adapt and modify it to their environments with little of minimum developement activity.

But if we look at when developing the application itself, at the programming level itself, it is cannot be commoditized. At that level like you have mentioned, you need to be more focused on what tools to use, the architecture, the approach etc etc...

So yes the coding\development as such cannot be commoditized. But YES, the software application can be. Which means that companies dont need to invest huge amounts of money into developing custom solutions. They can go out into the market, buy a standard tool and armed with the application flexibility, trim and adapt it to their requirement.
Comparing this to the analogy you have given:
Soyabean can be grown using different methods, at different locations, under a greenhouse or in a farm(application can be built using different tools).
But in the end once you get the soyabean its a commodity(in this case the application itself) which you are free to use in whatever recipie you wish to cook. :)

Summarize: Coding is NOT a commodity But Software IS.

posted on Friday, July 07, 2006 at 1:58 PM by Ajit Gangadharan

Re: Ajit

I'd have to dispute that:
1. If software were a commodity, there would be no way to differentiate between pieces of software that serve the same purpose
2. There are ways to differentiate pieces of software that serve the same purpose
Therefore: Software is not a commodity

Take a look at this example:
Two software firms, independent of each other, recognize a need for a particular piece of software and begin developing it. Same target market, same functionality scope and depth, same understanding of customer needs. After development was finished, would both firms have software that was equally good? The answer to that is, of course, no.

Take a look at two project management products: Basecamp and Microsoft Project. They are both incredibly different. If software were commoditized, you could pick up either of the two, regardless of your needs, and each would suit you perfectly well. But that of course is not the case- each product is narrowly tailored to it's target market. That, by definition, is a market that is non-commoditized.

I'm not exactly sure if all of that is what you are arguing, though. You mention quite a bit about prepackaged software that is customizable. Isn't the level of customizability inherently a differentiating factor? To accept that two pieces of prepackaged software used in this way were to be commodities, you would have to assume that they would both offer similar levels of customization.

This seems to me like you're thinking of things like ERP software that is, by necessity, infinitely customizable. You can't use a product like SAP right out of the box, and so therefore it is not a finished software product- it is merely a tool to help you arrive at a completely customized software product faster. SAP is an example of a 100% non-commoditized piece of software: Every single deployment of the software is completely unique.

posted on Friday, July 07, 2006 at 2:32 PM by

RE: Erik

You sure have posted valid points. I would agree to what you have said, but then again only if i were to look at it from your point of view.
I think it is all a matter of perspective.

If we are to take an example of databases, you have numerrous options to choose from, and with APIs available today they can easily interact and talk to each other. Of course they some have edges and differences which is what makes a end user select the one that best fits their need.
Now is database a commodity? Todays applications are as comfortable using a oracle database as they would a MSSQL database. Of course there are advantages and disadvtgs in using either in any given scenario, but yes, you coul pick any and you could make it work.

We have soyabeans in different sizes and shapes, different pricing and nutrition values. But we just pick the one that offers the best price, quality, and what fits out recipe. Can you use any soyabean? Maybe, yes maybe not. But yes it is still a soyabean.

This is not an argument, just a view point. We may or maynot agree to it. The whole point is to throw out some thoughts and interact and get a different perspective.

posted on Friday, July 07, 2006 at 3:27 PM by Ajit Gangadharan

I'm not a tech geek (I was one of the few that voted to be a biz geek in the recent poll...) so I don't really have an informed view on the question raised about the commodization of software.

But I do see in software applications the standardization of functionality. I work in the financial tech space and for example can't began to count the number of online equity platforms that have almost identical functionality.

Undoubtably different OSs and languages were used to develop these systems but they do very similar things. The creation of radically new applications does not often happen.

My Father starting working with mainframes in the 60's and I always loved the stories of the early days of writing programs on punch cards and handmade compilers. I guess compared to those times the tools and languages today are pretty commoditized. Thank goodness for that! We can easily build very cool things with the great tools available now.

posted on Friday, July 07, 2006 at 4:21 PM by

There's a difference between functionality similarity and commoditization.

Take running shoes, for instance. They all have the exact same functionality and target market, but yet they are not commodities because they can be differentiated from each other. A Nike is not a New Balance and consumers know this. Whether it be by style or material quality or the fit of the shoe or weight or tread style- there are dozens of differences between two shoes in the same narrow market segment. I can wear New Balance shoes and I can wear Nike shoes, but that does not mean that New Balance shoes are the same as Nike shoes. If I have wide feet and a smaller budget, New Balance would be more tailored to my needs than Nike.

Translate to databases. While they can roughly inter-operate with each other, this is irrelevant. There are differences in the product that lead me to choosing one over the other. If I need to run complex reports and have a ton of data, I'll choose Oracle. If I have a write-intensive process, I'd be more likely to use MySQL. These are differences in the products that make them highly tailored to one particular segment of the overall database market. This is differentiation, which is mutually exclusive to commoditization.

If you take a close enough look at any software market segment, you will find differences in the competition. This is not just differences in features, it is difference in support/customer service, scalability, usability or any other of dozens of non-functional requirements for a piece of software.

Essentially, what I'm trying to say is that if a software market were to be commoditized, the following would have to be true:
1) The functional needs of the customer must be clear
2) Every product in the market must meet those functional needs equally well
3) The non-functional needs of the customer must be clear
4) Every product in the market must meet those non-functional needs equally well.

Considering that non-functional needs include things like support, and it is essentially impossible for two different firms to offer equivalent levels of support, then I would guess it is safe to call software non-commoditizable.

Even aside from that, there are just too many moving parts in software for differences to NOT exist. Once differences exist, differentiation will take place, and then you no longer have a commodity market.

posted on Friday, July 07, 2006 at 5:04 PM by

Do you mean to say that New Balance and Nike are NOT commodities?
There are differences, but on the whole they are just shoes. Some people know specifics of what they want, others just pick up any shoes - comfortable or better style. But on the whole there are just shoes available in plenty in different sizes and types and prices.
Databases are available in plenty, but yes if i am running a website and i really dont have any specifics on how my siteneeds to run, i just pick "one" of the databases. Database a commodity?

posted on Friday, July 07, 2006 at 5:39 PM by Ajit Gangadharan

Indifference in a portion of buyers does not mean that the whole market is a commodity.

>But on the whole there are just shoes available in plenty in different sizes and types and prices.

In commodity markets, all prices are the same because there is no difference between products.

Maybe I'm being overly technical and the point is more along the lines of "Software is becoming more like a commodity" rather than "Software is a commodity" or "Software is on the way to becoming a commodity". That, I can accept. As time goes on, the differences between software products will theoretically lessen, and therefore become more like a commodity, but I don't think they'll ever get anywhere near that level.

posted on Friday, July 07, 2006 at 6:38 PM by

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.

Most software is or fast becoming a commodity. Look at what makes commodities
1.things of certain value to the customer
2.of uniform quality ( please read carefully, it is uniform quality, not SAME level of quality)
3.produced in large quantities
4. produced by many different producers
5. it is the contract or function that define commodity not any quality inherent in the product
6. ability to substitute

I discussed this in depth on my blog

posted on Saturday, July 08, 2006 at 12:08 PM by Murali

I think a distinction needs to be made between horizontal applications, e.g. a web browser and more specialised software, whether a supply chain management system or a car's on-board computer system. Browsers are largely interchangeable so they are more akin to what you describe as commodities. In fact, they are given away so if the price got any lowere you'd be paid to switch to a different browser. On the hand, everything your write about creativity, etc is increasingly applicable as the software becomes increasingly specialised.

Keep up the excellent writing. Essays or pithy comments equally appreciated.

posted on Sunday, July 09, 2006 at 7:44 PM by Eugene

Best discussion yet.

I have to say that I came into this article believing, like Dharmesh, that software is unique and non-commoditized. Regretfully, however, I have to say that I'm now more inclined to think the opposite.

The mind-changing argument for me is the "technicality", if you will, that holds together the "not commoditized" viewpoint. Which is, that there's always at least SOME underlying differences in the code between two pieces of same-function software. As such, software cannot be the same, and therefore, software cannot be commoditized.

While this may be technically true, if the differences are so minute, and the impact of these differences are only critical for 1% of all applications, that’s enough for me to generalize that software’s a commodity. Sure, ERP software is different because the nuts and bolts underneath actually define the function and purpose. But ERP-like products seem more like the exception than the rule. I would think 99% of all software available for any purpose falls outside this special case category and is largely interchangeable. And sure, there are things like tech support and customer service, the intangibles, but to factor in these considerations is to compare whole companies. No doubt these kinds of factors are impacting and unique, but we’re just talking about the end product, the software.

To me, the non-commodity camp is trying to say “I have $1 to my name. That guy over there has $0.50 to his. I have more money, therefore I’m not poor.” If (almost) everyone else is in terms of thousands of dollars, who cares about such small margins? It seems easy to assume that everyone would just conclude both guys are poor.

Love your writings, Dharmesh... just not sold on this one. I would like to believe otherwise so please, someone help me out.

- John

posted on Monday, July 10, 2006 at 12:10 PM by John

A very interesting discussion. I think that we need to differentiate between what is a platform and what isn't a platform. Among those pieces of software that can be considered a platform you need to look at what makes one platform better than another for each component of your solution.

For example you have choices for OS (Windows, Linux, Unix, Etc.), DB (DB2, ORACLE, MSSQL, MySQL, Etc.), WEB (Firefox, IE, etc.). Being in support for several years I can tell you that if the software is understood by all and it supports everything you do then I would agree that platforms are commodities, but that is never the case. The primary reason is because with the inevitable changes to software to include better algorithms and evolving business processes or social processes there is an inherent problem with users adapting to those changes. These adaptations manifest themselves via support calls, peer dictates (managers or friends), etc.;
it is for this reason that both platform and non-platform software are not commodities, and they will never be commodities.

Earlier someone mentioned that the tools and methods available to produce the soybeans were different, but fundamentally a soybean was still a soybean. I would argue that if 5 farms produced slightly varying soybeans whether size, color, taste, that they would no longer be considered a commodity, or if you needed a specific amount of soybeans delivered to you on demand then you may work through a farm that could guarantee that service level. Alternatively if you can produce soybeans at a much lower cost via technology then you would have an advantage (withstand financial issues, grow faster by aquiring, etc.) over those that could not adopt the technology. This is why companies will always pay for a quantitative advantage over their competitors and why the companies that produce software will continue to advance the science of software.

Overall software design entails many different facets (look, feel, intuitiveness, speed, integration, support, etc.) of which pure functionality is only one facet. Until all facets become equall across both platform and non-platform software then I think that software will remain non-commoditized.


posted on Friday, November 17, 2006 at 6:08 AM by Daniel

Comments have been closed for this article.