How Open Source can be a Game Changer

A few years back, I read a very interesting article (that I can’t find anymore) by John Newton, the CEO of Alfresco, explaining how Open Source changed their strategy. Of course, one of the main interests of having an Open Source version of your product is to expand your market by making it more accessible, thus creating opportunities for high-value services such as training, customization and so on. But beyond this shift in “how do we make money?”, he explained that it totally changed the nature of their salesforce. When you sell that kind of enterprise system, the best way to get potential customers to know and see your product is to invest a whole lot of money in marketing and sales. And you end up with a sales cycle of several months between the first prospection call and the actual sale… when it goes through. No wonder why license fees are so expensive for that kind of product, making it even harder to sell, increasing the length of the sales cycle, and here goes the vicious cycle.

Having at least an Open Source version of your product completely changes that because people who don’t have the checkbook but will eventually use your product can try it on their own. Maybe they’re working on personal projects, maybe even Open Source projects, and they can install and use your product for free. Then if they like it, they are more likely to go see their boss at work and recommend your product. In other words, you can replace a big chunk of your very expensive salesforce by free happy end-users and their recommendations. Hence not only does Open Source change how you make money, it makes it possible for you to save money where it’s not that necessary, and focus a lot more on your core business: building a great product.

But the way I see it, there’s another very important change with Open Source. As I said before, when your business model is based only on license fees, you focus most of your attention on your salesforce, which costs a lot of money, which makes your license fees so high that it is very likely to represent a big investment for your customers. So your salesmen end up attacking prospects at high levels of management. The problem is that the guys who have the checkbook also have very different concerns and priorities compared to the people who will eventually use your product. Let’s say you are building a software project tool suite with things like issue tracking, source control and so on. You try to sell your product to companies who do in-house software development, and the people who will eventually use your software are developers. But you don’t talk to those guys directly because they have almost no decision power, especially when it comes to spending several hundreds of thousands of euros for software tools. So you talk to their Program Manager or VP of Software Engineering or CTO of some sort. And all of a sudden, you realize that those people have concerns like keeping things under control whatever happens, minimizing risk (whatever that means), reporting, making sure that no developer does anything on their own, and so on. So of course, you will implement features to satisfy those needs because you want the big guys to be happy.

Now let’s go back to the Open Source alternative. If you hope that developers will use your software on their own project, find it cool and then go back to their boss and say “we should have that”, you’re not talking to the same people. It really makes things straight again because you’re back to consider end-users’ concerns first. Developers want tools that don’t get in their way, that allow them to save some time, not waste it, that are integrated in their development environment, and so on. My point is that an Open Source model does not only change where you make money, or how you balance your own investments. It can also change your whole product itself by changing whom you’re talking to.

Now of course, I’m opposing 2 strategies here: the traditional top-down approach that forces you to focus on upper-management priorities versus the Open Source bottom-up strategy in which end-users are the ones you have to convince. And I know that this kind of 2-way alternative is likely to create controversy because project managers will read this article and think “but we need reporting, we need control, we need power!”. Now of course you know that I don’t agree with this obsession for power and control as it is associated to the software engineering mirage. It’s like the big guys couldn’t stand the IT guys anymore, with their strange language and culture and so on. So they irrationally tried to isolate us from them with layers and layers of project management and control. But they lost a great deal of intelligence in the process and they’ve created a whole generation of frustrated developers who just execute what they have been asked to, even when decisions are made by people who don’t understand a damn thing about what software is and how powerful it can really be. And of course, big old-school software vendors have created opportunities out of this mess and we’re all forced to work with their products now. But hopefully, Open Source is already changing that, it is participating in a movement of IT empowerment, together with Agile methodologies, that will lead to more intelligent uses of technology and fill in the gap between business and IT.

Now to conclude, I’m not saying that management is totally useless. YES, we have a strange culture and a weird way to look at things. So YES, we need people to help us interface with business people and teach us how to do it ourselves. NO, the solution is certainly not to reduce our field of action to the minimum but YES, we need people who understand both the power that we have AND the big picture of what is necessary, and are able to make them coincide. And YES, this mission might require additional features in the tools we’re using, for things like reporting, prioritization and so on. But those features should never conflict with our concerns as end-users, they should never get in our way to building better software. But the good news is that there are very clever ways to do just that: have a look at Mylyn, or FogBugz. And of course, I myself am thinking about bringing my own contribution. So stay tuned…

Now I would love to try an experiment and use comments on this post as an informal survey. So if you are a software developer, what tools are you using at work for things like source control, issue tracking, documentation management, and so on? Do you like those tools and why?

From http://sebastien-arbogast.com/

My name is Sébastien Arbogast, I’m 26 and I’m an IT consultant for Axen in Brussels, Belgium. I’ve been working there since I graduated in Computer Science Engineering from the “Institut National des Sciences Appliquées” in Rennes, France. Sebastien is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website.