1. Have the relevant info.

This is probably the easiest one. Here's the list of what the website should say:

• What is the project; brief explanation required, a separate detailed explanation is a bonus (that's in addition to the brief one, not instead of). If your project is so obscure that people have to understand a few concepts before they can even have an explanation, then write the explanation assuming they do, and sprinkle it liberally with links to Wikipedia or whatever you prefer.
• Project status. Is it vapourware, usable work-in-progress, stable, abandoned? That's a reasonably important piece of information.
• Latest release: number (or name) and date, download link(s).
• Contact info: how to report bugs at least. Maybe you or your community provide some measure of support, maybe not; but at least a channel for reporting bugs is an absolute must. For a more normal project, where to ask questions (mailing list, irc), and how to contribute, are also common.

And the nice-to-haves:

• Documentation; even if your documentation is very good, mirror it online.
• Brainstorming area: a wiki or board is great as brewing grounds for ideas which may become documentation.
• Browseable, searchable bug/defect/TODO database.
• Marketing area: say why your product is great, dazzle visitors with screenshots or screencasts or code samples or whatever, make them want it.
• Egotrip area: give some praise to important contributors, including yourself if you wish. That gives people an incentive to contribute.

2. Don't make the news page the front page.

Your site is not a blog. Visitors have no interest whatsoever on knowing that a new version is out, or one of the developers is on vacation, or the lead developer's dog had puppies, if they don't know what your project is yet.

The front page is your introduction card. It's there to catch the visitor's attention. It should start by explaining what the project is, and maybe go on about why it's the best thing since sliced cheese; if your project has good eyecandy, include screenshots; otherwise, try to think of something else flashy and shiny to include.

It's ok to have a box with the latest news somewhere, maybe as a portlet; as long as it's not the dominating element in the page.

If your “site” is a single page, then replace “front page” above with “first section at the top of the page”.

I know many people think the news are the most interesting part; they certainly are for you, since you're already an user and supporter. Returning users can easily bookmark the news page rather than the front page. Even better, provide a syndication feed, so that they don't have to.

3. Design portably, design accessibly.

A website for a Free or Open Source software that only looks right in a non-free browser is an oxymoron. Test it in Gecko (any of them; Firefox, Epyphany, Galeon, Seamonkey, you name it) and in Khtml (either Konqueror or Safari, preferably both if you can have access to a mac).

Before the launch, give it a little go on Opera and Explorer too just in case. If it looks horrible in the proprietary browsers, you may or may not fix it, it's your call; if you don't, then consider adding a “Get Firefox” button. However, make sure your site is navigable with the non-free browsers, even if it looks like last week's leftover sushi in a train crash.

Please consider giving your site a go on a text-only browser too. That is for two reasons:

• Text-to-speech browsers used by blind or sight-impaired people are very similar to text-only browsers like lynx. If you can figure the site out in lynx, then a blind person will be able to learn about your project. If your project is something that is potentially specially relevant to visually impaired people, then you should probably look up accessibility hints on the web, and try your site on emacs w3 (w3 with emacspeak seems to be the preferred browsing solution for visually impaired true geeks).
• If your project is something I might want to run on a server, I may sometimes want to find something on your site with links or w3m over ssh. I expect that to be a rather common practise.

A few odder corner cases can be deduced from the above. If your project is something that people might want to use on their phones, make sure it looks decent on phone web browsers; and so on.

Corollary: do not under any circumstances use Flash or some other non-free non-sense like that. Preferably, avoid Java too — most Free Software and Open Source users will have a JVM, but a surprisingly high number of them don't have one in their browsers.

4. Think trough your information paths.

Serious website design includes tracing information paths: what kinds of information or services may visitors be looking for, how do they get there, and how easy it is to discover it.

Of course, doing the full-fledged thing may be too much on what is, for most people, a hobby. But do try to think up a few cases. Pretend you know next to nothing about the project — or even better, ask a friend, your sister, your dad, whatever. See if they click on the right menu items to get to the information they want. If they have to ask you “how do I...”, you're in trouble; specially if it's “cool, but how do I download it?”.

If you're into UI design, think of navigation in your site as an UI (because that is what it is). Feel free to do menus and submenus. If your software has a GUI — specially if it looks good — you may want to make the site look like the software, or resemble it, or reuse elements from its interface that people will remember. For a good example of the latter, see the gaim website (the icons in the main menu are taken from a Gnome icon theme).

5. Simple is fine. Now go write software.

If you whip up a few webpages — and you respect the rules above — then you're fine. Doesn't matter if you don't have a single line of css or javascript, if your site is mostly text, if there's no spiffy or shiny whatsoever. Don't let people convince you otherwise. If it conveys the information you need to convey, and you like it, then use it. Spending too much time on a flashier website will distract you from what you actually intended to do when you started (or joined) the project: write software.

Of course, if someone offers to help, then you can weight that as any other offer for help. Will it end up taking more of your time than you have, or will the contributor be able to handle it mostly alone? Does the contribution add real value? If you're getting a wiki, CMS-like news posting system, syndication, screenshot gallery, or documentation archive, or anything that is actually going to be useful to your users and potential users, then it might be worth the trouble, more so than if it's about a tableless layout or smart ajax menus.