An open source project’s website is the main gateway for potential users and contributors to learn about your project, and it assists existing community members to contribute to the project. But it has to do it right.  Does your website clearly present your project, its goals and status, and assist your community members to efficiently communicate with each other? Is it attracting new contributors?

This article, based on the oVirt community site development, shares areas to pursue for producing a community website.

oVirt, a virtual datacenter management platform, is well-regarded for the strength of its community. oVirt’s website is part of that strength, but is in need of some improvements. Currently the site is based on MediaWiki, which does not fully allow to bring oVirt’s website to the next level of being a truly effective and dynamic community website. The community is in the early stages of planning for a new platform and a new “look and feel” for oVirt.org, and as this new site planning and reviewing the old site gets underway, I’d like to share some thoughts and recommendations on how to increase the chances of an open source community website to attract new contributors and ease the work and communication of the existing community members.

Bring it home

The homepage is undoubtedly the most visited page of your website, so clear guidelines must be met.

Make sure the homepage clearly introduces and explains the project in a few short sentences. What is the project’s goal/topic? In other words, what does the project do? What’s the current stable version and when was it released?

There should be a clear and simplistic “get in touch” section, preferably with easy-to-spot icons. If you have an IRC channel, mailing list, or any social media presence (i.e., Twitter, Facebook, Google+, etc.) then this is the place for it. If there are several different IRC channels or mailing lists, it’s best to briefly explain what the purpose/target audience is for each mailing list or IRC channel.

Speaking of mailing lists, it’s preferable not to have too many of those. Twenty mailing lists are probably confusing for anyone new to the community. Fewer mailing lists (and other channels of communication) will make it easier for newcomers to reach out and ask a question. It will also show participants that the project is glad to communicate as well as ease current contributors’ ongoing communication.

Consider placing social media icons that lead to your relevant accounts in the top menu. This practice has become very common on many websites today and is intuitive to users.

If there are already existing customers stories or case studies, consider placing their logos in the story and link to another page that tells how they use the project. If you don’t have case studies, you may want to add some.

If your project has meetups, or if there is a booth or a talk in some upcoming event, mention it in an “upcoming events” section with a link to the relevant event, with its date and location.

A “news feed” will show the project is “alive” and not “abandoned”. It can be in the form of embedding a Twitter feed mentioning the project, or any other “recent news” section with dates and short updates about the project.

Beyond the homepage

It’s not just the front door of the house you have to worry about. Here are some recommendations for the rest of the website.

Be sure to clearly mention how and where to report a bug. A top-menu option or a big and clearly visible button are good options. Reporting a bug is relevant for all your project’s audiences, users, and developers.

Make an obvious download menu or a page with the following information: Where can the project artifacts be downloaded from? What are the installation steps? What is the minimal hardware and software requirements? Something else to consider: Would you like to publish the download instructions and artifacts for just the current version or several old versions, too?

Documentation is a huge asset for any community. Link to user documentation that explains the main features of the software, with screenshots and example inputs. Ensure you have feature pages that are easily searchable and tagged with descriptions of the main project’s features and the relevant release number/version—both the ones that are readily available and the ones being developed. This way users and developers will be able to understand the road map of the project.

Developers need to be especially accommodated. A good and clear developer-oriented section can usually bring more contributors to the project. Some ideas to consider for this section include:

•  Links to the source code and well documented how-to-build-from-source steps.

•  What is the project’s technology stack–which programming languages are used? What are the main frameworks/components/high-level architecture? Having a clear and short statement about the technology stack can save newcomers time when they are unsure if they can contribute to the project based on their technical knowledge and the languages/frameworks they are interested to work with and learn. Incoming community members can surely understand it from the source as well, but it will be definitely more time consuming to browse the source for that.

• What’s the code review process for the patches and which tool is used for the code review? Also be sure to mention who are the main maintainers and their responsibility areas.
• A link to a filter with some easy/entry level open bugs that can help newcomers get familiar with the code and they can help solving some bugs on the way.

A blog is a great way to share news and updates about a new version release, new features, and pics from past events. Make sure to link clearly to the blog from the main menu, and have tags on the blog posts to ease searches. Along those lines, make sure the entire website is searchable, and that a search box is clearly visible on every page, especially on the homepage.

Finally, give some thought on how to maintain changes of the website itself. How can someone easily submit changes to the website? For example, add a new feature page or fix a typo in documentation. Who should review and approve these changes? Which tools and skills should the users have for that? Should they know git and submit it as patches? That’s possible, but probably too complicated, especially for the users who are not developers. Is there a better and simpler tool for that?

Website technologies have made it easy to implement features that will accommodate the needs of open source communities, but picking the right tools and designing the right website structure for your community is something that takes time and thoughtful examination.

Originally published as Getting the Most Out of Your Open Source Project Website on the Red Hat Developer blog.