Dana Blankenhorn has been a journalist, writer and part-time futurist for over 30 years.
I can't help but fixate on the fact that two of the five points (1 and 4) in the post are asking enterprise buyers to somehow give extra merit to open source software just for the fact that it's open source. I don't see (smart) enterprise buyers doing this, just for the fact that they exist to serve their company, not a software idealogy. I don't readily buy the idea that we should be giving any special "recognition or reward" to anyone just because Open Source is being used. Saving the company money - yes. Completing a successful implementation - yes. Providing the company some kind of competitive advantage or streamlining a business process - yes. And I agree that Open Source can do all of these, but Open Source should be the means, not the ends.
In the selection process itself, the one place where this is understandably a hard-sell for businesses IS the perceived "freebie" that consultants and vendors of commercial software are willing to offer in the selection process vs. the "evaluate for yourself" selection process that Schott is advocating. Without someone able to quantify the back-end benefits of using Open Source software, I don't see many businesses who aren't already "in the know" spending resources downloading, installing, and trying to work with this software themselves to evaluate it. They are too busy trying to run a business, not play with computer programs.
As much as people "hate" salesmen, we still need people who know the product inside and out to demonstrate that the product will work. And yes, we don't expect to pay for a demo of a product that will not work for us, so we don't want to spend the time and money evaluating a number of products that may or may not work (and we don't know, because nobody is there to tell us). Yes, I know that the time taken to respond to an RFP and learn both my business and understand the software takes time and money, and I will pay that up front when I make my selection - but I will *ONLY* pay that to the one vendor that I agree to sign with, and even then, much of that work will already have been done with a vendor or consultant that already works with a specific software package, because they will already understand that software.
The real problem with the open-source method of software selection that Schott seems to be advocating is that part where I take the up-front cost of evaluating even a small handful of packages. Not only do I need to make sure my staff does a good job of learning my business outside of their own department, I also need them to learn a handful of software packages in order to determine if any of them will fit these needs. That's a skill-set that is extremely rare. The risk associated with this kind of evaluation process can make the "back end benefits" (which by themselves are hard to quantify, even by the Open Source vendors themselves) less than enough to justify taking this approach.
Let’s start the second half of the baseball season with an important statement.
For open source to push further into enterprises, enterprises need to change their procurement policies.
Mulesoft CEO Greg Schott (right, from Mulesoft) chatted with me about this over the weekend, and he’s got an excellent point.
“Companies are interested in open source but when they try to consume it with the same model as commercial software things break down,” he explained.
“They’re looking for busloads of consultants and engineers to download the product, install it, go through Requests for Proposals (RFPs) and open source companies are not set up to do that. We’re set up for companies to do that on the front end and benefit on the back end.”
This is important. A lot of enterprises think services like that are “free” because no bill comes, and if another vendor is chosen nothing is paid for them. But they do cost. They are folded into your cost when you sign on the line which is dotted.
By contrast, Schott notes, open source may cost time (i.e. money) to set up and evaluate, but you save that on the back-end, on lower subscription costs and no initial license cost. You have to sell yourself, in other words, but you save big.
Schott, a former top manager at Agile who now has open source fire after a stint at Springsource, has developed his thoughts into a series of bullet points companies might want to think about when comparing open source with commercial software:
1.Establish open source centers of excellence. You need someone internally who’s advocating open source.
2.Understand the different evaluation process. You don’t invite IBM, Oracle and an open source vendor through the same process.
3.Establish your own selection criteria. Instead of having an analyst’s checklist of 50 items and making sure everything’s there, ask what you need.
4.Recognize and reward where open source is being used. If you have people doing the work to get open source running, reward those people.
5.Enterprise license agreements (ELAs). Get ELAs itemized so you can pull components out. That will keep big vendors honest over time.
It’s a sign of confidence on the part of open source executives like Schott that they are now willing to admit you can’t compare open source to commercial offerings, apples-to-apples. That’s not a bug, it’s a feature. Taking pride in it, and having prospects adapt to you, is a good clue.
