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."
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.
@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.
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.
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.
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.
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.
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.
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.
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?
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.
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 http://blogs.inspions.net/2006/07/08/software-is-a-commodity-and-so-programming/
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.
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.
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.