A few of you have probably seen by now the Enterprise Irregulars' rebuttal to Guy Smith's SandHill article. Guy's article essentially heralded in the end of enterprise software's reign and ordained it's next ruler: open source. Well, some of us in the Irregulars simply didn't agree and we chose to do so publicly.
By no means was our rebuttal an attempt to gang up on Guy or challenge SandHill's editorial capacity. Quite the contrary, it was an opportunity to take a provocative statement from SandHill and debate the core topic in open forum. I am very grateful that SandHill took the time and effort to compile and edit the over 4000 words of rebuttal to something they themselves had published. To me, this bodes well for the future of SandHill as an organization dedicated to quality content and one that can rebut it's own positions publicly.
Unfortunately, due to format at time, SandHill did not have the ability to publish all of our comments in their entirety. As those of you know, i tend to write longer pieces so it will be no surprise to find out that I wrote a much longer original submission for SandHill. There are actually a few arguments in the longer piece that I think are very relevant both to the rebuttal as well as the general Open Source debate as well. So i have published the full unedited text below. If other Irregulars put their full comments online as well I will do my best to link to them.
Uneditted Posts From the Group:
Update:
Some interesting commentary on our rebuttal - it seems everyone thinks everyone else doesn't have a clue.
Dan Farber does an overview on ZDNet
Jason and I get re-rebutted on an InfoWorld blog
Don Dodge tackles the semantics of Open Source vis a vis our rebuttals
Dan Farber follows up on Matt Assay's rebuttal to our post
Do You Really Need a Thneed?
Mark Twain once said, "The reports of my death have been greatly exaggerated." To some extent I feel like Guy Smith’s obituary for enterprise software vendors may soon suffer a similar rebuttal. I’d like to point out a few flies in the open source ointment that may make the enterprise software death knell a bit premature.
Problem 1: Each Layer of the “Stack” Can be Commoditized Equally
One large problem with Guy’s argument is that the whole stack (I assume he means hardware, operating system, web server, database, application server, enterprise applications) can be commoditized. In the technology world, to be a commodity really implies that a layer of the stack is fungible and can be swapped out at near zero cost with another equivalent player in that layer of the stack. While I would agree that a few layers of the stack are fungible, I would disagree that all of them share this characterization. Hardware is essentially fungible. Web servers are essentially fungible. But once you get into operating systems, databases, and enterprise applications, I would argue they are not (I straddle the fence on application servers). The reason for this is twofold: platforms and people. Selections of your OS, DB, and enterprise application layers have huge trickle down effects in the rest of the stack and your IT organization. Selecting Windows vastly changes the face of your organization in both skill sets (.NET/MCSE) and the applications you are likely to use (SQL Server, VisualStudio, VSS, etc..). Selecting a database or enterprise application will have the same effect. How many resumes say Intel or AMD specialist? Or even Dell or HP specialists? Now consider how many people say they are Oracle DBAs or PeopleSoft Developers?
The second problem with saying the whole stack is a commodity is the implication that no layers of the stack are customized. While almost no one customizes the x86 layer (yes, Google does build their own white boxes, almost every enterprise application implementation is a little to a lot customized. I know this because I work everyday with companies who own PeopleSoft, SAP, Oracle EBS, Siebel, and JDE. Having to customize and manage customizations is arguably their biggest nightmare and definitely their largest overall cost driver in owning the application. Customization is the de facto standard in the application industry and it is not going away until we all decided to run our businesses in exactly the same way. As a side note, SAP is doing some interesting work in process best practices (see this Business Process Expert section of SDN). One way to look at this effort is as a top-down approach towards standardizing business processes and thus reducing customer customization of SAP and the TCO of the SAP platform.
The point here in relation to open source is again two fold: first, the overall cost of owning a packaged application (e.g. the application stack) is not just the up-front cost of licenses but the ongoing maintenance cost. While the OSS vendors can offer cheaper up-front license costs, one of their weaknesses is that their eco-systems are still relatively small. How many practices at Accenture, Deloitte, etc. are built around OpenMFG versus SAP? How many resumes on Monster include PostgreSQL versus SQL Server? Granted this eco-system will shift over time with adoption, but it’s a chicken and egg. Accenture won’t bite until they can do a 1MM implementation, which means that OpenMFG needs to have a CIO that is willing to risk 1MM on an open source application. This may not happen any time soon.
Problem 2 : All Open Source Companies use the Same Model
Part of the problem with Guy’s argument is that he treats the open source moniker as if it was de facto a single business model. The implication is that any open source vendor essentially gives the software away for free (as it apparently costs them nothing to create and test), and then sells services or add-ons around the implementation, maintenance or ecosystem created by the software. This is in fact quite far from what is actually happening in startup land. I would characterize three basic models of open-source vendors:
1) Companies who purely provide services around an open source code-base. RedHat and Novell would be the closest example here.
2) Companies who provide an open-source version of their product as an entry point and then an enterprise version of this as well. SocialText, Zimbra and Asterisk would be good examples of this.
3) Companies who start their code base using open source software, extend it proprietarily with their own features, and then sell it using a classic enterprise sales model. StillSecure, who’s products are extended upon the open source Snort intrusion detection system, would be a good example [full disclosure, I am an investor in StillSecure].
The problem with model #1 is that in the long run this makes OSS companies look like professional services companies. If their margins start to reflect services companies (10-25% type of thing) then their valuations will go the same direction. This will cause a huge problem for the OSS market and I am actually going to predict that this will happen. I think the market is still infatuated with the growth rate and potential of OSS companies from a revenue side but is not considering the profit side (very few are even marginally profitable). Thus service-oriented OSS companies are getting valuations that look more like software companies than services companies. Remember all the internet services companies in the boom: Scient, Viant, March First? Their valuations were way out of line with traditional services companies until the crash. I believe we are seeing the same phenomenon with offshore services companies as well right now. As the market looses interest in top line growth and rationalizes valuation against the bottom line, the service-based OSS companies will either need to find a more classic enterprise software business model which gets them higher margins or accept their services-related fate and the low revenue-multiple valuations that come with it.
One problem which will occur if this happens is that the huge influx of venture capital money into startups with an OSS model will evaporate over night. While it is hard to pin a VC down on any consistent in their investment philosophy, one thing that you could nail every time is that they don’t invest in services businesses. Margins are bad and valuations are only 1-2x revenue. Not good for IRR. If this happens, the VC-funded OSS party is over. This alone would stop the enterprise software death march in its tracks.
Model #2 above really shows the weakness of the OSS development model. If you look closely at what most hybrid OSS companies offer in their “enterprise versions” (e.g. the non-zero-cost license model version), you’ll see something like Zimbra’s “Certified Software Updates”. In other words “we test this version in house.” Well – guess what, large enterprise CIOs really like to know their software is tested and validated to work with the rest of the stack. And this is one aspect that Guy misses out on. Part of the huge cost of developing enterprise software is making sure it works in the infinite permutations of the stack that your customer might have. This is a complete pain and is why SaaS is an attractive model for vendors as much as customers (the SaaS vendor owns the complete stack and only has to get their software to work with one permutation). In the end, part of the up front license cost simply pays for this activity. Until the stack is really a fungible commodity through standards and adherence to them (as discussed above), this is the world that enterprise software vendors have to live in.
Model #3 is essentially just enterprise software with a smart start. But ask any vendor who started with an open source code base and they will tell you, as soon as you customize the original OSS code base, it is unlikely you’ll ever go back and keep up to date with it. It just costs too much to remerge your extensions back. And if your extensions are proprietary then you won’t be contributing them to SourceForge any time soon.
So to sum up, I think while Guy misses the point in terms of his broad generalizations, there are some models he mentions that will dramatically affect the enterprise software market. In my opinion, OSS will have an affect in three specific areas. First, OSS applications will absolutely take over the real commodity parts of the stack (web servers, J2EE appservers, low-end databases). Where there is no need to customize and there is no specialized skill set, this makes a ton of sense. Second, this commoditization will make it hard for larger enterprise vendors to sell into the mid-market with traditional solutions. The mid-market has been heralded by some as the next set of green pastures for traditional enterprise vendor’s revenue growth. The company arguably most affected by this will be Microsoft with their imminent launch of the Dynamics suite into the mid-market. But the Oracle’s and SAPs of the world will feel some of that pressure as well. Their comeback will surely be SaaS models which are attractive to the mid-market and remove the discussion of OSS or proprietary altogether as the target company doesn’t install any software. This leads me to my third assertion. SaaS vendors built on top of OSS software have the biggest potential to impact the market. First, their startup development costs are low (the OSS code is free). Second, they don’t have to worry about certifying and testing for all the permutations in the stack (which means their ongoing development cost is much lower). And third, to one of Guy’s better points, their sales model is all online try-and-buy which is much more cost effective than fielding a direct sales force and going through 12 months sales cycles. The lingering question though is how much of the enterprise application world will SaaS really work for and how many vendors will a CIO have to go to get a complete suite? Many CIOs I have talked to have not made a SaaS investment yet because the functionality of any one vendor is not broad enough. The thought of integrating five vendors, especially when you don’t have the data at your own site, is daunting. Maybe SAP or Oracle will emerge with a broad SaaS platform faster than SF.com? They already have the software written so it’s free to them too. That, I think, is the 60,000 dollar question we should be asking – not which suit we should wear to Oracle’s funeral.
Final point you make Niel. Everything I've seen says writing for SaaS is not the same as on premise. SAP hasn't got this cracked for SMB - they've been courting other vendors. Can't say about Oracle unless you count uncle Larry's Netsuite as part of the picture.
Posted by: Dennis Howlett | August 08, 2006 at 01:38 PM