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?
5 Comments