Focus on Your Users and Contributors

One of the most crucial factors in your project's success is releasing a useful product--one that works and solves a real problem. This is exactly the same problem faced by any company releasing a commercial software application. Open source works best with at least several thousand users, so your product must first attract that many. Then the open-source process will encourage those users to provide feedback that will make your project more in tune with the needs of potential users. Remember that one of the main points of doing open source is continuous design, which requires that you pay attention to the continuous feedback you're getting from the community.

If you have such a large code base that you plan on releasing it in several installments in order to give you time to scrub it, then make sure that the first release can build a complete and useful product. Try to release the parts that are most valuable to users and developers first. As you release subsequent pieces, additional news stories about your project will be generated.

Target Your Potential Audience

As with any product, you need to identify what sort of person will benefit from using your product. You need to make sure your message reaches those people. This is where you can make use of standard marketing and advertising.

You also should target other companies that will benefit either from using your product directly or using it to add value to their customers. For example, any company doing Java development can use NetBeans to increase the productivity of its programmers. Other companies create commercial products that run on top of NetBeans. In both cases, companies have an incentive to assign their own developers to work on NetBeans to add features they need, and indeed a number of companies have already done so. For any open-source project, companies provide a good source of potential developers.

Make Users Successful

Installing and learning to use a piece of new software is always a major hurdle for people. As discussed in Give Folks a Good Initial Experience in Chapter 6, it is important that you make things as easy as possible. Every person who can't install your application or who is unable to get it to run will be sure to mention those problems to other potential users. You want the message sent by word of mouth to be that people should try your product, not that it should be avoided.

Good documentation, tutorials, and training will also help your users to succeed. The ideas behind open source encourage users to help each other, so provide ways for them to do so via your project's website: Create user mailing lists and discussion forums. Compile FAQs. Do everything you can to encourage the formation of an active user community. There may even be more than one, so you may need to foster several developing communities. They might be separated by what they do with the product (for example, Java vs. C programmers) or by other factors (for example, French vs. German speakers). For large projects, work with a publisher to get a book written about how to best use your software.

Most active communities have an email-based communications flavor to them. One reason that urban settings seem energized is that there are constant noise and interruptions--actual evidence of energy. A community that thrives on email is one that interrupts people with frequent email. Some community members--often the most active ones--are eager for such interruptions. A community with no such interruptions, with only a website (even with wikis and weblogs) will seem placid and low energy by comparison. When people need to go see whether something is happening, they tend to go see a little less frequently as time goes on. For energetic email-based communities, there needs to be a way for people to get respite and opt to come around to see what's happening or receive relatively infrequent email digests.

Do releases as frequently as makes sense. Small frequent releases give people a greater sense of progress than infrequent large ones.

Let your users help make your project more successful. You need to listen to their needs when designing future versions of your product. In fact, your users should be part of your project's design team.

Encourage Outside Developers

When you first open your source code to the outside world, the initial reaction of outside developers is usually very positive. You can expect comments such as "Wow! You really meant it! There's a lot here!" After a few weeks, the warts will start to show as developers realize how much work will be required to add the features they want, to improve performance, or to do whatever they care about. You need to expect this change in attitude and react appropriately: Acknowledge the problems and don't be defensive.

Make sure your developers welcome outside comments and do not respond with flames. Your team needs to encourage outside contributors. Some have lots of expertise and need to be treated as peers. Others may lack experience and need mentoring. The tone you set when you respond to the first suggestions, bug reports, bug fixes, and outside contributions will determine what role people outside your team will play in your project. It is much easier to start off right than to try to recover later.

Any developer beginning to work on your project needs help to come up to speed. New developers at your company can often just walk across the hall to ask one of the original developers. Outside developers do not have that option. You need to provide them with a systems overview, internal documentation, and email access to the original developer team.

Help Outside Efforts Meet Project Quality Standards

Every open-source project establishes a level of quality that new modules and features need to reach in order to become part of the official release. For some projects, this may mean just that the new code adds more features than bugs. However, other projects may require documentation of the new features; support for internationalization, localization, and accessibility; user-interface (UI) consistency with the project's look and feel; usability testing; adherence to coding style guidelines; or any of various other common requirements for product-quality software. For volunteers who have developed some cool new functionality and want to contribute it to your project, meeting this full list of requirements can easily involve much more work than they spent writing and debugging the code in the first place.

This creates a potential problem: You want your project releases to be of high quality, but you do not want to treat outside contributions as second-class code that doesn't make it into the official release. This situation arises in part because a company-sponsored project usually includes technical writers, graphic artists, UI specialists, and others who work with your company's engineers. One possible solution is to have these people also share their skills with outside developers.

The NetBeans project did this--graphic design for icons was available on request, the Sun UI team was available to provide advice on the user interface for a contributed module, and the Sun documentation team generally took responsibility for documenting everything in the NetBeans standard distribution. Other assistance was also available to include the new module in the automatic project build scripts.

This doesn't guarantee that all contributed code will be brought up to product quality. It is common for open-source projects to have an experimental modules section containing new code in various stages of readiness for adventurous users to play with. Those modules that the community finds promising are candidates for your team along with the rest of the community to improve further.

Make Sure Adequate Resources Are Allocated

An open-source project requires more resources than a conventional proprietary one. If you skimp on providing for the additional needs, it will slow down, or even cripple, your project. The rate-limiting factor for your project should be the enthusiasm and effort of your community, not the person maintaining the project's website who is too busy to update it or your internal developers who are so overworked they have no time to integrate outside contributions and bug fixes. Starting up an open-source project implies a commitment to engage with your community and to support it.

Moreover, feedback you receive from your community provides important information you should use to set priorities. If all your employees are fully assigned to tasks in order to meet your company's goals, then you will be unable to benefit from what you learn from your community. You need to be able to reassign developers to work on what will make your project most successful, where success is defined in large part by your users. If your schedule and plans are inflexible, you will miss one of the major benefits of open source--design help from your community. You also run the risk of alienating members of your community when they see that you do not listen to their ideas, suggestions, and requests.

Of course, you do have limited resources, so you need to identify when your lack of resources is the bottleneck and see if the community can provide the additional manpower. For example, what if one of your developers who is in charge of a module has so much work to do that it prevents a prompt reply to bug fixes or modifications submitted by outside developers? In such a case, one or more other developers need to be allowed to also check in changes to that module. This may be an outside developer who has submitted changes to the module. As soon as possible, you should grant qualified outside developers check-in privileges.

However, that same overworked module owner must make time to participate in any community discussions relating to that module. If that is not possible, then another person who can engage with the community needs to take over ownership of the module. It is okay to delegate work on the module to others, but leadership regarding the module's development requires active participation.

Good project management can make a difference. A good project manager makes sure that when the project is being hurt by a lack of adequate resources either more resources from within your company are allocated or the community is solicited to provide the additional help.

Governance May Need to Change as Your Community Grows

What works for making decisions when you first launch your project will probably change as your community develops. Initially only your developers will understand the source code and what is needed to change it; the community is mostly in the role of users commenting on how well the product meets their needs. That makes it easy for your developers to be the ones who make all the major decisions, especially because they are the ones doing the bulk of the work. As time goes by and outside contributors become more involved with the project, they will naturally want more of a say in how the project moves forward. This will include what features go into it, what bugs should be fixed first, and when and how releases are done.

At this point you have a choice: You can try to keep total control, minimizing community involvement, or you can encourage the community to take on a larger role. In the latter case, the open-source project will blossom beyond just your company, even though it will still be the largest contributor.

Governance is how things are decided and by whom. Every community and every open-source project has some sort of governance because decisions must be made all the time. Governance does not necessarily imply some sort of hierarchy, voting procedures, or strict process. People who join open-source projects expect some sort of meritocracy in which good work (merit) is rewarded with more rights and responsibilities. Most open-source projects have good meritocracies, but not all do.

In a company-sponsored open-source project, people who would otherwise be thought of as good-natured dictators might not always be seen as working toward the best interests of the project and community but might be seen as serving some corporate goals. In these cases, it's a good idea to think about alternatives to pure meritocracy for governance.

The community will typically ignore early discussions on governance--they will be happy letting you run things. Most developers and users simply want to do their work; they don't want to have to think about process and governance. But at some point, people in your community will start to demand a say and may even complain about how evil your company is to try to run everything. At that point, little you do will be seen as good and many messages posted will contain suspicions about your motives. It's like a rebellion, and you just need to expect it and ride it out.

For most company-sponsored open-source projects, some kind of exception-based governance with an appeals body is the best lightweight mechanism to put in place. Sometimes you need to put something related to governance in the contract with the web-hosting company. For example, if an appeals body needs to be able to direct the hosting company to give check-in privileges to someone, that will need to go into the contract between your company and the hosting company--otherwise, your company will retain that power.

When your community starts to request a greater say in how the project is run, it is likely that most of the email will come from just a few people. Do not think that they are just a few malcontents and that everyone else is basically happy with the status quo. If you do, you will miss your chance to involve your community more in your project--and you may not get another chance. It is better to think of the few vocal folks as early adopters, who represent the leading edge of your community's thoughts on governance. Work with them to get more community participation. If you don't engage with them, then they will almost certainly cut back their efforts; even worse, you will give the rest of your community the impression that you do not want to work with them--that they are somehow second-class citizens, that they should stay in their place and let you call the shots for the project. Changing this impression later will be difficult. It is better to not give it in the first place. Working with your community, you have a chance to make the project a true community effort.

Even after you have made it over this hurdle and your community is actively involved in making important decisions about the project, you should expect this process to continue and governance to adapt as your project continues to develop. In large part, this will be caused by your project's growing in size, both in terms of the number of people involved and the number of active subprojects. For example, as the original Apache project added more and more subprojects, it needed to create a Project Management Committee to oversee each project. Further growth led to the creation of the nonprofit Apache Software Foundation with an elected governing board. As your project grows in size, your project's organization will also need to change.

PROVIDE FOR THE DIFFERING NEEDS OF YOUR COMMUNITY MEMBERS

Everyone in your community is unique. Their reasons for participating, the length of their involvement, how much they contribute, and how much they know all vary from person to person. In her book Community Building on the Web , Amy Jo Kim describes a five-stage membership life cycle that runs from visitor to novice to regular to leader to elder. Most people will not progress through all five stages--in fact you should expect the number of visitors to be several orders of magnitude larger than all the other stages combined. To attract and retain people, you need to understand their differing needs and how to encourage people to become more involved.

Guide Your Visitors

A visitor is someone who simply wants to see what your community is about. Like a tourist, a visitor wants to easily find the interesting places and painlessly get an idea of what's up with the project.

Are visitors to your project's website able to easily find answers to their questions or do they become lost as they try to locate information? A good website has a section devoted to newcomers. This Visitors Center should contain the following:

A project mission statement and road map.
Answers to frequently asked questions.
Instructions on how to download the current release.
Tutorials and getting-started documents.
Press releases and articles about the project.
A site map and a way to search the website.
Policies and guidelines for participating in the project.

Most of the larger open-source projects make it easy for visitors to find this type of information. Two good examples are Mozilla1 and GNOME.2

You may want to have a separate area for each different category of visitors. This might be as minimal as having additional sections in your FAQs, or you might have multiple web pages with specialized documents for each group. For example the OpenOffice project3 has localized versions of much of its website for speakers of different languages (for example, Czech, French, German, and Japanese), whereas the GNOME project provides separate web pages for users and for application developers.

Another question you must address is how much visitors can participate. Can they browse mail archives, subscribe to mailing lists, post to mailing lists, add comments to discussion forums, or edit wiki pages? Generally, you want to maximize how much information visitors can see on your website and minimize barriers to entry. However, you also need to worry about possible disruptions of conversations; furthermore your community members may not want to discuss controversial topics in public.

Although many visitors will be new to your project and may need help navigating your website, others will be quite knowledgeable about your project--they may visit your project's website frequently to see what's new. Do not assume that all the people who care about your project get their news via the mailing lists; feature news about your project on the home page and update it frequently.

The definition of visitor is someone without a community identity, so any participation visitors do is done anonymously. It is not necessary to encourage your visitors to join. However, you should make clear what the benefits and requirements of membership are. The main reason people join an online community is to do something that requires membership. For an open-source project, that something is typically being able to ask questions in order to get help in using the project's code and participating in the discussion of the project's future.

Welcome Your Novices

Novices are people who have taken the step to join your project. They may have registered on your project's website or maybe just subscribed to one of your project's mailing lists. They are interested in your project, but need to learn the ropes about how your community functions. They need to learn what they can do as members and how to behave.

When they join, you need to welcome them into your community. A simple way to do this is by sending a welcoming email message. This note should be from a real person, even if it is sent automatically from the mailing list server. Have either the project's founder or your community manager write this welcoming message. It should confirm the novice's membership and explain how the community works. You shouldn't overload new members with information but rather provide links to what they are likely to need to know as they get started working on your project.

On your website, you should help novices learn who's who in your community. Include a page listing the major contributors, community leaders, and module owners. If you can include pictures of folks, all the better. Introduce novices to your regulars and leaders at community meetings.

Depending on your project, you may want to have a special mailing list, discussion forum, or even a subproject for newcomers to get their initial questions answered. This can keep the same basic questions from constantly being posted to your main mailing lists. It lets novices help each other, which sets a good tone for later. This is another reason to have good FAQ lists and to regularly link to them in the major mailing lists.

Be sure to encourage a friendly attitude that is tolerant of inappropriate postings by novices on project mailing lists. Gently let the offenders know how your project does things, without personally attacking them. Redirect inappropriate messages to the correct mailing list. Discourage flaming. This attitude encourages novices to participate and is good for your community of regulars too.

Reward Your Regulars

Regulars are the lifeblood of your project; they are the folks who do the work to make your project a success. They answer questions on the mailing lists, report bugs and bug fixes, contribute code and new ideas, tell others about your project, and do all the other work necessary for your project to move forward. Do everything you can to encourage your regulars to participate and to retain their interest in your project.

Because many open-source projects are meritocracies, be sure to recognize people doing good work. Be sure to add them to the project's list of contributors. Reward them by granting them CVS commit privileges. Invite them to be part of the core group. Encourage them to take responsibility for part of the design or a module of code.

A good way to show appreciation for the work your regulars do is to have a spotlight feature on your website's home page or in your project's newsletter that highlights individuals and their work. You can also encourage them to give a presentation at a community meeting. Not only does it reward them directly, but it also can educate your community about new functionality and encourage other regulars and novices by giving them an example of what your community values.

Another way to show that you value your regulars is to use resources from your company to further refine one of their contributions to help bring it up to project-quality standards, as described earlier. Even having one of your graphic artists create a cool logo for a subproject may be appreciated. Just be sure they feel you are working with them and not trying to take over from them.

The ultimate way to retain your best regulars is to hire them! It is always hard to find top talent and especially to know how they will function in your company's culture. With open source, you have a way to try out people and determine whether they fit in with your current team. Even if they do not live near any of your company's offices you already know that they can work productively from wherever they do live (that is, remotely). For example, Sun Labs is supporting a small open-source project called Electric, a computer-aided design system for electrical circuits. When one volunteer really distinguished himself by his contributions, Sun hired him--even though he lives in Moscow and the Sun Labs team is in California.

Empower Your Leaders

Your leaders are the people who keep your community running. Some will be outside volunteers and some will be your employees--a successful project will have a healthy mix of both. Some will have formal leadership roles, such as module owner, but many roles will be more informal. For an open-source project, leadership is all about having a vision and working with others to make it happen; it's not about being in charge, making decisions, or giving orders.

The leaders in your community will naturally take on many different roles:

Welcoming newcomers to the project and answering their questions.
Answering technical and procedural questions on your project mailing lists.
Guiding discussions to help them reach a conclusion.
Selecting high-quality content to highlight on your website or in your newsletter.
Coordinating activities such as releases, community meetings, or trade-show demos.
Providing quality checks on contributed code.
Policing community discussions to keep them civil, and redirecting messages to the correct mailing list.
Resolving conflicts and helping the community to make decisions.
Solving complex technical problems.
Creating compelling visions and directions for the project.

You need to watch your regulars to see which are starting to assume any of these roles and encourage them to do so. Try to recruit outside volunteers to oversee visible project-related activities such as module owner, release manager, or newsletter editor. Establish as soon as possible that community members do important things.

Be sure to provide support for new leaders. It may be as simple as your community manager trading some tips via email on guiding discussions or assigning an experienced module owner to mentor a new one. You may want to give all new module owners training on the various tools your project uses. But recognize that volunteers have limited time, so don't push them to act like full-time employees.

You can reward your leaders and make them more visible by giving them a special place to express their ideas and opinions. This could be a column in the community newsletter or a series of articles on your website--you could encourage them to write weblogs featured on the project's website. If a leader is not interested in writing, then post an interview instead.

When you have project-related discussions and meetings inside your company, try to invite outside volunteer leaders to participate. Be sure to keep them informed on any decisions you make. All of your project's leaders need to be kept in the loop. You do not want to create an us-versus-them attitude.

Honor Your Elders

Elders are respected long-time regulars and leaders who are your community's mentors, teachers, and advisors. They provide role models for newcomers and regulars on how to behave properly. They may have stepped down from more active roles such as a leader or contributor, but your community can still benefit from their sharing their knowledge.

Some projects take no notice of when major contributors move on; at most they may add their names to a list of emeritus contributors and also remove them from the list of active developers. The Apache Software Foundation's projects have a rule that committers who have been inactive for 6 months or more may lose their status as committers. Although people can regain their committer status by just requesting it on the project's developer mailing list, the fact that they lost it indicates a certain indifference toward formerly valued community members.

Try to identify potential elders and encourage them to continue to participate in some way. They may not have time to write code, but perhaps they would like to follow various design discussions--they certainly have the knowledge to do so, including knowledge of your project's history and why previous decisions were made the way they were. If any of your senior developers move on to another project in your company, see whether you can get their new managers to approve their continuing, though perhaps minimal, involvement on your project mailing lists.

One way to show that you value your elders is to have a special mailing list for them where the community can ask their opinions on important matters that come up. You can also try to solicit their advice on the regular project mailing lists. Include them in activities at your community meetings and interview them on your website or in your newsletter.

Communication Creates Community

Everyone involved with your project--users, designers, developers, and evangelists--should know what is happening with it. Everyone needs to know what's new and be able to participate in discussions about various project issues, plans, and designs. As is mentioned in the section Let Everyone Know What is Happening in Chapter 6, it is crucial that your internal developers use public mailing lists for their discussions so that the entire community can participate.

Your project should start off with as few mailing lists as possible in order to focus things (see the section Types and Number of Mailing Lists/Newsgroups in Chapter 6). This might be one moderated list for infrequent project announcements, one unmoderated list for all user-related questions and comments (including design suggestions), and one unmoderated list for all general developer-related messages (mostly implementation issues).

Your team needs to set a friendly tone on these lists to encourage others to participate (see the section Posting Etiquette in Chapter 6). You should encourage people from outside of your company to respond to questions from other users/developers. We recommend the Jini team's policy of waiting 2 days before answering a general user question. Questions that can be answered by only the core team should be answered immediately. This should result in a mailing list where users naturally answer most of the posted questions, and the core developers answer only the more difficult, technical ones.

Mailing lists are great for discussions, but not everyone has the time to follow them. To keep people informed on current issues, you should start a project newsletter. This newsletter should be published on a regular schedule, ranging from weekly to monthly depending on how active your project is. The contents of the newsletter should be featured on your project's website. An example newsletter topic might be a "contributor spotlight" that focuses on some individual who is doing interesting work on the project. The NetBeans project publishes both a brief weekly newsletter, consisting mostly of links to interesting discussions on its mailing lists, and a monthly newsletter with full articles covering such things as project-related news, feature stories on developers and projects, and pointers to press articles about NetBeans.

Community Meetings

To create a real community for your project requires that people get to know one another. Some of this can happen over mailing lists, but far better are face-to-face meetings. Have a community meeting as soon as possible and at regular intervals afterward. For smaller projects, you might need to hold your community meeting as part of some larger event, for example as a birds-of-a-feather (BoF) session at conferences such as JavaOne or LinuxWorld. Try to hold meetings in different locations so more of your community can attend.

A community meeting is a great way to raise the overall level of excitement about your project. Avoid dull status-reporting sessions. Plan for more interactive formats to take advantage of people being together. Users and developers usually have lots of questions they would like to ask the core developers, so be sure they get a chance. Introduce major contributors so people can associate faces with names. Your developers should also become known as individuals. Reserve time for people to schedule BoFs during the meeting. Include time for people to informally chat and network.

Don't be constrained by regular meeting formats. The Jini project has held several open celebrations that they call Jini Fest! where they show off cool aspects of Jini technology and provide an occasion for Jini developers to socialize and network. These have been more free-form events held during the annual JavaOne conference where groups are invited to show off their work with Jini--both companies using Jini and various Jini Community projects are invited. Each group hosts a table in a big room. Add food and drink, plus several hundred Jini enthusiasts, and you have an exciting event. They even filmed part of the event as part of a webcast about Jini technology featured at JavaOne.

Community meetings are also a great place to hold working group meetings. Getting the major players into a room can speed up decision-making on open issues. (Be sure to report back via email to the full community on any decisions made at the meeting.)

Other meeting options include phone conferences and online chat sessions. You might also consider using a webcast to present status updates or other information to your worldwide community. The Jini project has done several webcasts. Although webcasts are not as interactive as a meeting, they are good at helping your community to get to know the people presenting material. Putting a human face on your main developers and contributors helps to build community. An open-source project has by definition a distributed work group, and you need to explore ways to facilitate communications among the members.

Events

Sometimes you can create a strong sense of community and attract others to your project by sponsoring events, such as a reception at a larger conference. In many cases, conference organizers are receptive to the idea of a special event or sponsorship at their conference to add texture at low cost to them. Conference organizers often contract with a hotel or conference center to lease a fixed set of the facilities for the entire duration of the conference, and therefore these facilities might be available at low or no cost to you.

A good example is IBM and Eclipse. At the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) in both 2002 and 2003, IBM sponsored Eclipse receptions. In 2003, the reception featured a few short speeches but lots of food and demonstrations. There were no other conference events that evening, so attendance was high. The event was held in one of the main conference halls, which cost IBM nothing, and the entire affair cost less than $20,000 for the food and drinks. It was at this conference and reception that Erich Gamma and Kent Beck's book on contributing to Eclipse went public.

New Forms of Communication: Wikis and Weblogs

The tools available for online communication continue to evolve. As they do, new opportunities arise for people in open-source projects to interact and collaborate with each other. Two particularly promising new technologies are the wiki and the weblog.

The WikiWikiWeb

A wiki is a website that allows people to edit web pages collaboratively. A wiki makes it easy for anyone to view, edit, and create web pages using just a web browser. A very simple markup scheme allows basic text formatting. In the original wiki, a link to another wiki page was automatically created by writing several words with their first letters capitalized and with no spaces between them, for example, OpenSource or CollaborativeDevelopment. If there was not already a page with that name, a new one was created.

A wiki is a great way for a community to create a group document. As members browse the existing pages, any time they see mistakes or want to make additions all they need to do is press the Edit this page button displayed at the bottom of the page. This loads the current text of the page into a form in which it can be edited. The Save page button in the form saves a new version of the page, which is immediately made available for all to see.

The first wiki website4 was established by Ward Cunningham in 1995. Ward originally called it the WikiWikiWeb from the word wiki wiki , which means "quick" in the Hawaiian language. For another example, check out the Wikipedia,5 where, in only 3 years, the online community has created an open-content encyclopedia of almost 300,000 entries (as of July 2004). Open-source projects have recently begun to use wikis. The Apache Software Foundation has a wiki6 used by its various projects, and the GNOME project has set up a wiki7 to provide support.

Writing in wiki pages consists of either unsigned, deliberately anonymous text that is intended to be community material which others are encouraged to update and improve (for example, a page on the Apache wiki describing how to do log rotation for the James mail/news server) or a series of signed comments where people hold a form of conversation as they try to reach an understanding of the issues involved (for example, a page discussing which Java IDE to use, also on the Apache wiki). Anyone can both reorganize the conversational threads to clarify the material, possibly moving them to new pages, and revise the community material based on the comments made. Over time more and more community-owned text is created expressing the community consensus and the concluded discussions may be removed. Many wikis provide simple version-control mechanisms so that no text is lost, and archiving important versions of a wiki page can make looking at history easy.

Most wikis have a special RecentChanges page that displays an automatically generated index of all the wiki pages that have been changed recently. Many people check the RecentChanges page frequently to see what is new on the wiki.

Many people's immediate reaction when they first hear about wiki is that it cannot possibly work. People worry that someone will come along and delete what is there or write random garbage all over pages. This indeed can, and does occasionally, happen, but as soon as the wiki's community members notice the problem, one of them erases the graffiti and restores the page's original contents from the previous archived version. After continually having their "work" removed, the offending individuals usually quickly give up and go elsewhere.

A more common problem is that no community consensus emerges, possibly because the community is split into opposing viewpoints on some issue. Then it is important that the community try to express each of the viewpoints rather than resolving the issue to a single "correct" one. This requires a real sense of community and a respect for the beliefs of other community members. The Wikipedia calls this writing with a neutral point of view and has a good description of how to do this.8

Another reason that discussions sometimes do not resolve is that the community is exploring a new area and just doesn't know enough yet. In this case, the discussions remain visible as a reminder that the issue is still open. As individuals and hence the community learn more, people may eventually add to the discussion and reorganize it.

The wide-open nature of the wiki and most people's unfamiliarity with wikis can present a barrier. People can be afraid of what will happen to what they write or unsure what type of contributions are acceptable. The tone set by the community will either encourage new folks to join in or discourage them from doing so. Once people contribute and begin to edit wiki pages, they gain a feeling of empowerment and often develop a vested interest in overseeing the wiki as a whole.

A wiki is a community effort and each develops its own culture. In general, the sense of working together to build a better understanding seems to encourage people to be more polite than many other Internet activities do--perhaps because on a wiki any flames, spam, and trivia can be easily deleted, while the constructive comments typically expand and grow.

Coming to a common place, sharing a vocabulary, and working together over time on common goals all help to make the people using a wiki into an actual community.

For more information on wikis, see the book The Wiki Way: Collaboration and Sharing on the Internet by Bo Leuf and Ward Cunningham.

Weblogs or Blogs

A weblog (also known by its contraction, "blog") is an online journal with entries on whatever topic or topics interest the author, usually including links to online articles, news, or other blogs. Blogs enable people without much web experience to create, format, and post diarylike entries with ease. Blogs are a great way for an individual to have a place to express opinions.

We have discussed mostly communities built up by collaboration, but the blog focuses on the individual. Helping to create a strong individual identity also helps to build community--community is about getting to know the individual members in the community better over time, something that blogs help to do. They also help to bridge the gaps among multiple communities that the blogger is a member of. Many people who write blogs include a list of links to other blogs that they read. This blogroll helps to define the blogging community that a person identifies with.

A good way for an open-source project to make use of blogs is to have a news page that displays the latest blog entries from selected community members or a project group blog. Most blogs provide an RSS ( Rich Site Summary or Really Simple Syndication ) feed that other web pages can subscribe to. Using this RSS feed, a project can feature on its home page headlines for the most recent relevant blog entries.

Having key people in your project write a blog (called "blogging") is another channel for getting important information to your community; it is also a good way to reach people outside of your community who are interested in your project. Anyone can subscribe to the RSS feeds from your blogs and thus get timely updated news concerning your project.

A good book on how to write a blog is The Weblog Handbook: Practical Advice on Creating and Maintaining Your Blog by Rebecca Blood.

1. http://www.mozilla.org

2. http://www.gnome.org

3. http://www.openoffice.org

4. http://c2.com/cgi/wiki

5. http://www.wikipedia.org

6. http://wiki.apache.org/general

7. http://gnomesupport.org/wiki

8. http://en.wikipedia.org/wiki/Neutral_point_of_view

Innovation Happens Elsewhere
Ron Goldman & Richard P. Gabriel
Send your comments to us at IHE at dreamsongs.com.

Previous Table of Contents Up Next