Monday, April 07, 2003

Bad Apples

and how commercial companies should utilize Open Source with in-house development.

Open Source software is for most a new and unknown idea whose time has finally come. Many managers who have never even heard of Linux are finding themselves attempting to integrate it into their in-house development. They hear all of the wonderful benefits of utilizing Open Source software and want to be part of that. Unfortunately too often the projects fail for what seems unknown reasons. The majority of the time the problem stems from the false idea that Free Software means no cost across the board. Projects are done on a shoestring budget and the idea of interacting with the community is forgotten. The community is a large asset at the companies disposal that should not be ignored. A successful Open Source project within a company must incorporate developers within the community into the project.

John Macintosh owned an apple tree farm. The vast majority of his apples were shipped out by the ton to a company that made apple cider. After seeing a local farm open its fields to those who wanted to hand pick their own apples with fantastic success he decided to do it also. The margin for selling hand picked apples is much better then selling apples by the ton so why not give it a shot he thought. Come the next spring he put out a sign by the road stating that anyone could hand pick apples. As the summer wore on he found a few customers stopping by, but due to the infrequency he mostly found them to be an annoyance and considered stopping the program all together. Near the end of the August he had a friend over whom also ran an apple farm. The topic turned to John's field and the his lack of customers. His friend quickly pointed out a number of problems that John had overlooked:

Customers were given little help when picking the apples. Basics such as ladders, apple grabbers, and bags or crates were not provided.

There was no one officially hired at the farm to deal with customers. John who was often busy with other things made the customers feel as though they were not his top priority (it doesn't matter if they really were or not).

Getting customers to know about his farm was nothing more then a sign down near his driveway. Because of the success of other farms he incorrectly assumed that this is all he would have to do.

Each one of these were a problem that in the end hurt John's apple farm.

Of course John Macintosh and his farm doesn't exist, but if you replace him with a manager and apples with Open Source you suddenly have an interesting situation. Most all business managers when presented with the apple story know the list of problems even before it was listed, but when talking about Open Source they go tripping all over themselves asking why didn't it work? The problem is mostly a lack of knowledge about how Open Source works. They hear about Open Source and Free Software and think that is exactly what it is, something that they can take for free and with very minimal effort get Open Source developers to help. Half of the reason for using Open Source software is to utilize the community, letting them help in improving and developing the software. Managers hear about the army of programmer just working away on code in their free time. They then incorrectly assume that this army of free programmers are just waiting for them to start their project. Managers often times think that very little to no effort will be needed to utilize the community.

Customers were given little help when picking the apples. Basics such as ladders, apple grabbers, and bags or crates were not provided.

Developers want to work on Open Source software, your Open Source software! There is no excuse for not giving them every opportunity to do that. Providing timely updates, nightly build, access to the bug tracking system, and mailinglists are all very easy things that can be provided in most cases. There are of course many more things, but those four are a very good start. If a project doesn't even have those internally then there are problems that this article can't cover. Other gestures can be Open Sourcing tools that provide little to no value to the company, but are valuable to developers. Helping developers work on your code is always a good thing.

There was no one officially hired at the farm to deal with customers. John who was often busy with other things made the customers feel as though they were not his top priority (it doesn't matter if they really were or not).

Someone needs to be assigned to work with the community on the Open Source project. Often times those who are trying to use Open Source / Free Software get in the mentality that there should be no costs at all associated with it. They think that a project can be successful without any technical help. That somehow the internal and external developers will get together and things will magicly work. A designated developer must be assigned to span the two groups. If the community feels like they are being ignored they will leave (or worse start there own competing project) and then you will have no community. The person who was assigned to work with the community must have full access to both groups to be successful.

Getting customers to know about his farm was nothing more then a sign down near his driveway. Because of the success of other farms he incorrectly assumed that this is all he would have to do.

A developer should get a little extra help then extra users. Remember that they are working on code for free. Putting up the source code on the website when intern John gets around to it, although legally correct will win no points with the community. Having a set internal policy how developers can purchase/barrow hardware or other tools is an excellent start. If developers are only thought of as just a way to push a few more units out the door they too will quickly realize this. A successful Open Source project will attract new developers while one that is being neglected will cause the opposite.

There is no reason for an Open Source project to fail in this day and age. A few simple steps can be followed to make it a success. Developers desire to code and like any relationship they don't want to feel ignored. When they take their free time to report problems they shouldn't feel as though their problems are on the bottom just because they are working in their free time and not being paid $100 an hour. Remember a bug in code is still a bug to be fixed no matter who reports it. Working with the Open Source community does not mean ignoring targets and milestones. It means taking advantage of a extraordinary resource available.