The software industry’s conventional wisdom holds that the underlying technology “stack” – code base, database, development tools – doesn’t matter. It’s the end product – what the users see and use each day – that matters. After all, most software is selected by business users that don’t need to know “how the sausage is made.”
In large part, I agree. Years ago, I tried to market software based on underlying code. I failed.
From the buyer’s perspective, the most important criteria are that the system does what they need it to do and that it’s relatively easy to use. Most buyers just don’t care about the underlying technology because they never see it or interact with it directly. Nor do they understand it.
However, long term, these same buyers will want their software vendor to:
- continue to add new features and fix bugs quickly;
- evolve to the next generation of technology; and,
- remain “strategically viable,” not just financially viable.
Underlying software technology is a huge determinant of any vendor’s ability to deliver on these three requirements. Software companies using older, inflexible technology have a hard time releasing new features, rarely prosper in the next generation of technology and wither on the vine for decades (rather than go bankrupt).
Recently, I was reminded of all this when ERP software company Consona acquired Compiere – a fairly unknown open-source ERP vendor. In my opinion, Consona bought Compiere not for its open-source business model, but because the Compiere product is built on a very modern technology stack and is designed to run in a cloud computing environment.
Why do I think this? Well, in part because Consona CTO, Steve Bailey said so:
“Compiere is the world’s leading open-source ERP solution and the products are brilliantly architected. They run on a fully open-source stack (e.g., Java, Linux, JBOSS, Postgres), utilize a browser-based AJAX UI based on the Google Web Toolkit, and are fully operational either on premise or on a utility cloud platform like Amazon…”
But more telling is that this acquisition diverges significantly from the traditional “roll-up” acquisition strategy of companies like Consona, Infor, Oracle and Sage. Usually, these consolidators are focused on buying companies with hundreds or thousands of customers that pay very profitable annual support fees. If they take good care of those customers, they can continue to collect those fees and increase profits through economies of scale.
While Consona has aquired a number of software companies based on this model, that doesn’t seem to be the strategy behind the Compiere deal. Compiere brings only 130 customers to Consona and I doubt Compiere’s open-source business model was generating big profits. Instead of buying customers and profits, Consona seems to be thinking ahead about how they can lead the market in the next generation of technology. The acquisition is more about growing organically – selling more Compiere systems – than it is about harvesting customer support contracts.
Why is this all relevant to software buyers? Because there is a big shift underway from client/server systems installed “on premise” to cloud-based or software-as-a-service systems that are hosted in a secure data center and accessed through a web browser. Moreover, the open source movement is producing underlying technology that is not only free, but increasingly really good stuff. Software vendors that don’t make the transition will wither on the vine.
Compiere is built on the Java programing language, Linux operating system, PostgreSQL database and Google Web Toolkit user interface framework – all technologies that are free to Compiere and its customers. Additionally, they are being enhanced every day by armies of volunteer programmers. That allows Compiere to just focus on enhancing its application functionality for accounting, manufacturing, distribution, etc.
To highlight the significance of this model, consider that a bunch of brilliant Google engineers built some cutting edge user interface technology (Google Web Toolkit) and open sourced it. Compiere turned around and used it in their products. Google did a big part of Compiere’s engineering for free…and will continue to do so. Now that’s efficient development.
Compare that to an application software company that has to pay ongoing royalties to an infrastructure software company for the privilege of developing on its outdated database or development tools. The smart engineers long since left both companies so they could work on cooler projects at more modern software companies. The mediocre engineers that remain are having a hard time developing new features on old code. Sales are declining and customers are defecting (albeit slowly because it’s hard to switch).
You don’t want to be that customer that is trying to defect but fears the switching costs. You want to be the delighted customer that loves their software because it works today and will work tomorrow, regardless of what new requirements emerge.
Honestly, I don’t know too much about Compiere and this post is not meant to be a plug for them. Consona is a customer of ours, but so are almost all of their competitors. I do know that the underlying open-source stack is good stuff. Moreover, I think the strategy behind the acquisition is a smart detour from the same old roll up strategy.
What I find most interesting is that a meaningful player in the ERP market is making a big investment in underlying technology. Why? Because long term, it does matter.
-
http://jamesdixon.wordpress.com James Dixon
-
http://www.catura.de/blog Trifon Trifonov
-
http://enopensource.sandfort.net Yves Sandfort
-
http://www.philsimonsystems.com Phil Simon
