Making an open source living, part 2

newsmaker In part one of our interview, we spoke to Steven Noels about how the company he works for, Outerthought, makes money out of open source software, as well as using open source software written by others within its business. Outerthought has also released some of its own code as open source. Much of this code was originally written to meet a customer's needs. We wanted to find out whether they had found the experience positive. In particular, we wondered whether they'd had any contributions to their projects from the community.

"It has happened, but not at a particularly high rate. It's a give and take situation. If we had been able to put more effort into quickly building a community around the project I'm sure this would have happened sooner. For xReporter, our Web-based reporting tool, around one year after release, users started to appear, and we were being asked questions on our mailing lists. It's now two years after release, and we're not answering all of the questions ourselves any more. We have users helping each other, so that's one thing. We don't have to provide support any more, at least not first-level support. We see users helping each other, and that's nice."

Noels points out that they have reached the stage where there are outside contributors to the project: "We've voted in two outside developers, just a month ago. They started using it, they seemed like smart guys, they fitted well with our ideas, and they felt at home in the project. We said we're going to give you guys commit access, so you don't have to provide us with patches, you can just have your own way with the code base. That' something which took us two years. You get what you put into it--we're not always able to put as much energy into the project as we want, but if you're patient enough you eventually succeed."

Outerthought has also found that releasing some software as open source can prove to be an effective advert for the company's services. "The other perspective is that the project is there, people can use it, they don't have to pay a license fee, and they can start playing around with it. Eventually they may have problems and requirements that are not solved by the project", says Noels.

Outerthought has won business on exactly this principle: "We have that situation with a US company. The initial development was funded by a Belgian company, one of our largest customers. A US company wanted to use the same framework for one of their customers, but they wanted some stuff that the software lacked. They contacted us and asked if we could add it to the project. This meant that although the first customer had to pay for the project, he got additional features for free, because we built those for the next customer and we asked them if we'd be able to release the changes and additions as open source as well".

"We gave a total estimate of one man-year of work for the initial release, and we've already added half a man-year of additional stuff onto it funded by other customers. The original customer just had to upgrade to get the additional features for free. So there are two sides to it: the community adding stuff to the project, and things that come out of customer requirements."

Noels says that persuading a customer to have a project they'd commissioned released as open source was easy, given the right argument. "We had a discussion with the first customer. They had a choice between paying us a certain price per day, or paying less than that but having the project released as open source. Now, the pricing difference helps. It helps the customer to persuade his bosses that it's a good idea." It wasn't all about money though, as Noels points out: "In this case, it also felt logical for them to release this stuff as open source. Why? Because if you look at the way we do database reporting, that's hardly the core business of our customers. It's a tool they need to support their business, but it's not what they actually do."

"The thing that is expensive, and which is very proprietary, is the datasets they are querying, not the reporting tool itself. It's also a matter of pricing--if you're going to buy this many licenses of Crystal Reports, it's going to cost this much, for that you can commission your own reporting system. This means it will do exactly what you want, and if it's released as open source afterwards it might, in the longer term, do even more stuff that's funded by other people."

Some people see the choice of open source license is important to a project's success, so which license does Outerthought release its code under? "Both projects are under a BSD-like license, which is based on the Apache License. This means that credit has to be given to us, so people can fork the code or use it in a commercial application, but they have to make clear that they've used some of our code to their customers."

This wasn't necessarily driven by Noels' and his colleagues' involvement in Apache, though. "This was more of a gut feeling. I see many companies going for the LGPL model, because of a fear of forking. I think trying to avoid forking of your project has more to do with how you manage your project and its community. If you manage it well and you're keen on integrating patches and additions from outside, forks are not likely to happen. Using the LGPL license seems to be based more on distrust towards other developers using your code, whereas we say in the end if they have in-depth questions, real support needs they are going to come back to us. We designed and wrote the code, and that's more important than which license we use to distribute it. If someone wants to fork our code and they have deep enough pockets there's no way we can stop them anyway".

Noels says getting involved with the Apache Software Foundation wasn't so much a deliberate action as just a progression. "It happened without much strategy. The initial interest was technological--I was looking for something which was capable of XML publishing, and I eventually was confronted with Cocoon. That was a long time ago, and I started helping, discussing, and contributing little bits of code. I really felt grateful to the people who were involved at that time that they considered me to be one of their peers. It felt good -- having invoices paid by customers feels good as well, but having some smarter guys saying "we like what you contribute, come and be one of us", that's very important".

Working on code as part of a non-profit organization brings a different, and possibly more satisfying, way of working. "Being able to reflect on things without customer pressure behind it is also very important. We can ask questions, we can have issues with customers--technological issues--that we can reflect on with code developers, without having to think about business interests".

Noels also feels there are other benefits to participating in open source development in general: "For small companies it's a way to expand your horizons in a sense. It started with one project, which was Cocoon, and from then on it grew organically. You find out that you care a lot about licensing, you care a lot about what new projects get added to the foundation, so you start discussing these issues on mailing lists, and thinking out loud. Eventually these people say "we might as well let him in rather than try to defuse his energy", so that's the logical progression from becoming a committer to a PMC member to a foundation member. It's just because you care about it--it's a people thing".

Noels even gets a certain level of personal satisfaction from his work with the ASF. "It's kind of cool to be able to speak on a first-name basis with guys like [ASF Founder] Brian Behlendorf, who get interviewed by Fortune Magazine! Knowing that you're on the same mailing list, you care about the same issues, you're able to read what he's thinking on the legal aspects and the community aspects is great. There's a great deal of experience between the members of the Apache foundation. Just being able to tap into this is personally very enriching".

Having to fund such involvement is much trickier. Noels finds that working with other developers involved in the same open source projects is a great help. "In our situation it helps that we're all involved in Cocoon. We all have commit access to Cocoon. The time I contribute to the foundation and to Cocoon is effectively funded by my colleagues, and that helps a lot, that I'm not totally independent and I have two colleagues, who make sure we can spend work time on free software".

Not that he finds its only people working for small companies like his who contribute: "If you look at Apache contributors there's a mix between people who are completely independent, people who work for large companies, and lots of small shops working on Apache projects".

Noels feels that his involvement with the ASF has been one of the main reasons his experiences with open source software have been so positive. "You spend time doing some things for free because you know in the end it could be a good long-term investment. We would never be able to reap the benefits of open source software if we had been working completely on our own. Just opening up a project and putting it on SourceForge wouldn't have worked--it was working with Apache that made it easier for us, and made it easier for us to contribute back to Apache".