Previous    Table of Contents    Up    Next

Trying to Control Too Much

One of the surest ways to cripple an open-source project is for the original developers to refuse to give up control. At best this turns potential outside developers into a user group, and at worst it kills the project. There are many ways that the original developers can try to keep control.

A common mistake is that the internal development group believes that it does not need to change how it works. Very often the internal developers continue to use a private company mailing list to carry on discussions about project issues. Although not every email message needs to be sent to the public project mailing list, if essential design discussions are carried out in private, then one of the main benefits of open source--feedback from users and outside developers--is lost. A further problem is that when the internal developers do post to the rest of the community, they are announcing what they have decided rather than starting a community discussion. For a successful open-source project, the internal development team needs to shift its email discussions to the project's public mailing lists.

The other major way that internal developers keep control of the development process is by keeping a private code archive, often one that relies on a proprietary code versioning tool instead of CVS. Some projects do not even have a public code archive, just tar1 files with the source code for the most recent release. This sends a clear message to potential outside developers that they are second-class citizens who can look at the code but never touch it meaningfully--in fact they cannot even see the most recent changes but need to wait until the public copy is updated. A real open-source project has one public code archive that all developers use, although not everyone will have full write-access to it.

Another problem arises when developers want their design or code to be perfect before letting anyone else see it. A major shift in attitude is needed to go from a proprietary development environment where, in many cases, no one ever looks at your code, to an open-source world where everyone may see what you've done, warts and all. Whether it's a single developer or the entire internal development team, waiting too long before releasing a design or code is a mistake that hurts the overall project. It is important that everyone thinks in terms of a work in progress, developed in the open to maximize possible feedback from others. Remind folks that nothing is final; it is always subject to modification as the project's needs change.

A more general problem is common to both proprietary and open-source projects: developers and managers try to make a master plan and then carry it out. Planning is good, but, carried to the extreme of not adapting to change, it can hurt your project. For example, some open-source projects try to figure out all the appropriate mailing lists and set them up so they will be ready when the project is first announced. Unfortunately, the needs of a project that has just started up are often quite different from those of one that has been running for a while. A better approach is to start with one or two main mailing lists and to create more lists only when the number of daily messages grows too large. Engineering in general often tries to do the "right thing" in one step rather than taking a number of smaller steps in whatever direction currently seems best. A decision maker who believes strongly in master planning will probably not buy into the fundamental philosophical tenets of open source (see Philosophical Tenets of Open Source in Chapter 3).

A very bad problem occurs when the internal developers do not have respect for the outside developers. If any member of the core team thinks of the outside developers as bozos who should be ignored, then you can be sure that the community will pick up on that attitude and react negatively. You should remember that there are more smart people outside your company than inside it, and one major reason for making your project open source is to be able to engage with such people as much as possible. In an email discussion about a project where the core developers were not engaging with the community, Alan Cox, one of the primary Linux kernel developers, put it like this: "Give feedback and you get more than repaid. Ignore people and you lose them forever."2

This problem can often be seen when core developers refuse to engage with outside developers in design discussions on the project's mailing lists--often the core developers don't even read the public mailing lists. Refusing to listen to community concerns hurts the project because it both kills a sense of community and results in developing the wrong product. Keep in mind that approximately half of all software projects fail, not for technical reasons but because they produce a result that does not match the needs of the target audience. Feedback from the community in an open-source project increases the probability that what is produced is what is wanted. Make sure you listen to what your community members say; they are probably right.

If your community encounters difficulties in working with your developers because of any of these problems, then you should not expect much in the way of outside contributions. Any external developers interested in your project will probably work well outside the core area that your internal developers have laid claim to. Contributions of new plug-ins or new modules are possibilities; major improvements to existing modules are not.

Even if you have been doing everything correctly, the community will mostly leave improvements to the core to you until there are visible or a significant number of outside developers working on core modules. That's why it is very important to publicize any outside developer activities or contributions to the core area, to break down the view that your company handles everything related to it. This will take time, so be sure that the metrics you use to measure the success of your project reflect this.

This is not a problem just for company-sponsored projects; traditional open-source projects also encounter it. For example, in April 2003 a fork of the XFree86 project was started because of the feeling that the core team was controlling development too tightly and not listening to the rest of the community. Problems identified by the community included limited development resources (fewer contributors than for much smaller open-source projects), slow release schedules, lack of cooperation with other projects such as KDE and GNOME, and an opaque development process (core team using a private mailing list and no information available on the XFree86 home page on how to become an XFree86 developer). Part of the problem came from the way the project was initially structured in order to satisfy requirements of a contract with X.org. The rest came from not changing the decision-making process as the project grew. More details can be found in an online interview with a former XFree86 core team member.3

The day-to-day operation of a project offers many opportunities to make mistakes by people trying to retain control. Creating a real community requires that the community participate in making decisions. There is no real community when the only developers who can check in code to the CVS archive work for your company, where every important module is owned by a developer employed by your company, or where the governance board consists solely of your company's employees. So grant outside developers the right to check in code as soon as possible, put an outside developer in charge of a module as soon as possible, and have outside developers on your governance board.

You can alienate outside developers if your company's employees are automatically given check-in privileges while outside developers have to earn them by making good contributions. This is a common mistake for open-source projects with a core team from a single company. It is important that all developers be treated according to the same standards regardless of which company they work for. Sometimes new developers at your company may have made contributions that the outside community doesn't see because they have handed over their code to the module owner in private, so be sure to make the activity of new folks visible to all.

Another mistake some open-source projects make is for the module owners to be too slow to accept outside contributions and check them in to the official code archive--or even worse, to refuse to accept them. This might be because the module owner is too busy to deal with any contributions from the community. It might also be because the module owner is being too controlling over what goes into the module. Part of the module owner's job is to maintain the quality of the code, but another, equally important job is to be responsive to the directions set by the community.

If another company is contributing so much code that the module owner becomes a bottleneck, then it is important that one or more of the outside contributors be granted the right to also check in code. The alternatives might be that few will make additional contributions or, more likely, that the outside developers will fork the project, as happened when the XEmacs developers started a second open-source project to develop Emacs faster and in a different direction than the original Emacs effort.

In summary, one of the worst things you can do to your open-source project is to try to control it too much. Although other mistakes you could make will slow down or limit your project, your keeping too much control will minimize outside contributions and make it likely that someone will fork the project. Rather than trying to control everything, you should provide positive leadership. If you set goals that the community agrees on, then everyone will be working together to advance the project. If you don't engage the community, you will lose it because everyone will stop trying to work with you and go elsewhere. One final point is that not all engineers and managers are cut out for open source: If they refuse to give up control, then they may do more harm than good for your project.

Many of these problems stem from not thoroughly buying into the philosophy and practices of open source. If the development team and management will not buy into loosening control and valuing active community participation, you should abandon pushing for using an open-source methodology in your company.