Aspects of Developing With, and Using, Open Source Software
Over the years I've talked to a number of developers who were in the process of moving a project into open source. They were worried about how things get fixed when they are broken. Do you allocate bugs for fixing? Do people spontaneously go to work on them? Do you link them to something interesting as a bribe to get them done? These are important issues, and they have to be dealt with. Unfortunately, there is a tendency in the open source movement to shrug off these concerns and announce that everything will be all right on the night. So how does it work? Well, part of the problem here is that open source development is a mindset as much as a method, and the questions are being asked with a conventional development mindset, rather than an open source mindset. It's really very simple - the developers are working with you, not for you. You have to get it right - if you try to order them around they will leave - they get enough of that from pointy-haired bosses at work. There are no easy answers, you have to develop your own style of collaborative work - whatever works for you and the other developers. As with most things in IT there is no silver bullet. If, as I suggested earlier, you bring working code to the project, then you will find it easier, because you will have the respect accruing from that achievement. You will be working with your peers, and the working relationship is one of mutual respect. When you are operating in a situation of mutual respect it is much easier to resolve problems that would otherwise cause friction. One way of dealing with this matter is to keep an open list of issues, bugs, and new features wanted. Developers can use the list to decide what they are going to work on. People are fundamentally honest and rarely make commitments that they can't keep, so most things on the list will get dealt with over time. If there are things that are needed and that keep getting left on the list, then you can draw people's attention to it and ask if anyone would like to handle it. Often this will be enough to deal with the matter, but if no one feels capable of taking it, then the solution is for you to work on it yourself. Remember, because the project is now open source, it doesn't absolve you from continuing to work on it - the boring bits as well as the cool, sexy bits. Of course, there are going to be problems. Sooner or later someone will volunteer to do some work that is outside their competence. You're going to have to tell them that they are out of their depth. Not nice. Not easy. But even in open source development you have to accept responsibility. Other problems include people who volunteer to do things and then don't deliver. You have to take it off them and put it back on the list. It's hard, but if you don't do it the project will collapse, because the other developers will resent having their time wasted. The bottom line? If the developers don't feel warm and happy about the project, they will leave and find one they do enjoy working on. You are dealing with people not computers! |
If you have any questions or comments about the articles on my web site, click here to send me email. |