In the beginning was the code. That was what it was all about, getting good code together to solve specific problems and meet the needs of those who coded it. In other words the users were the coders. Or so close it was difficult to tell the difference. Open Source has moved on since then, and it comes with a shift of focus that may threaten its very existence.

Many projects start with a vision of a few, and if they scratch the itch of enough people, they gain both developer and user support to move the project from the early, stumbling steps to a releasable product. When the project is small, in terms of lines of code and number of developers and users, it is easy to accept input from everyone and build a project that is a shared vision. Given that most projects start with volunteers borrowing time from their day job, this synergy of users and developers sharing a vision is a big boost to ego and subsequently to the quality and inventiveness of the code.

Now the project moves on and becomes successful. But what does that mean? It generally means that the user count increases, and this can bring a lot of new ideas to the project, and maybe even new blood in the development team. New users are good, right? In the early days, yes. The new users tend to be technically aware and able to assess the code as well as provide insightful input to the development team.

So lets move on a few years to the present. The Open Source arena has exploded. As the average home user becomes aware of open source they start to realise the cost benefits of this wonderful system of code development. It costs nothing, but in many cases is of an equal or better quality than software that can cost thousands of dollars. This is a boon that cannot be ignored! Open source projects are gaining users by the thousands. This has to be good, right?

What does the average home user expect from their software? Generally they expect software that works, and if it doesn't they want someone to call who will fix it. Same as with their traditional software. But what does that mean to an open source project? It means that the support component starts to move inexorably from technical support (bug fixes, security updates) to user level support, like how to install the software, how to configure it, how to use it. Developers are taken from the intellectually stimulating job of designing and developing new features to the stultifying repeating of answers to frequently asked questions that is user support. It takes them from the very thing that attracted them to the project to something they are most likely escaping from in their day job. This presents a real dilemma for a lot of open source projects.

Another force that starts to come into play is the fracturing of the shared vision. With so many new users, each wanting to input their ideas, projects can quickly become swamped with feature requests, many of which are poorly thought out, or attempt to convert the project from its core direction to something that it isn't. Users naturally want the software to work for them, in the way they want to work, and don't necessarily understand the technical or design constraints of making a silk purse out of a sow's ear. Worse, users often think that their way of working is the only way the product should work, and cannot, or will not, understand that other users have different perspectives and requirements. Having to cope with the filtering, assessing and design of new features adds to the support load on developers and can quickly burn them out. After all, they are generally volunteers, and don't have to be doing this.

It is often surprising and dismaying to developers that some users become belligerent in their calls for support or for feature requests, demanding that these things be changed as if they had some innate right to impugn the integrity or intelligence of the developer. They haven't paid anything for the software, they don't have to use it, there are usually other options available, so why the invective? This can be really stressful to people who really only want to help others, and aren't getting any compensation for being abused.

Project admins are left with few options. Increasing developer counts tends to increase admin load, and the number of lines of functional code per developer decreases. Users demand new features on a regular basis, requiring more frequent releases, but with volunteers doing the work, this can mean that release schedules are works of fiction. About the only thing left seems to be to commercialise the project to ensure there is enough income to pay for the maintenance developers and support techs.

Commercialisation brings with it a number of risks. The biggest risk is that you lose your best developers. Then there is the very real risk of losing all those users that pushed you in this direction. Why? Well the options of to "monetize" as the venture capitalists call it tend to come down to selling either the product, or support, or related services. Since the free product and free support is what drew the users to your project, having to pay for it is going to drive at least a percentage of them away. Suddenly your business plan starts to look a little shaky.

Some projects are started in order to become a platform to create a business, and for those the commercialisation is the end, and the means to get there is the open source. But lots of projects start out with an itch to scratch and the commercialisation becomes a means to an end. Either way, the open source project is no longer the same, the rules have changed, and it is a very real risk that everyone is going to lose a little.