What should be on the landing page of an open source project? [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Improve this question

The reason for asking this question is to get a good idea about how best to present an open source project for my own projects. How can one best make a project attractive to potential new users and/or developers? Clearly projects vary in nature and scope so when answering it may be necessary to qualify any suggestions which are contingent on these factors.

It would also be interesting to see some good examples of the best presented projects out there!

Here are some things that I look for on the landing page of an open source project, in approximate order of priority

Elevator pitch: what does this software do
Download link for the latest version
Latest news; what's new in new versions
Documentation link
Link to discussion boards/mailing lists/bug tracker; how to talk about it and report problems
Link to the source code/revision control system

Explain what it does, probably also by explaining the problem it solves. If you can do that in big type (somewhere between the size of a Stack Overflow question heading and the text of the actual question) in 2-3 sentences, so much the better, you can link to the "learn more" page where you do the deep dive.

Make it very easy to download a copy and get started. (A big "download now" link is good. MoFo did this very well with the Get Firefox site and that pattern has spread appropriately. If it's a package install e.g. a Ruby gem, spell out the steps.)

Show where people can go to ask questions, and/or the documentation. You do have documentation, right? (Or you're working on it?)

Beyond that, link to the necessary stuff: code repository for those who want to browse, a more detailed "about" page (that might be part of the documentation), list of contributors (might also be part of the documentation) but the big part is to answer Why and How as succinctly as you can.

Basically, that's the story. Your first page is the first slide or two of your presentation.

For new/potential users:

Overview or outline of what it does (the pitch)
Screenshots or examples of some core features

I think the majority of your returning visits will be from developers using your project; think of what you as a developer might need:

Clearly visible link to download latest build or source
Link to your SCM repository & how to contribute
Link to API docs
Link to issue tracker

Users of your project are interested in this things, in order of purely subjective importance:

Downloading your apps
Knowing what your apps does (project descriptions, screenshots)
Get Help and Documentation
How to report bugs
How to get access to the source and to contribute

How I would do it is to have a huge download link in the first page, with a short description of what your program is (max. 1-2 paragraph). Then there should be a link in obvious place longer description; forum/mailing list and documentations; and how to contribute and to report bugs.

Rationale

Why download links first instead of project description first?

Your user likely come from two sources:

articles referring your project, or your project announcement forums
search engine

In both cases, it is very likely they already have an idea of what your project is about before landing on your page. In the first case, they have read the article; while in the second case, they are searching for a tool similar to your project.

However, for the second case, it is likely that they are still not sure that your project really are what they are looking for; that is why you add a brief project description on the side of the download link. This is to ensure them your project is/is not what they are looking for.

Why "Help and Doc", "Bug Report", then "Contribute"?

That's the order that user will do when they have problems with your program. First, they will look at the help and documentations, then maybe ask a few people in the forums; failing that, now they will file a bug report or feature requests; then if nobody took interest on the bug report/feature request, some will then have have the willingness to contribute.

You can get ideas from: