Building a Community

Who's in Charge?

If people feel that they are involved in the decision-making process and that their viewpoints are heard and respected, then the community will generally accept whatever decision is made. If people feel that a decision is being rammed down their throats, then they will object and, in the worst case, go elsewhere, possibly forking the source code and starting a competing project.

The exact decision-making process varies from one open-source project to the next, but in many it is based on the idea of a meritocracy: Those who have demonstrated their competency through their work on the project are the ones who make the decisions. In many cases, the project lead, often the originator of the code, has the final say. Likewise, module owners make decisions that affect their module. This works only as long as the "benevolent dictator" can maintain the respect of the developer community; otherwise, the community will call for a replacement.

Note that even in a meritocracy there will be lots of politics at play. First, there is the question of who judges whether someone has merit or not. There is no objective test that prospective contributors must pass. Instead, they must somehow prove themselves to the current core group. If their approach to the project is sufficiently different from the core group's then they may never be judged worthy. Second, having a good idea is not enough; it must be presented to the community in a clear manner that meshes with the current vision for the project. Even though a single module owner may make the final decision about whether to incorporate a new feature, being able to muster community support in favor of the feature can strongly influence the outcome. In both cases, there is a tension between the group's ability to maintain a narrow enough focus so as to be able to move forward and being open to innovation.

It should also be noted that a meritocracy based on the ability to write code has the direct effect of disenfranchising users--including users who are qualified developers, but who do not have the time or interest to contribute code to the project. Giving a say only to those who have contributed their time and effort has a certain appeal, especially if you are one of those people, but it has a negative result if the interests of those contributors are different from those of pure users. For example, a programmer's needs for a text editor are quite different from those of a person writing technical articles. So an open-source project developing a new text editor could easily put all its energy into adding features that make it easier to write computer programs rather than into features such as for the needs of footnotes or bibliographies. That's fine if the vision of the project is to create an editor for programmers, but if the original intent is to provide an open-source replacement for proprietary programs such as Microsoft Word then the project will be a failure. Success requires that all the users have a direct say in setting the priorities for the project. Letting everyone vote on which bugs are most important to fix is a small example of this. In any case, developers get the final vote by deciding what they will volunteer their time to work on.

For an open-source project where the majority, if not all, of the senior developers work for a single large company, this decision-making process can run into problems. Many open-source developers are suspicious of the motives of large companies, and they will suspect the senior developers of caring more about their company's needs than about the good of the open-source project. This makes decision making a problem until the outside developers get to know the senior developers as individuals and have reason to trust them. Even then, people will perceive the situation as potentially unfair.

To counter this, a more democratic process may be required. In some open-source projects, the senior developers vote on major decisions. For the Apache Software Foundation's projects, three positive votes and no negative votes are necessary for any decision. Moreover people voting no must give an explanation of why they are vetoing the proposal. A vote is also required to add a new member to the group of voting developers. The Apache HTTP Server Project guidelines and voting rules can be found on the Apache website.1

Another solution is to establish a neutral governing board that has final say and to which anyone can appeal a decision. The Jini, JXTA, and NetBeans projects have done this, establishing boards where Sun has only one-third of the total votes and the rest of the board consists of well-respected community members elected by the community. This has gone a long way toward gaining the trust of outside developers by showing that Sun cares about the success of the open-source project and is not trying to pull a fast one.

When choosing your company's representatives to such governing boards, you need to consider each board's purpose. For the Jini project, the board is primarily intended to provide technical oversight and so the initial Sun-appointed representatives included two of the core Jini architects. For the NetBeans project, the board is more of an appeals court and so the Sun representative has been someone knowledgeable about open source, but not directly involved with NetBeans day to day. Such a representative will be more likely to be unbiased if any major controversy happens; it also ensures that the Sun core NetBeans developers can freely advocate their positions without having to stay neutral. If your company is involved with other open-source projects, then the company employees working on those projects might be excellent potential board members for your project.

The Jini project has gone even further toward democracy by putting major decisions to a vote of the entire community. As mentioned earlier, Jini technology is a simple distributed computing model based on the Java programming language. Among other things, it was intended as a model for services--small bits of functionality--to discover each other dynamically and create a network of interoperating program parts. These services could be housed within devices--physically separate computing platforms as far as Jini is concerned. Because such a model is new, the definition of each service is likely to require a maturation period in which an initially immature service is defined and released, with perhaps numerous improvements subsequently being released. Service definitions are specified by Java interfaces (API).

A problem facing the Jini community was how to maintain the consistency and quality of Jini services, where all services must conform to the core Jini specifications (it's like TCP/IP) but where newly developed services need room to experiment and innovate. The community has developed a process that is fair, lightweight, and adaptable. It is lightweight because most people don't need to use it--they just write up specifications for their new Jini services and try to get people to use them. Only when they want something ratified or when they want to make a change to the core Jini services do they need to have the larger community vote.

To be fair means giving individuals and small companies a say equal to that of large companies. It also means recognizing that a large company may have many thousands of customers using its Jini-based products, and so it deserves a greater say than a lone individual. To balance these conflicting needs, members are divided into a general house and a commercial house. Both houses must approve any proposed standard. Acting as a sort of appeals court to oversee the process and further ensure fairness is a nine-member Technical Oversight Committee (TOC). The initial draft for this Jini Community Decision Process (JDP) is described in the Jini constitution.2 The current, more detailed version 1.0 of the JDP was completed in December 2002.3

One final point is that none of the open-source licenses tries to describe how the community should be run--if a project forks, one branch could vote on everything, whereas the other could appoint an individual to make all the major decisions. If people do not like the governance structure you choose for your project, they may decide to set up a separate community with a decision-making process that they find more acceptable.

Likewise, the community has no direct say in changing the license--only the copyright owner of the code can do that. However community discussions on the project's mailing list in favor of changes to the licensing can be effective. The Mozilla project is an example; community feedback helped to shape the initial license and has also prompted the adoption of a dual-license structure. To give the community direct say, the copyright could be assigned to a foundation responsible to the community with the foundation's governing board elected by the members of the community. Then the community would have ultimate control over making changes to the license.

Building Trust

If you are just a private individual starting up a new open-source project, then you might be able to simply announce your project and then sit back and wait for contributions to start rolling in. For a company, however, especially a large company, there's a suspicion that must be overcome before outside developers will feel comfortable contributing to the project. Basically, you have to earn their trust and prove that you do not have hidden motives. Further, there is a big difference between creating a successful users group and growing a successful open-source community.

If potential developers suspect that you will make money by selling the code that they contribute, then they are apt to be offended, and rightly so. And if they think that they might need to pay you in order to use a product that incorporates their contributions, then don't expect to receive many contributions.

You must clearly communicate what your business model is and that any money you make is for value that you are adding, such as higher-quality or additional proprietary features. If you really are profiting from the outside contributions made to the project, then even if you can explain how they also will benefit, it will be an uphill battle to recruit outside developers.

If developers must pay licensing or royalty fees, they will be less likely to contribute back to the project. If the license itself is too restrictive or seems to favor your company too much, outside participation will suffer. If publicity seems to slight contributions from external developers, then those developers will create negative press and leave.

The more you actually live a true open-source lifestyle, the easier it will be to earn the trust of your outside developers. Any incidents where your developers, or other people in your company, put a business-as-usual spin on things will make it harder for the project to succeed.

For example, Sun's reputation with the open-source community increased with the release of NetBeans under the Sun Public License and even more with the release of StarOffice under the LGPL and the support of Sun for the GNOME project. These overcame some of the bad feelings many developers had toward Sun because of the way Sun has retained control of Java. However, if any future problems arise between Sun and outside developers in the NetBeans or OpenOffice projects, the old suspicions may immediately resurface and need to be addressed.

It is vital that your company's developers participate in the project's mailing lists. This is how the community will come to know who they are and what sort of person each is. Remember that trust is built up between individuals. How your company's developers interact with community members will set the tone for the entire community. Because initially all of the module owners will be internal developers, how they accept and reject outside contributions will either create an atmosphere of real community or convince outsiders that it is an effort only by (or for the benefit of) your company.

You should have qualified outside developers receive check-in privileges as soon as possible. So keep an eye out for any outside developers who are contributing reasonable code; after they have made a few contributions, consider granting them CVS commit access. The sooner some module owners are outside developers, the better, so welcome anyone contributing what could be a new module. These are signals to everyone that it is a true open-source project. For example, a defining moment for the Tomcat project was the 3.1 Release, for which the release manager was from IBM and not from Sun. That let everyone know that Tomcat was no longer a Sun-only project.

Because many open-source developers are suspicious of large companies, it is important to recognize that it takes time to earn their trust and overcome any past mistakes.

Building trust also applies to people in other parts of your own company. When other groups in your company work with you through the open-source process, they will understand that your project is not business as usual and you will probably have a much easier time working with them. You should encourage developers outside your work group to contribute and when they do, consider granting them CVS commit access where appropriate. Note that the process of deciding who qualifies for CVS access should be the same regardless of whether a developer works for your company or outside of it.

Growing a Community of Users and Developers

You have a basic choice of sitting back and letting potential users and developers find you or going out and actively trying to recruit new participants. In either case, once people start to contribute to your project, you need to actively encourage them.

If you decide to go out and look for folks, then you need to know what types of people you are looking for. Who is your target audience? Or rather target audiences, because you need to grow both the number of active developers and the number of people using the resulting software.

To attract users, you need something that they can use. If all you have produced are some major pieces that will go into an actual product, then there may not be anything to use yet. This was a major problem with the Mozilla project when it first started. Without a working Mozilla browser, there were no users, and it was much harder to attract developers.

Once you have a working product, you increase your users just as with any other product: You make it better--easier to use with more features, better performance, fewer bugs, and better documentation. And you market it. Because the source code is publicly available, there should be a free version that users can easily download and install.

When you think in terms of starting with a small or minimal working useful piece of software, you encourage users and other developers to refine the requirements and specifications for it. In this way, open source can be very like the agile methodologies that produce many small releases guided by customer or user feedback.

A good user mailing list or newsgroup will also help grow the number of satisfied users, who will then help future novices. It is extremely important early on to help set a good tone on the mailing list. By encouraging group participation, you help to grow a real community. Out of this user community will come your future contributors, documentation writers, evangelists, and customers.

When the project is just starting, having a single communal mailing list is best. Resist the temptation to overdesign by creating many lists before any community has developed. As the volume grows on the mailing list, the community itself will decide when it is time to create additional lists.

In a traditional open-source project, people start out as users and become more involved because they value the product and wish to improve it. Again, your developers need to encourage people to participate in the design of new features and also in their implementation. For minor contributions, this can sometimes be frustrating to experienced developers who know that they could do it faster and better by themselves, but a few kind words now and then encouraging newcomers can really help.

Another source of contributors is other companies. If a company benefits from using an open-source product, then it may be willing to devote resources to that project. Actively seeking other companies to partner with may be a good strategy for growing the pool of contributors. Note that when a company gets involved, it may add many new developers who are focused on one or two modules. It is important that the module owner not be overwhelmed by their participation on the mailing lists and can promptly incorporate their contributed code and bug fixes. It isn't good if they have to wait weeks for their changes to get into the official CVS code archive. As soon as possible, some of their more experienced developers should be granted check-in privileges.

When working with teams from other companies, do not assume that things are going well just because no one is complaining. They might be unhappy but not know who to complain to or be unsure of what to expect because they are not familiar with open source. It is important that your community manager or some senior developer informally contact them to ask how they are doing and if they are encountering any problems.

One other source of developers is universities. Providing assistance--hardware, software, or funding--to a university research program can enlist the aid of large groups of students. For example, to promote use of the Eclipse open platform for tool integration, IBM announced the Eclipse Innovation Grant competition in November 2002 through which it would grant a total of $500,000 in awards to university faculty members and researchers to use the Eclipse open-source code base for teaching or research, or to actively promote the growth of Eclipse user communities. IBM also has an active Eclipse Fellowship Program to fund university-based research in the areas of programming languages, tools, and environments.

Many of these suggestions require your core developers to interact with and mentor people outside of your company. This can be done only by personal contact. By including community work in your open-source developers' performance review criteria, you encourage your developers to work with and mentor people in the larger community and thereby make the project more successful. If they receive the message it's important to work with outside developers, but they are evaluated only on how much code they've written, then it is likely that they will minimize their community participation. Without strong outside leadership to pick up the slack, the community will then stagnate and the project may become an effort done mostly by your company alone.

Give Folks a Good Initial Experience

It is often difficult for a user to download and install a new piece of software. This can be due to a variety of reasons such as poorly written directions, the number of steps required for a successful install, or the difficulty of correctly configuring the software to the specific computer system. If your project is really compelling to potential users, then they will be highly motivated and willing to overcome whatever obstacles are in their way. For example, the first spreadsheet programs on the early personal computers created an urgency in many people, who needed the functionality of a spreadsheet so much that they were willing to ignore how difficult it was to use them. Of course, if your project is that exciting, then it may be that your business model should be based on commercial sales and not open source.

It is really important to make sure that people have a good initial experience when they locate, download, and try out your project's product. Making sure that the initial "out of the box" experience is a good one can be the difference between a successful project and one with no users. Make sure that it is easy for users to locate the correct version of the product to download. There should be a link on the project's home page that will take them directly to the correct download page. It should be crystal clear which download is the most recent stable release and which is the cutting-edge, buggy release that newcomers may not want. If there are known to be major problems with a release, then you should have a list of all of the major bugs or missing features posted somewhere that users can easily find--in fact, they should see the list before they try to download, so they can decide if the release is even worth their time to try out.

For most projects, however, the first obstacle people encounter may be enough to stop them from going any further. If they never hear about your project or can't find the project's website, then the project has essentially failed. If it's not clear how to download and install the software, folks will give up and look elsewhere. If they can't figure out how to use the program to do at least something simple or if it crashes on them right away, not only are they apt to drop it then and there, but they'll also let other people know what a loser the program is.

Any product installation process should be simple and straightforward. There should be a clearly written tutorial to get people started using the program. After they have had a taste of success with it, they will be more willing to put up with and overcome problems.

Trying to guarantee your users a good initial experience certainly makes sense as a goal for companies making commercial products, but why should an early version of an open-source project be so polished? It's certainly true that lots of open-source advocates are sophisticated computer users and expect early releases from open-source projects to be a bit rough. However, they only have so much time to devote to trying yours, and overcoming each obstacle eats into the time and energy they have available. Too many obstacles and they will give up and do something else. Remember, they don't need your program--they already make do without it and initially are just curious about it.

In some ways, this is a good situation, because it forces you early on to think about how people will actually install and use your program, instead of your waiting until the end of the development cycle to tackle it, if then. Dealing up front with user concerns always makes for a better final product.

Creating a good initial experience also goes for outside developers joining your project. What sort of reception do they get when they make their first bug reports, contribute their first bug fixes, or initially post to the mailing list? Are they welcomed or flamed? Does a more senior developer mentor them or reject their efforts? Even if their contributions are ultimately rejected, it is crucial that they feel that their efforts were appreciated and that they, as people, were not rejected.

An example of how to encourage outside contributors happened early on in the Jini project. One of the first code submissions had major problems. Rather than rejecting it, Ken Arnold (the module owner) basically rewrote it. Ken then talked privately with the original author about the need for the revisions and then announced to the world that the author had made this great contribution to the project--without mentioning that it had been rewritten. This broke the ice, and more outside developers started to contribute.

Other obstacles that developers face include how difficult it is to understand and work with the source code: Is it modular? Is there readable system-level documentation of the program's architecture and data structures? Is the build process straightforward or long and complex? Do they need special tools to compile or work on the code? These are all potential problems that can make developers decide not to devote their free time to working on your project.

Obstacles can hinder your project in other, more subtle ways. During the first few years of the Jini project, lots of energy was taken up addressing problems all newcomers seemed to face when they first tried to run an example Jini service. The problems stemmed from the underlying complexities of how the operating system handled multicasting (or not, in the case of Windows 2000), the network configuration, having the correct security policies set in the Java virtual machine, and other such issues that are outside of Jini's control but that are needed for Jini to function. Until the Jini project included tools to automatically detect these problems and then help users track down solutions to them, the beginner was faced with a major effort before achieving any success with the Jini technology. Some novices make use of the Jini FAQ and mailing list archives to solve their problems, whereas many more post their plight to the main mailing list. Going into its fifth year, the community continues to be incredibly supportive of new user problems, but it does take up the time of more senior members of the Jini community.

A Community Website

People's first, and possibly only, exposure to your project is apt to be through your project's website. People working on your project will use the website as a place to meet, to post their work, and to find out about the current status of the project. The information presented on your website and how it is organized can help your project to be more successful. A good website helps create a sense of community.

At a minimum your website needs to have pages that do the following:

• Describe your project and its goals.
• Provide access for downloading the most recent releases, the latest experimental builds, and the current source code.
• Explain how to get involved.
• List recent news items concerning the project.
• Tell how to sign up for the project mailing lists and how to search the archive of previous messages.
• List the key developers working on the project and how to contact them.

Larger projects will also have web pages for:

• Tutorials and examples of how to use your product.
• User documentation.
• Developer documentation, including an up-to-date project road map.
• Accessing the files in the CVS archive.
• Reporting, searching, and editing bugs in the bug database.
• A list of FAQs about the project.
• Descriptions of each module.
• Pointers to web pages for commercial products associated with the project.

Many of these items will be created by your community members either directly (for example, someone writing an FAQ) or through community activities (for example, an online discussion of what milestones are in the project's road map). Other pages report on what community members are doing. Some projects allow participating developers to create additional web pages, possibly giving them personal directories to store files in where they can upload their own web pages or exchange files with other developers.

As you can see, the pages on the website must cover a large and diverse range of material. This material needs to be organized to meet the different needs of the various parts of the community. So there may be one section of the website dedicated to users and another more focused on developers' needs. The project's home page needs to clearly direct visitors to the web pages appropriate for their interests.

Moreover, the look and feel of the site will probably change as you move from the very public home page to more specialized, remote parts of the website. In a home, there is an intimacy gradient from the public parts of the house to the more private regions visited only by family and close friends. Similarly, a website's outer face should usually be more polished and standardized, while, further in, individual developers may use a variety of designs for the web pages that describe their subprojects.

As the project grows and changes, so too must the website. The community itself should be a major source of suggestions on how the website can be improved. Make sure it is easy for community members to suggest changes to the site and participate in its continual redesign. Some of this is easy to do by just posting on the web pages an email address for suggested changes. That is good mainly for minor corrections or adding pointers to web pages on other websites. For more substantial changes, it is usually better to have a website subproject that volunteers can join.

There is also a constant need to keep the website fresh. New content in the form of articles, status updates, news stories, and usage tips must be added regularly. Many people do not subscribe to the project mailing lists but rely on the project website to keep them up-to-date on things. This point came out quite dramatically when the OpenOffice project conducted a survey, advertised on all of the major OpenOffice community mailing lists and also on the website. When the results were analyzed it became clear that over half the people who responded did not read any of the mailing lists but instead relied solely on the website for news about OpenOffice.

The website is like a newspaper and, if the same old articles are there week after week, people stop visiting. One important project role is that of website editor. Just as a newspaper needs an editor, so does your website. The editor needs to solicit articles from developers, gather news related to the project, highlight work being done, profile key developers, and generally make sure that there is a good reason for anyone interested in your project to regularly visit your website.

A large project, such as OpenOffice, NetBeans, and Jini, will need its own independent website; it will also have the budget to pay for one. Smaller projects can join an existing website that hosts open-source projects, such as SourceForge,4 Java.net,5 or the Free Software Foundation's Savannah.6 If a company has many small projects, it may make sense to gather them together on the same website. For example, Sun has a website for smaller Sun open-source projects called SunSource.net7 and IBM has a similar site.8 Appendix A contains URLs for other companies' websites.

Meetings

Mailing lists, websites, and other flavors of online communications are good, but to have a real community it is important for community members to actually meet each other in person. Being able to put a face with a name and to really interact with people--hearing their voices, seeing their facial expressions--is what is needed to create a true sense of community. Meeting in person also helps you to see people as individuals and to break down the barriers between companies.

Community meetings help the project to develop its own culture, which reinforces the community by helping to define a group identity and building stronger bonds between members. Each community will have its own flavor based on its shared values, its philosophy, the personalities of major members, and other unique properties. Attending a community meeting gives members a shared experience. It helps to create a larger context by exposing people to aspects of the project that they would otherwise not have seen.

Meetings are excellent places to do the following:

• Discuss and vote on major issues--sometimes it is much easier and quicker to reach consensus when meeting in person.
• Have individuals or subgroups present their work to the larger community.
• Conduct demonstrations of new products or subprojects.
• Connect developers and users.
• Start up a new subproject--people can more easily share their enthusiasm in person than through email.
• Acknowledge people who have contributed to the project.
• Perform informal market research and test out new ideas.
• Generate excitement for the project.
• Create a greater sense of community.

So it is very important that your project schedule regular community meetings. These can be full events in themselves or just a part of some larger event--the NetBeans community has scheduled meetings as part of the JavaOne conference and also at the O'Reilly Open Source Convention. Meetings can involve the entire community or just members of a subproject. If your project has working groups, committees, or a governing board that can be scheduled as part of a larger projectwide meeting, that will make it easier for individuals to justify traveling to participate in them.

Consider using formats other than the typical presentation and panel sessions. One idea is to have a fishbowl discussion . For a fishbowl, place five chairs in a circle in the middle of the room with the audience arranged around them. The session starts with four of the chairs occupied--usually with key project members--and one empty. The rule is that conversation can continue as long as at least one of the chairs is unoccupied--as soon as all five are occupied, the conversation must halt until someone gets up and leaves. The people initially in the four chairs start a discussion on some matter of importance to the community. Only the people sitting in the central chairs may speak. Someone in the audience who wants to say something must come up and sit in the empty chair, at which point one of the other people in the circle must leave (usually someone who has already spoken). The resulting discussion often has a more thoughtful tone than in other formats, partly because each person gets only a few chances to speak and so wants to make the most of each opportunity, and partly because the discussion is not dominated by back-and-forth discussions among a few people. At the Jini Community meetings, it has become something of a tradition to end the meeting with a fishbowl discussion about issues facing the community and the future of Jini technology.

Make sure to leave time for informal activities so people can meet up with folks with similar interests. Avoid the urge to schedule every minute. Encourage people to hang out together by having a reception with good food and drink. Have a group outing to some local landmark. Eat meals together. Make sure that your meeting space has places for people to sit together and talk. Sometimes the most valuable discussions happen outside the official sessions.

Corporate Source Issues

Engaging a community can be more difficult in a corporate-source project than in an open-source project. This has to do with the nature of identity in the two arenas. People working for a company sometimes have a special corporate identity. By this we mean that employees adjust their behavior and attitudes to align themselves better with the corporate culture. For example, an employee might display more loyalty to the company while in the workplace than may be natural for that employee at home or at a ball game. But a commons-based project requires candor and a critical eye from participants in order to realize the benefits of the slowly dawning insights that commons-based approaches encourage. In an open-source setting, identity is a pseudonym because it may not be easy to find out someone's true identity behind the email address or people may not be inclined to look hard for that real identity. But in a company, it's easy to find out who is behind each email address and one's candid comments might figure into performance reviews and other employment decisions. This fear of exhibiting beliefs and behavior that would be good for a corporate source project but which might be considered contrary to the rah-rah culture of the company might inhibit employees and limit the effectiveness of the project.

Moreover, some developers are afraid of exposing their weaknesses--such as poor language skills--to an audience that could include managers who can fire them or withhold projects, raises, and promotions. When the context is a judgmental company project, some potential contributors might fear to expose a weakness that is otherwise not apparent. In an open-source project, in contrast, language skills do help a contributor, but there is generally tolerance for people who are not speaking their native language or who happen to be less skilled at writing than others in the project. Although the day-to-day dealings in open-source and corporate projects can be equally difficult and judgmental, corporate projects additionally brim with employment-related dangers. Whereas open-source projects thrive on candor, bottom-up action, and merit-based advancement, corporations may encourage strict team play, command-and-control, and hierarchy.

Sometimes experts are hesitant to expose their expertise because that might jeopardize their competitive advantage in the company. This hesitancy could boil down to a desire to get credit for contributions--in some cases people are more comfortable with disclosing information when there are audit trails that reveal who is accessing their disclosed information.

Project leaders and other managers advance by taking responsibility for a tough project and then delivering. But to some this can appear hard to do when control is relinquished to others, which is what happens when other people in the company, who do not report to the project leader or manager, are granted the right to check in or have write access to source code. And so project leaders and managers may not accept a corporate source project or may do so only reluctantly and therefore try to limit broad participation, at least unconsciously.

These are all impediments to building a strong community for a corporate source project. For corporate source to be truly effective, there needs to be a corporate culture that respects and celebrates speaking honestly.

Three Principles for Community Building

We end this section with three basic community design principles from Amy Jo Kim's book Community Building on the Web (pp. xv-xvi). We highly recommend this book, which describes the strategies needed to create a thriving online community.

First, design for growth and change. Don't overdesign your project up front. Start off small and focused. Grow in response to the needs of your community members. This echoes the development philosophy of open source: Start with a small but useful working version of the software and permit the community to continuously (re)design it. The poet, William Stafford, in speaking of writing, has provided a good definition of art:

[Art] is a reckless encounter with whatever comes along.

Building a community is an art.

Second, create and maintain feedback loops. You need to listen to your community in order to meet its needs. No one likes to be just a cog in someone else's machine. Doing this is harder than it sounds. Try to find someone to direct the evolution of the community part of your open-source project who is not heavily invested in the technology under development. Such an outsider is likely to care about the community more than the technology and therefore will be able to listen better.

Third, empower your community members over time. As your project "grows and matures, your members can and should play a progressively larger role in building and maintaining" the project. A common failure of the meritocracy is that the old guard hang on too long. Some elders develop a fear that only they know the true path for the software and that permitting someone else--anyone else--to have a definitive say will blow it. You should encourage your leaders to move on earlier rather than later. The following quotation is from an interview with a short-term participant in open source:

There's another [open-source] project whose technology I use and I want to develop further, but the "benevolent dictator" is simply a dictator ... the few developers who stick around are like that too ... who needs that?"9

Taken together, these three principles will help you to nurture and guide the excitement and energy of your users and developers to grow a successful project with an engaged community. The results will be much more than you could have done by yourself.