Making an open source living, part 1
Steven Noels is Managing Partner at Outerthought, a small Belgium-based consultancy specializing in projects built around Apache Cocoon, a Java-based application framework. He's also a member of the Apache Software Foundation and the Apache Cocoon Project Management Committee--as well as using open source software, he contributes his time as a coder and helps to run the organization.
Builder UK spoke to Steven recently about his experiences working with open source software in a commercial environment. We started by asking how Steven and Outerthought got involved in open source, and find out it wasn't based on any particular philosophy:
"Originally our interest in open source was on a purely technical level. We do a lot of work with the Apache Cocoon project which taught us a lot about open source--legal aspects, the community--which was interesting, and eventually helped us to help our customers, and to build stuff for them and release it as open source as well. But it started out as a technology interest, and only after a while--for us it took around a year--did it become something that we saw a business model in."
Noels sees this as different from a lot of the recent activity based around open source, where the decision may be taken at a management level. "What we see now is a lot of companies who do open source because of business strategy, whereas with us it was very different. We were confronted with open source because it was a cool project. We started working in the project and around the project, and it was only after a year that we saw it's possible to earn money by adding stuff to this project, and by people requiring assistance and additional help. It hasn't been a business strategy from the start--it evolved into one."
Small consultancies like Outerthought normally exist to provide bespoke software for their customers to solve a particular problem. While that's true, Noels sees their job as being more than that. "We've been doing development for a long time, so what we sell to our customers is our experience. Most of our customers have their own developers--our largest customers have development teams of 30-40 people, who are working on old technology, like Cobol, and they want to move to a new technology like Java. They could do that by taking a Java course, and moving on from there, but it's very difficult to have people change mentality to the one needed for object oriented development."
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 realized 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 licenses. 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."
Noels summed up what he felt his clients really wanted: "That's something our customers are adamant about: if they ask a question, they want serious answers. You don't sell them a license; you sell them your experience.
Noels has also found that this approach is a great way to generate repeat business. "It leads to serious stickiness in business relations. It's very challenging, because you have to be sharp--there's no safety net. You can't say 'this isn't working, but it's Microsoft's fault'. We tend to be very selective in the jobs we take on. We say 'we only work in Apache Cocoon, don't ask us about Struts.' The difference is that we haven't been participating in the design, discussions and community around Struts, so we can't provide the same level of quality as we can with Cocoon."Being able to provide the level of support that customers were asking for meant that Outerthought had to specialize in a very specific area, the Apache Cocoon framework. Noels says this wasn't an obvious move at first: "That's something we learned ourselves, the hard way. In the beginning, we said 'we do Java and XML,' then we said 'we do open source Java and XML.' If we said we did Java and XML, people came to use with questions about the Java API for Oracle, which we didn't know anything about. So we said 'no, we do open source Java,' then people said 'are you doing MySQL?', and we said no, since that's C and C++, and we don't know anything about that. So then people said 'oh, you do Struts and Cocoon and Tapestry,' and we said 'no, we only do Cocoon.' We made that decision two years ago; to really focus on Cocoon, and now 50 or 60 per cent of our turnover is based on Cocoon. But it took us some time to realize that we had to focus and be very specific about it."
It has been suggested that specializing so much may actually result in the company losing business. So, one might ask, what happens when a customer wants more than just that specialized area? "When a client comes along, he's interested in us but he might have a different technological vision. We try to convince them that he shouldn't focus on the framework he wants--let us help decide on the framework used. In the end, experience with a particular framework is much more important than having the choice of framework."
Noels goes on to say that they're happy to work with third parties who provide some skills that Outerthought isn't able to provide: "Since we're specialized we don't do everything. For Outerthought itself that means we have been involved with a few other companies which have particular expertise in related areas, or they have similar expertise but operate in a different geographical area, so we don't feel like competitors. Sometimes these companies are larger, they have some J2EE folk on staff, or people with JBoss knowledge, for instance. In that case we end up doing a normal subcontracting job. Mostly we say let us just do what we're capable of, and we're very keen on working with partners on a project."
However, Noels feels that with this approach the customer doesn't necessarily get the best deal, so will often approach things differently. "We try to skip the subcontracting stuff, because we think the customer should be the owner of the project, and he must be aware of the importance of such constructs, and the best way to make him aware of that is to put the problem in his hands, and to say OK, so you know you need two Cocoon folks, you need one JBoss guy, three general Java developers. Now you can go to an integrator and say "solve this problem for me," and that's how most integrator shops work, by providing a turnkey solution. The problem with this is that quite often, towards the end of the process, it becomes quite clear that the customer is buying a turnkey solution. He's not able to open up the hood any more and see what's happened, and with whom it's happened. You ask who has being doing this part of the project to be told: 'Oh, that was a guy we contracted for six weeks for that specific part, but now he's left.' It's quite difficult for the customer to understand who has been doing what."
Avoiding this problem is what has led to Outerthought's use of an open source style collaboration with their customers. "What we tend to do, if the customer is willing, is to discuss with them the hiring in of other partners in areas we don't specialize in, and for the customer to manage the projects in a classic project management sense, but also manage the knowledge transfer process, so that if I want one of my internal developers to understand this part of the project, I need to sit them next to that guy so he's aware of what's going on. That's also very comparable with the open source environment."
Since Noels has found the collaborative development model to be so useful, does he think open source developers are better team players? "No. They're no different. You have the same personality clashes you have in a closed corporate environment. I think the difference is that everything happens out in the open. You're just trying to show the best of what you can do, because you know lots of people are looking at you, so the aspect of peer pressure is very important."
But the pressure isn't a problem: "It's a nice, challenging peer pressure. You know that I'm going to create something, and because you know that more than just my boss and three colleagues are going to read it, it will be 40 committers to a project, and there might be 600 people lurking on the mailing list, so you don't know who's going to be reading it. You still have the ego clashes and little battles, but it's toned down a level."