Open Source Business 3 + 3

June 11th, 2007 javier

Stephen Walli was kind enough to request my opinion on 3 success factors and 3 things to avoid when building an open source business. It’s hard to beat Stephen’s 3, I agree with all of them - one of the most gratifying being the user is in control, acting as a catalyst to spread the word and empowered to use your product in organizations who may not have traditionally considered your solution. The “sneaking into the floorboards” gets projects far more play and proves them out by the ingenuity and acceptance of the end user, and enables the user to satisfy their needs with what works for them - not what someone else decides to pay for.

But, 3 other things I can think of all generally focus on the sheer speed of innovation and success with Open Source:

1. By establishing and cultivating an open source community, you are much closer to your users. Their demands, ideas, and creative solutions are apparent to you much more quickly then in proprietary powerpoint-danced based solutions, where customers may not actually use the product for up to 9 months from the moment they start talking to you. This keeps vendors inline much more efficiently with the rapidly evolving requirements of their users.
2. Open Source users are more open to new and innovative functionality and they are downright eager to participate in the end stages of its development. There is a fine line to walk here, but essentially you can usually release much earlier betas of your product and get a wider set of usage scenarios vetting the quality of the software much faster then in the proprietary world where software hides behind a dark curtain of mystery until its released. Of course, this is not to be abused! If your betas are inherently broken the community will shun them. Ultimately if used right, the company and the community benefit from faster time to market for product development.
3. As a vendor, its incredibly rewarding to see and hear of your successes, whether commercial or not, so quickly. We released our 3.0.5 release of Hyperic HQ this week and I already have heard MULTIPLE comments from open source users and customers alike about how much they like the improved performance in their large scale deployments. Its been out almost 24 hours. Sure, some of that has to do with our upgrade model - but it has just as much to do with the openness of the community we support.

3 things to stray away from:

1. Building something cool shouldn’t be rocket science to use. Pay close attention to usage scenarios, common navigation and interpretation models. If your user is not a developer already - they probably won’t start installing by doing a compile. If you want fast adoption, requiring 2 weeks of training or months of professional services is one sure way to lose their attention and good faith.
2. Open Source is not a free ride to put out poor quality software. Just because they don’t pay for it, doesn’t mean that quality isn’t important. I know I said in #2 above that they are much more tolerant, but its no excuse to deliver something that doesn’t even turn on without command line flags, running in debug mode, or with constant error screens popping up everywhere. Your users will work with you, but don’t take them for granted.
3. Although surprisingly common, if you base your software business model on services alone for revenue, or even greater then 25% (completely arbitrary number), you are in trouble. One, its going to take you a LONG time to get critical mass of deployments. Two, its going to constrain your growth to hiring an army of professional services who you trust to be consistently as smart as you and as versed in your project. Three, its likely going to slow or stop your ability to generate real improvements to your project. Fixes may happen in the context of specific use cases but real innovation and extensions are going to be highly subject to a slow period in services… during which you aren’t making any money or growing! Not to mention you will likely be closer to airline staff then your own family, because of the rigorous travel schedules.

Entry Filed under: IT Industry, Javiers Blog