By Tina Gasperson
IT Manager's Journal
March 1, 2007

Nelson and Reeves were in the MBA program at the University of Austin and won a business plan competition, along with some startup capital, for their open source business idea. "We saw a need in the marketplace," Nelson says. "It was the apocryphal conversation around a beer: 'There's gotta be a better way.'"

Before studying for an MBA, both men spent several years working in and around open source software, with companies like drkoop.com, SurfWatch Software, and NextJet. They loved open source. "We believe very firmly in the cost-effectiveness and the collaborative environment that makes for compelling products," Nelson says. "There is no company that we could afford, where we could directly email the developers, tell them a problem, and get a turnaround fix in a couple of days. You could pay for premium support from Oracle and they're not going to give you that kind of access. You get it automatically with an open source community."

But the benefits of open source didn't come without a set of drawbacks. "We saw that J2EE deployments were very time-consuming, error-prone, and full of missing pieces," Nelson says. "Companies were doing this on an ad hoc basis. We needed to bring that into a programmatic process and it needed to be done professionally. There are just way too many times in my past life when I've been up at the data center at three in the morning trying to make a deployment go smoothly."

So Nelson and Reeves conceived a plan for a commercial software package that could help companies automatically deploy, update, and uninstall Java-based applications. And to save money and develop the best product possible, they rely heavily on open source. The operating system is Red Hat Linux. "We'd prefer to go to Ubuntu or something like that," Reeves says. "It's just a bit more mature user interface." But since more of their customers build on Red Hat, Ubuntu will have to wait. They also use SugarCRM for contact management, CruiseControl for automating the build process, Subversion for version control, and MediaWiki for internal communications and the public-facing Web site.

Reeves says the company's approach to evaluating applications for internal use is simple. "Once you identify a need, you look for an open source solution. So far, the answer's been yes. And it's very easy to judge the quality of the product. How many people contribute? How active is the development stream? How many other users of the product have commented on it and viewed it? Determining quality is a lot harder to do with proprietary products. You really have to sort through the marketing message to start to ferret out the value. With open source software you don't have the veneer of marketing. It's very straightforward."

But, Nelson says, open source is not without its challenges. "There's a product we use called TrueLicense. It's an open source licensing product. We've had a challenge trying to force it into the mold of what we're doing. When you start to use an open source application in a way that it's not intended to be used, you run into problems. The temptation to do that with open source is a lot greater. It is so flexible and mutable and changeable -- you want to use it in lots of different ways, but that can put you into a trap. You're trying to fit a square into a circular hole."

Reeves gives a more specific example. "We use Nagios. Out of the box, you can set it up and have it monitoring specific processes running on the server. But because you can customize it so much, I have a tendency to think, 'If it can monitor my servers, maybe it can take corrective action when something goes wrong.' You're gonna run into some problems there. You have to be careful about how you craft that script -- you might cause more damage, and you leave behind the support network that makes open source attractive in the first place. You can mitigate that risk by letting the community know what you're working on, get feedback, and see if someone else is working on it too. When you start adding features and not doing it within the framework of the community, you might as well be doing closed source."

For other entrepreneurs considering the use of open source software, Nelson says to pick applications with "large communities. Describe your needs, choose something you're comfortable with. There are open source packages that are extremely complex. Some are simple. You need to tailor your choices to the area that you feel comfortable in. If you dive down into a very complex product and you don't need a very complex product, you're going to run into problems. At the end of the day, even though you have a community, there really is nobody you can make a call to that you know will answer the phone."

Reeves adds, "My advice would be to start small. Figure out a real problem you're having. In our case, one of the main ones was managing our sales process. For others, it might be managing time. Define your problem and look for an open source product to solve it for you. You can use closed and open together. I believe that as people begin to use open source software, they'll just start using more and more. Once you've used something and it works out great, you're going to continue."