Open source and innovation as maintenance models

Open source and innovation as maintenance models

Summary: Following my piece on a proposed model for enterprise applications maintenance, two fresh posts, one from Matt Aslett at 451.com and another from Leigh Cauldwell offer alternative ideas around how the present conundrum might be solved.

SHARE:

Following my piece on a proposed model for enterprise applications maintenance, two fresh posts, one from Matt Aslett at 451.com and another from Leigh Cauldwell offer alternative ideas around how the present conundrum might be solved. Matt offers the open source position arguing that:

 This would appear to be playing into the hands of open source vendors. But maybe not. Consider the recent discussion on open source business models. I wrote yesterday that “most open source vendors have some kind of ‘unique, must-have technology’ that is only available via commercial license or subscription.”

This is perfectly understandable given that many open source vendors are searching for the hook that will reel in enterprise customers and ensure that they convert enterprise open source users into commercial open source customers. Savio Rodrigues has been talking up this strategy for some time, while Matt Asay agrees that “any business must figure out a ‘proprietary’ differentiator”.

Deciding what that differentiator should be is, as Matt puts it “the nettlesome question” and many vendors have fallen back on the tried and tested enterprise software models and decided that commercial licensing, whether it be for proprietary extensions or a full blown proprietary ‘Enterprise Edition’ is the answer.

The problem with open source is that no large enterprise is going to bank its business on a model where there isn't a throat to choke when things go wrong. Open source may have significant initial cost advantages but the fact RedHat , MySQL and JBoss are in the hands of established commercial hands speaks volumes about the comfort factor businesses draw from this style of arrangement. In recent times, I have seen SugarCRM practices emerge but none are on a global scale. I would go further, arguing that at the other end of the scale, small businesses won't have the skills necessary to support open source. Some IT shops have taken this step but they are few and far between. I can only think of a small handful.

Leigh on the other hand has a much more radical approach:

We want to charge our clients for support and maintenance according to the measurable value that we create for them. Our clients want three main things from our software:

  • increased revenue
  • increased productivity
  • and more accurate figures and reporting

As the relationship with each client evolves, we're in a better position to know how to achieve those goals and to suggest new things to try. So, why don't we charge them for delivering those exact results?

I like this idea but wonder how well it will be received. I recall when i2 attempted to build a revenue sharing model with its trading platform. At first blush it looks attractive but over time, the company quickly found that as savings mounted, customers were less willing to share. That model failed. Then there is the problem of defining measures against which both sides can track and reward progress. We all know for example that SLA measures rarely fail because the SLA provider is in the hot seat for knowing the limits of their provisioning capability.

Leigh goes on to argue that such models require a significant element of trust. That's true but how many times do we find customers complaining about the relationships they hold with vendors? All too often there is an undercurrent of distrust. Part of the answer might come from improved transparency. I am finding that despite the disagreements I might have with SAP on certain issues, their efforts at being more transparent are allowing commenters such as myself far better insights into why certain decisions are taken. From what I hear, customers appreciate those additional insights.

As I've said before and whatever course is taken, the industry can no longer live with models that were more appropriate to another time. Debates of this kind can only serve both the industry and its customers better, especially as new computing models like SaaS and cloud computing emerge to challenge the status quo. Milking the maintenance cash cow can only go on so long. Far better the industry comes up with radical solutions now rather than be faced with wholesale revolt, skepticism and a deepening distrust.

Topics: Open Source, Emerging Tech

Dennis Howlett

About Dennis Howlett

Dennis Howlett is a 40 year veteran in enterprise IT, working with companies large and small across many industries. He endeavors to inform buyers in a no-nonsense manner and spares no vendor that comes under his microscope.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

2 comments
Log in or register to join the discussion
  • Throats to choke

    Excellent article but you state...

    "The problem with open source is that no large enterprise is going to bank its business on a model where there isn?t a throat to choke when things go wrong... ...I have seen SugarCRM practices emerge but none are on a global scale."

    I think this is harsh. The recent deal between BT and SugarCRM proves that large businesses will "offer their throats" to promote the product to their business customers. Whilst BT may not be truly global in the sense that say Sun or IBM are, I believe that global consultancy practices will recommend open source solutions where they are a good fit for the customer's requirements.

    http://www.theSugarRefinery.com
    ecentric
  • RE: Open source and innovation as maintenance models

    Hi Dennis

    Thanks for your thoughts on my posting (just spotted it on technorati). I agree that not all clients are likely to develop the level of trust with us that would enable this model, but I think the ones that do, will benefit from it (as will we).

    There are hybrid models that may do the job almost as well. We recently sat with a client and identified some business process improvements in their sales ledger roles, with associated software changes, and agreed that these changes should save one person-week in their monthly sales cycle. We decided in this case it would be too much overhead to measure the exact saving, so instead we agreed a fixed price for the work based on the projected value of the saving. The client was happy with the price because they could see a very clear ROI, and we were happy because we were able to charge a reasonable fee without having to justify it on a day-rate basis.

    This is a model I'm starting to use even with the more conservative clients, and they are responding well to it. Only the more entrepreneurial people are keen on a direct share-of-revenue or share-of-saving model, but we are quite happy to have a mix of different business models.
    leigh@...