Making an open-source living, part 1

While the training aspect of what they do is important, the company soon found themselves supplying more than that. "We used to do purely training, so we taught them Java and what we know about setting up a good development environment, and good design guidelines. Because of our interaction with the open-source community, we saw all this theory being put into practice in an open-source model, so what we did afterwards was expand this from a training-oriented approach to an approach where we were using open-source community practices with our customers' developers. We taught them to use source code control, how to communicate with each other, and follow an open-source community development model."

Eventually Noels realised that it would be better if the company gave customers a head start with Java. "Given our technical participation in Apache Cocoon, we were not only able to provide training, but also a framework to start working with. Java's very low-level, and you have to provide some sort of framework above it or several frameworks before it becomes comprehensible for someone who's just learning it. Our work with Cocoon meant we had something tangible to give to them immediately."

Since the software that Outerthought supplies to its customers is open source, there's nothing to stop them downloading, installing and using it without having to employ the company's services. We asked Noels what the advantage of working with a company like his was, and whether he wouldn't make more money selling software licences. Unsurprisingly, he disagreed. "There's a firm belief on our part that commercial software licensing judges the quality of closed-source software as higher than open-source software just because there's money involved. If you ask people for a certain fee to use your software, they expect the quality to be better. The problem with that is the people working on the code might be exactly the same."

He added that the value isn't in the code itself, but making it do what you want it to: "Customers are much more interested in tapping into the intellectual property that sits behind a particular implementation. If you know your code well, you're able to provide second-, third-, fourth-level support for it. It's easier to say 'this is possible' or 'this is not possible' in an open-source context than if you're a consultant working with, say Oracle, where you don't have access to the source code. Actually, it's not so much about having access to the Oracle source code as having been there when the product was designed. You know when a customer asks a question whether it's going outside of what the software was designed to do."