I just got off a conference call we hold semi regulary amongst the committers working on the CDT indexer. Now that we have people from four different organizations working on it, we need this level of co-ordination to ensure we don’t trample on eachother. And it is a cool example of open source development at work.

Now when you get this many interests working on a common code base, you are likely to run into times when requirements start to conflict with each other, and you end up with conflict amongst the developers. This has started to happen with us and it is giving me an opportunity to really learn the right approach to take to make sure everyone walks away happy, or even whether it is possible for that to happen.

Taking a big step back, I think the first thing you have to do if you have a requirement you’d like the open source project to satisfy is to convince others in the community that it is their problem too. Now sometimes that isn’t possible because the requirement really is particular to your customers. In that case, I think you need to convince the others that the changes you are proposing will have minimal impact on them and others who want to build on and use the project. There are times, especially with young projects, where people might bend over backwards to help you. But you certainly can’t count on it, nor should you.

At the end of the day, what it really boils down to is that you have to convince people. Influencing is a critical skill that an open source developer must have to be successful working with open source. In a corporate environment, you have it easy since you can always go complain to management. But in open source, all the committers are peers, there are no managers, so they need to work out any conflicts with eachother. And that demands great people skills.

It is pretty interesting that our little indexing group has such great influencers and the discussions can become quite heated. But we do respect eachother and will continue to hammer out these issues and try to come up with the right solution for everyone.

And if this does work out for us, it’ll make a great chapter for a book on working in open source. There may be a book out there already that I need to read, or maybe not and someone needs to write one. Because I see this happening on almost every open source project I see.