There is no one way to build and manage a community led project, but there are common tools and practices that we can use to inform our work. Let's take a closer look at some of them.

Many people think that being open in a project is about spending time informing people of current activities. However, this is not the case. [ <!> A BIT STRONG? SURELY THIS IS ONE PREREQUISITE FOR BEING OPEN? SAY SOMETHING LIKE 'THIS IS NOT THE ONLY GOAL'? OR AM I MISSING THE POINT?] The goal of being open is not to ensure uninterested people [ <!> WHAT ABOUT KEEPING THE INTERESTED PEOPLE INFORMED?] fully understand what you are doing. It is about ensuring that interested people are included in the process so that they can add value to the project by contributing resources and effort in whatever way they are able to.

To facilitate this, and to run an efficient open [ <!> SOURCE?] project you need a clearly defined development process. You also need a number of tools to ensure that following the process does not impact on the projcet resources negatively.

For an open [ <!> SOURCE?] project there are four essential tools: [ <!> I THINK WE SHOULD LIST THESE AS THEY APPEAR IN THE DOCUMENT: 1. TOOLS FOR COMMUNICATIONS, WITH SUBSETS 1.1-1.5 AND THEN 2-5.]

The process for a developer will look something like this: [ <!> WHAT PROCESS? COMMUNICATION PROCESS? MAY BE MORE USEFUL TO DESCRIBE TOOLS AND WHAT THEY DO FIRST, SO I SUGGEST MOVING THIS TO ITS OWN SECTION AFTER CURRENT DIV.4 OR 5, AND CALLING IT 'USING COMMUNITY TOOLS'. IT WILL NEED NEED MORE OF AN INTRO. ALSO, DO WE WANT TO DESCRIBE ANY PERSPECTIVES OTHER THAN THAT OF THE DEVELOPER?]

An important thing to note about this process is that it takes very little effort on the part of the developer to keep the community informed. The developer is not doing anything they would not normally be doing. The majority of community updates are created by the tools not by the human. Openness does not need to increase effort (beyond getting the tools set up right from day one).

What if a discussion arises out of some of the work? That will take a little effort as the developer has to consider the issues being raised and choose the best route. However, spending a little time in upfront code management saves loads of time in long term maintenance. This has been proved in many studies of software development.

Tools for communication

Mailing lists and/or forums

Mailing lists and/or forums are used for discussion and consensus building. They should be publicly available and should be archived to provide traceability and documentation.

Some people prefer the 'pull' mechanism of web based forums - that is, the user needs to visit the forum in order to read the latest posts. Other people prefer the 'push' mechanism of mailing lists - that is, the latest posts arrive in the user's email client and can be responded to without visiting a web site. It is important to understand your community's needs and expectations and provide the appropriate tool.

Many of the newer mailing list/forum tools provide both web based and email client interfaces so that users can work with whichever tool is most appropriate to their needs. We strongly suggest you adopt one of these hybrid tools to ensure that you maximise the chances of a user engaging with your community.

Blogs

Blogs are ideal for disseminating ideas or news, but are not ideal for discussion as not everyone will see follow-up comments. However, as an efficient mechanism for announcing plans or developments they can be very useful, especially when you consider that, unlike a read only web page, they allow readers to add additional information.

RSS

RSS is a means of syndicating information. RSS feeds are a convenient way for people to pull content from your project and aggregate it in a meaningful way for the way they work. That is, an RSS feed can appear in many places, such as a user's mail client, an RSS reader, a web based aggregator or a news site. Providing RSS access to as many of your communications channels as possible increases the chances of that communication reaching new users.

Podcasts

PodCasts are audio or video files that provide information about a project. [ <!> NEED MORE CONTENT HERE]

Screencasts

Screencasts are demonstrations of software in use. Users can view them without needing to install the software being viewed. [ <!> NEED MORE CONTENT HERE]

Content management and dissemination

[ <!> NEED TO EXPLAIN WHAT CONTENT MANAGEMENT IS HERE] Content management solutions require you to trade between:

The following table presents some generic solutions for content management and attempts to indicate their strengths and weaknesses. The scoring is from 0 (low) to 4 (high).

Solution

Flexibility

Process and Structure

User Access

Notes

HTML web site

3

2

0

Editing raw html files allows us to do anything, but process and structure must be manually enforced and users have no easy way of contributing to changes.

XML web site

4

3

0

Editing XML is very similar to editing raw HTML; however, a more flexible source format allows more automated control over both the content types and the site structure (i.e. index pages can be auto generated).

Wiki

1

0

4

Wikis are great for allowing users easy access to your content, but without careful management they quickly become disorganised and it can be difficult to repurpose the content for other uses.

CMS

2

4

3

A CMS system allows tight control over the process and structure of your content and can also be fairly easy for users to access; however, they tend to be more limited (than raw files) with respect to reusing the content and can be more difficult to install/set up

Another important consideration is tracking contributions to your content. This is covered under the Intellectual Property Rights section [ <!> DO WE MEAN DIV.5, MANAGEMENT OF COPYRIGHT?] below.

Description of a Project (DOAP)

DOAP is a project for creating an RDF/XML vocabulary to describe open source projects. It allows key details about a project to be recorded and made available via the semantic web. [ <!> NEED MORE CONTENT HERE}

Version management

It is very important to provide a version control system (a.k.a. revision control system or RCS) for the management of your project resources. This allows you to track who made what changes when, why they were made and, if necessary, to roll back changes that cause problems. Using an RCS is easy; using one correctly is harder. If you've never used an RCS before, we strongly recommend you find a mentor and read our document on version control.

When used correctly, an RCS assists with keeping developers informed, release management, bug management, testing, code stability and experimentation, contributions management and write access to resources. Your RCS is a coordination and management tool as well as your project's time machine. It will ensure everyone is fully informed about all changes to resources and will allow anyone to retrieve all resources from any given moment.

some projects believe they don't need an RCS system because they have only a single developer, they are wrong. The ability to examine the history of a resources development in extremely valuable even in a single developer project.

See also:

Issue tracking/project management

An issue tracker allows your users to report bugs and request new features. It also allows your project management to plan work and prioritise community driven requests.

By using an issue tracker you can provide a clear indication to your users as what to expect in future releases of your code. This means that if a user has a specific need for a feature or bug fix that you have no intention of implementing in the short term, they can opt to invest some of their own resources in adding the feature or fixing the bug. Communicating your plans clearly and efficiently to users is the first step to having them contribute to the development of your project.

An issue tracker can also be used to accept and track contributions to your code and documentation.

Management of copyright

It is vital that you know who owns the copyrights in your project. To do this, you need to be able to trace every contribution to its original author. In the case of contributions that directly affect your project outputs, such as programme code or documentation, this is most efficiently managed through a version control system (see above) coupled with a clearly defined Contributor Licence Agreements and a submission process using an issue tracker.

Where contributions are not directly in the form of source code or documentation, for example design ideas, it is important that they are captured in a publicly accessible and traceable form. If you conduct your design discussions on a mailing list, the archives of that mailing list are perfect for this.

[ <!> NEED A CONCLUSION]

Further reading

Presentation: Open Development ManagementPractices

OSSWatchWiki: CommunityTools (last edited 2013-04-15 13:56:16 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.