Previous    Table of Contents    Up    Next

Community Issues

So far we have discussed some of the worst mistakes that can hurt the growth of your project's community. These include mistakes such as continuing to work in a proprietary style without engaging the community, trying to plan out the entire community ahead of time rather than letting it develop more organically, starting up the project website and mailing lists before you are ready to participate, and acting as if you owned the entire project.

Another set of mistakes stems from a belief that the community will arise by itself. That will never happen. For example, it is common to believe that the community doesn't need face-to-face meetings--that email communication alone will create the needed connections between people. This just isn't the case. Meeting in person allows folks to put faces with names and to see each other as people; it helps to break down the barriers between your company's employees and outside contributors. A related mistake is believing that all that is needed to have a community meeting is to announce it a few months in advance, and then it will just happen. This also doesn't work. As for any meeting, it is important to plan out what topics will be discussed and to post an agenda well in advance. It is also necessary to talk up the meeting in community discussions. People need to be motivated to want to attend, especially for the first few meetings when the community is just getting established. Creating a vibrant community can occur only if you and your team nurture it by encouraging contributors, holding community meetings, and supporting community activities.

Another problem occurs when your company's developers send harsh or acrimonious messages-- flames --to a project mailing list. Flaming rarely improves matters, and the community will consider the flame to have come from your company. Make sure you and your teammates follow good posting etiquette and avoid attacking outside developers. Even if you know that the person you want to flame is comfortable with that sort of exchange, remember that public messages are seen by all the community members, many of whom do not appreciate flames. You should think of the entire mailing list as being the audience for any emails you send--don't focus on a specific individual. Because the mailing lists are the major way people in your community communicate, it is crucial that everyone feels safe posting to them. Flaming and harsh criticism in messages discourage many people from participating.

A similar problem is that any opinions or comments posted by an employee of your company will often be taken as official company policy. You need to be sure to indicate which postings are just your personal thoughts and which are really company policy.

Not telling the rest of the community what you are planning is another all too common problem. For a project that you are leading, this behavior will generally discourage community involvement; for a project that you are only a participant in, it will make it harder for you to get your contributions accepted. In both cases, you also lose out by not getting feedback early on when it can do the most good--so your eventual result will not be as good as it could have been. You may be acting with the best of intentions, but others in the community will not know that and are likely to assume otherwise. The article reproduced in Appendix D gives an example of what can happen when a company's developers do not communicate their plans to the community in advance.

Another set of problems center on how easy it is for community members to create new subprojects for modules they are working on. On Jini.org, any registered community member can create a new subproject; however, old subprojects that die are not cleaned up. As a result, it is very confusing to Jini developers who want to join an existing subproject because they are confronted with a list of over 100 subprojects, many of which are defunct. For any open-source project, someone in the community needs to be responsible for pruning inactive subprojects. On the other hand, diversity is good--it's how innovation and creativity come about. So it's good when many subprojects get started, even if many of them die out. And when a subproject is dead, it should be moved to an inactive list rather than to the dumpster in case someone later wishes to pick it up.

Evangelize active projects so potential participants know about them. Both the Jini and the JXTA project home web pages have a section spotlighting one or two community projects.

The opposite problem occurs when it is too hard for someone to start up a new project. Both NetBeans and JXTA have an approval process for creating a new project. A public discussion is required before a new project can be approved. This works to avoid duplication and to inform the rest of the community about the new project, but in a way this may prevent some types of projects from being started. People are generally conservative, and, when a project sounds like it is outside what is normal or usual, people tend to discount or discredit it. So, if you ask people what they think about a project that is innovative in some way, they may tend to disparage it. In contrast, if you simply let the project proceed, then once people try out a working version of it perhaps they will understand its value. That is, a deliberate approval process can screen out innovative projects because of a kind of fear. Many technical people, particularly software people, try to create tidy logical structures and ontologies and then place things into them. When an area is not thoroughly known, it isn't possible to make such tidy structures, but that doesn't inhibit the impulse. Some new projects won't fit into one of these imagined tidy structures and might be criticized because of it. Hence, a better approach might be to allow anyone to create a new project and then have a community coordinator monitor the project's health; should it die, the community coordinator can then move it to a list of inactive projects.

A final community-related problem concerns one-size-fits-all project infrastructure tools. Make sure that the company providing the infrastructure for your project (website, CVS tree, mailing lists, and bug database) does not treat your project as a generic open-source project. Every open-source project will naturally do things slightly differently, and, where this is significant, you don't want your project constrained by your infrastructure provider. For example, the NetBeans project had decided to use a model where any developer trusted to commit changes to one module was trusted to commit changes to every module. This model encourages community members to trust each other, and relies on social rather than technological means to enforce rules for code changes. The original open-source infrastructure provided by CollabNet, the NetBeans infrastructure provider, had supported this model. CollabNet later decided to upgrade their infrastructure, and the new design (SourceCast) assumed as universal the practice some open-source projects adopted of limiting developers' CVS access to just those modules that they have been explicitly granted access to. The NetBeans project discovered this only after the upgrade, and it caused some ruffled feathers in the community when developers' privileges disappeared without warning. CollabNet agreed to change their software to be more policy neutral. This example illustrates two things: technological concerns should not dominate design; and there is not one true way to do open source.