Open for business: How some sales processes don't work for OSS

No readers like this yet.
Open for business

Opensource.com

In a perfect world, the sales process for an open source business would be as simple as answering the phone and taking orders. Unfortunately, reality is seldom perfect, and the open source sales process faces a number of challenges. 

Chief among these is that companies have been conditioned to do business in a certain way, and while that standard system works fine when acquiring commercial software, the traditional model breaks down when it comes to open source software. (For the record, I use open source to mean software that is truly open--i.e., where the licensing cost is zero.)

Proof-of-concept is a poor choice

For example, when a company is looking for an enterprise-grade software solution, a commercial software vendor would often agree to a proof-of-concept, or POC. In this scenario, the commercial software company sends an engineer, at their expense, to the prospective client’s site. The engineer installs an evaluation copy of the software and educates the potential buyer on the software's features, focusing on how it functions in that specific environment.

The software is left up and running for a certain amount of time so that the prospective client can evaluate the product. Then, at the end of the trial period, the license expires and the software stops working unless a permanent license is purchased. Since the licensing cost for the commercial software could be quite large, the vendor has an incentive to perform any number of these POCs--just one sale will more than cover the cost of those that don’t work out.

But this method falls apart when it comes to open source software. Your company can install the software, configure it for the client’s environment, even show the client how to use it, but then there is no way to recoup that cost with license fees. In short, while there’s no doubt that POCs are a great way to expose potential clients to your product, they simply aren't financially sustainable for an open source company.

Beware of any company that approaches you with the suggestion that you "just get it set up so we can evaluate it, and then we'll be certain to buy a support contract."

This is especially true if they’ve never contacted you before, yet say they want to buy your most expensive product. It is doubtful that this company is serious about a purchase. More likely, they think that if they dangle a big enough deal in front of you, you'll provide free services. You don't want these clients.

The clients you do want realize that your time and expertise are valuable. Although almost all open source companies produce software, most make their revenue through services, and so the best way to be successful is to focus on services revenue as a significant source of income. And while this may seem counter-intuitive, it does involve charging for pre-sales.

As I noted above, companies have been conditioned to do business in a certain way, and many balk at the idea of paying a fee in order to evaluate a solution. It can be hard to change this mindset. Sometimes, I’ll explain it to a prospective client this way: You pay a doctor, a plumber, or an auto mechanic for their expertise. They provide a service, not a product. Open source software works the same way. The product itself is free; open source companies are in business to make sure this software works optimally for their customers.

The temptation, especially when you’re just starting out, is to do evaluations for free, just for the exposure. I strongly suggest resisting that temptation. While I'm more than happy to spend an hour on a basic demonstration over the Internet, anything more than that usually requires a purchase order. At OpenNMS we sell time--our own (which is obvious enough), but also our client’s. Our expertise considerably reduces implementation time (and thus cost). Our clients recognize that and respect this.


Request for proposal usually a time-waster

Which brings me to the worst time sink that an open source business can fall prey to: the request for proposal (RFP).

If you have been involved in enterprise software, you've seen RFPs. These are usually huge documents outlining vast software projects with strict requirements for response—none of which fit well into a services model. I was once asked to participate in an RFP for a large California college system. The accompanying documentation expressly stated that all services would be performed by another company, but I was still welcome to submit a proposal. Since all I provide are services, I declined the opportunity.

I call the worst RFPs 'Hail Marys,' after the 'Hail Mary' pass in American football. This is when a third party wants respond to an RFP, but they are missing a key component and they want you to supply it. Here is an example (taken from an actual email):


"I have a tender in Turkey and would like to submit a solution to them. The tender is in the telecommunications sector, and we are going to submit [solution #1] and [solution #2] to a telecom operator. The customer expects a management system for the devices. Although there are primitive management functionalities for the devices, we assume there is not.

If you would like to give a proposal to deliver a solution for the tender, I will forward the management system part of the RFP. The RFP basically asks, NMS; fault management, performance management, and inventory systems."



Well, that's clear as mud. In just one paragraph this vendor has suggested my company undertake at least a week of unpaid work. And, even in the best-case scenario, we'd be a subcontractor on the engagement to someone who doesn't really understand our business or our product.

Even RFPs submitted directly to the company requesting the proposal are rarely worth the effort. Last year, we had one such RFP that we felt pretty good about. I even hired an expert at writing response documents. After several weeks of work, and several thousand dollars, we did not get the bid.

I'm not saying that all RFPs are bad and that you should never respond to one, but I will caution that for most open source businesses it doesn't make good financial sense. Hunting elephants may work for companies that generate revenue on license fees, but it rarely works in open source.

In both the case of pre-sales and RFPs, I suggest that the client purchase a services project in order to explore an open source solution. Even if it takes a week or two, the cost of that time pales when compared to commercial software solutions that can run to hundreds of thousands--if not millions--of dollars.

Simon Phipps recently wrote an article stating that companies should be willing to pay the same for an open source solution as for a comparable commercial software solution, even though the former lacks a required license purchase. I don't disagree with him, but I think it is important that open source companies re-frame the entire purchasing process.

Due to the inherent freedoms in open source software, solutions built on them can cost less to implement and less to own--not solely due to the lack of license fees, but because they are simply better solutions. As I point out to prospective clients who are unsure about paying for pre-sales: While you may not be willing to explore open source, you can bet your competitors are, and they can use their savings to better serve their customers.

And if they can provide better service than you can, how long will your customers remain yours?


Chief among these is that companies have been conditioned to do business in a certain way, and while that standard system works fine when acquiring commercial software, the traditional model breaks down when it comes to open source software. (For the record, I use open source to mean software that is truly open--i.e., where the licensing cost is zero.)

For example, when a company is looking for an enterprise-grade software solution, a commercial software vendor would often agree to a proof-of-concept, or POC. In this scenario, the commercial software company sends an engineer, at their expense, to the prospective client’s site. The engineer installs an evaluation copy of the software and educates the potential buyer on the software's features, focusing on how it functions in that specific environment. 

The software is left up and running for a certain amount of time so that the prospective client can evaluate the product. Then, at the end of the trial period, the license expires and the software stops working unless a permanent license is purchased. Since the licensing cost for the commercial software could be quite large, the vendor has an incentive to perform any number of these POCs--just one sale will more than cover the cost of those that don’t work out. 

But this method falls apart when it comes to open source software. Your company can install the software, configure it for the client’s environment, even show the client how to use it, but then there is no way to recoup that cost with license fees. In short, while there’s no doubt that POCs are a great way to expose potential clients to your product, they simply aren't financially sustainable for an open source company.

Beware of any company that approaches you with the suggestion that you "just get it set up so we can evaluate it, and then we'll be certain to buy a support contract." 

This is especially true if they’ve never contacted you before, yet say they want to buy your most expensive product. It is doubtful that this company is serious about a purchase. More likely, they think that if they dangle a big enough deal in front of you, you'll provide free services. You don't want these clients.

The clients you do want realize that your time and expertise are valuable. Although almost all open source companies produce software, most make their revenue through services, and so the best way to be successful is to focus on services revenue as a significant source of income. And while this may seem counter-intuitive, it does involve charging for pre-sales.

As I noted above, companies have been conditioned to do business in a certain way, and many balk at the idea of paying a fee in order to evaluate a solution. It can be hard to change this mindset. Sometimes, I’ll explain it to a prospective client this way: You pay a doctor, a plumber, or an auto mechanic for their expertise. They provide a service, not a product. Open source software works the same way. The product itself is free; open source companies are in business to make sure this software works optimally for their customers. 

The temptation, especially when you’re just starting out, is to do evaluations for free, just for the exposure. I strongly suggest resisting that temptation. While I'm more than happy to spend an hour on a basic demonstration over the Internet, anything more than that usually requires a purchase order. At OpenNMS we sell time--our own (which is obvious enough), but also our client’s. Our expertise considerably reduces implementation time (and thus cost). Our clients recognize that and respect this. 

Which brings me to the worst time sink that an open source business can fall prey to: the request for proposal (RFP).

If you have been involved in enterprise software, you've seen RFPs. These are usually huge documents outlining vast software projects with strict requirements for response—none of which fit well into a services model. I was once asked to participate in an RFP for a large California college system. The accompanying documentation expressly stated that all services would be performed by another company, but I was still welcome to submit a proposal. Since all I provide are services, I declined the opportunity.

I call the worst RFPs 'Hail Marys,' after the 'Hail Mary' pass in American football (https://secure.wikimedia.org/wikipedia/en/wiki/Hail_Mary_pass). This is when a third party wants respond to an RFP, but they are missing a key component and they want you to supply it. Here is an example (taken from an actual email):

"I have a tender in Turkey and would like to submit a solution to them. The tender is in the telecommunications sector, and we are going to submit [solution #1] and [solution #2] to a telecom operator. The customer expects a management system for the devices. Although there are primitive management functionalities for the devices, we assume there is not. 

If you would like to give a proposal to deliver a solution for the tender, I will forward the management system part of the RFP. The RFP basically asks, NMS; fault management, performance management, and inventory systems."

Well, that's clear as mud. In just one paragraph this vendor has suggested my company undertake at least a week of unpaid work. And, even in the best-case scenario, we'd be a subcontractor on the engagement to someone who doesn't really understand our business or our product.

Even RFPs submitted directly to the company requesting the proposal are rarely worth the effort. Last year, we had one such RFP that we felt pretty good about. I even hired an expert at writing response documents. After several weeks of work, and several thousand dollars, we did not get the bid.

I'm not saying that all RFPs are bad and that you should never respond to one, but I will caution that for most open source businesses it doesn't make good financial sense. Hunting elephants may work for companies that generate revenue on license fees, but it rarely works in open source.

In both the case of pre-sales and RFPs, I suggest that the client purchase a services project in order to explore an open source solution. Even if it takes a week or two, the cost of that time pales when compared to commercial software solutions that can run to hundreds of thousands--if not millions--of dollars. 

Simon Phipps recently wrote an article (https://opensource.com/life/11/3/open-source-procurement-subscriptions) stating that companies should be willing to pay the same for an open source solution as for a comparable commercial software solution, even though the former lacks a required license purchase. I don't disagree with him, but I think it is important that open source companies re-frame the entire purchasing process.

Due to the inherent freedoms in open source software, solutions built on them can cost less to implement and less to own--not solely due to the lack of license fees, but because they are simply better solutions. As I point out to prospective clients who are unsure about paying for pre-sales: While you may not be willing to explore open source, you can bet your competitors are, and they can use their savings to better serve their customers.

And if they can provide better service than you can, how long will your customers remain yours?
Tags

5 Comments

I am waiting for the day when the RFP process gets the open source treatment - there are only so many questions that need asking after all.

In the future I envisage open marketplaces for matching customers and suppliers and an easy way to respond, with software automatically sifting the most promising proposals for the client. Once the "triage" phase is complete then the usual business processes kick in.

This removes the need for suppliers to be making up the numbers or filling in the blanks and protects them from the 11th hour showstoppers. The customer, of course, gets access to a wider pool of suppliers for less effort.

As Tarus points out, as a small firm, we cannot run the risk of getting sucked in to RFP's and accept we are missing opportunities but need to protect our time, so would welcome a more "market" based approach.

I helped convince a book distributor to go with an open source supplier of Adempiere. The cost over 5 years with implementation support wasn't much different than the proprietary competitor. But the selling point that resonated was the ability to switch support vendors at the end of the current contract (something that requires switching products with the proprietary system). The biggest obstacle was explaining to the CEO how they could "own" the installation with no license fee.

And that cost will only be driven down / become better value as open source usage and competition increases.

Hi Tarus.....very well articulated. Being India's First Open Source Integration Comapny we fight this day-in & day-out. We have worked on so many so called Leads which turned out to be time wasters and consumer of free services. My collegaue has even written a blog post on our sales experience within Indian context http://blog.infoaxon.com/how-indian-businessess-view-open-source/1174
We are moving to investing one time efforts in creating demo videos of our open source integrated solutions in KM and BI and using those as showcase of our capabilities on slideshare. For anything onsite we need PO.
Regards
Vineet
Co-founder & Director
InfoAxon Technologies Ltd.
INDIA's First Open Source Integration Company
Web : http://www.infoaxon.com
Blog : http://blog.infoaxon.com
SlideShare : http://www.slideshare.net/infoaxon

Very nice article! Last year I published a master thesis about this issue. It contains solutions to overcome challenges from a buyers perspective. It provides a way to adjust procurement processes to take open source software into account.

"How to buy something that is free?"
- Developing grounded design principles from
theory and practice, for the inclusion of free/libre
open source software in an organization’s tac-
tical procurement of software. -
http://mauriceverheesen.appspot.com/articles

More information? Twitter : multimho or see my website for my email address www.mauriceverheesen.nl

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.