X

The secret of successful open-source companies, Part II

Starting an open-source company may be more art than science, but there are several principles that will enable you to effectively launch your open-source start-up.

Matt Asay Contributing Writer
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.
Matt Asay
4 min read

Last year (almost to the day), I wrote a post that detailed how JBoss went from $0 to a $350 million acquisition by Red Hat and scored a range of paying customers along the way. The research for that post was actually done in preparation for an OSCON presentation I was to deliver, which is the same impetus for this post.

One year later, my analysis of JBoss has proved to be remarkably accurate (at least for Alfresco). However, I was a little off on my timing (see the slide at right), and I didn't give enough credit to the power of open source to drive sales.

One year later, I'd add the following observations to my original analysis:

  • You don't need much in the way of field sales for the first three years, and maybe four, but you must balance this lack of quantity with exceptional quality. Basically, you want your field sales person (and it probably should just be one person per major geographic) to cover the big strategic accounts. It's not that inside sales can't do these but rather that you want them going for volume and the field sales person developing depth within a few strategic accounts.

  • Inside sales can do just about anything. I have yet to find a deal that my inside team can't close over e-mail and the phone. Of course, this means that:

  • If the product can't sell itself, you will die (a deserved death). You lead with a dramatically lower price point, which requires a dramatically lower cost of sale. Let the product sell, and let inside sales manage the process of turning conversions into cash.

  • Avoid RFPs (requests for proposal) like the plague. It's fine if your system integrator partners want to undertake the burden of filling these out, but RFPs are an excuse for a prospect to not choose you. If they haven't downloaded and been converted by the code, filling out an RFP will not help you. Your odds are better on product downloads than on product descriptions (in an RFP).

  • Your sales team needs "value triggers" to drive product perusers into product buyers. Proprietary software companies are such because they want to give customers a convenient reason to purchase. There are less admirable reasons, but that's the most basic one. Open-source companies need clear reasons why prospects should pay now rather than a year from now. Putting code in the customer's hand both helps and hinders sales. Find ways to make the former outweigh the latter.

  • A pure support model has a short shelf life, and it diminishes in proportion to how mature your product is. If you're new and buggy, support is a necessity. As your product matures, you need more value wrapped around the product. I believe that most open-source start-ups have three years in which they can get away with a support model. After that, they need to deliver something like the MySQL Network Monitoring and Advisory Service or the JBoss Operations Network: something that delivers a greater (perceived and actual) level of support and service than someone waiting by the phone can deliver.

  • Related to this last point, you need exceptional sales engineers in the early days of your company/product. Early on, you probably will have somewhat weak documentation and forum support but a lot of promise in the product to keep prospects interested. To ensure that they get value from the code, be sure to staff heavy with highly technical sales engineers. Over time, these positions can be more oriented to sales (70 percent) than engineering (30 percent, but at first, you want people that skew heavily toward engineering (70 percent) over sales (30 percent).

  • Your initial pricing should be something that a department with a larger enterprise can sign off on without executive approval. Most early open-source adoption happens in ad hoc fashion throughout an enterprise. Price accordingly. You can worry about the sitewide license once you have several departments within the same company. At first, just keep the price low enough such that it doesn't create too much friction for adoption of your product.

  • Sell value, not price. This may seem to contradict what I just wrote, but not really. You want the price low so that prospects can invest all of their focus on the value you bring.

  • As a new vendor, you need to disrupt. Therefore, harness the full power of open source. Your biggest need is users, not IP protection, as Mike Moritz has suggested. Who cares if your code is copyrighted if no one wants to use it? Protect your intellectual property by having it widely used and loved. Having lots of customers is a better barrier to entry than having lots of IP.
These are some of the principles driving my company's business. They have worked fantastically well for us. Please share any that have helped your company.