Right at the very beginning! You want the community to feel that they have a genuine stake in your project, otherwise they will feel like they are being used as free labour.

All communication should be over a public mailing list or forum, again this enhances the idea of the community.

You can mitigate the 'design by committee' problem by laying out a clear vision in your initial posts to the mailing list, e.g.

"So we're looking at a domain model to represent our Pet Store (as per JIRA-4). Does anyone see any major issues with this model?"

In terms of accepting actual physical contributions, you should start by accepting patches and performing public code reviews on them. That way contributors can already publicly see what sort of coding standards they need to adhere to. Make sure your commits are available in a commit mailing list as well - you need to be held to the same standards!

Read http://www.producingoss.org for more details on how to run a successful open source project.

Right at the very beginning! You want the community to feel that they have a genuine stake in your project, otherwise they will feel like they are being used as free labour.

All communication should be over a public mailing list or forum, again this enhances the idea of the community.

You can mitigate the 'design by committee' problem by laying out a clear vision in your initial posts to the mailing list, e.g.

"So we're looking at a domain model to represent our Pet Store (as per JIRA-4). Does anyone see any major issues with this model?"

In terms of accepting actual physical contributions, you should start by accepting patches and performing public code reviews on them. That way contributors can already publicly see what sort of coding standards they need to adhere to. Make sure your commits are available in a commit mailing list as well - you need to be held to the same standards!

It also pays to have project standards on a Wiki or some such document.

Read http://www.producingoss.org for more details on how to run a successful open source project.

Right at the very beginning! You want the community to feel that they have a genuine stake in your project, otherwise they will feel like they are being used as free labour.

All communication should be over a public mailing list or forum, again this enhances the idea of the community.

You can mitigate the 'design by committee' problem by laying out a clear vision in your initial posts to the mailing list, e.g.

"So we're very much looking at making X, Y, Z services available over a RESTFul interface (as per JIRA-123). Does anyone see any major issues with this?"

In terms of accepting actual physical contributions, you should start by accepting patches and performing public code reviews on them. That way contributors can already publicly see what sort of coding standards they need to adhere to. Make sure your commits are available in a commit mailing list as well - you need to be held to the same standards!

Read http://www.producingoss.org for more details on how to run a successful open source project.

Right at the very beginning! You want the community to feel that they have a genuine stake in your project, otherwise they will feel like they are being used as free labour.

All communication should be over a public mailing list or forum, again this enhances the idea of the community.

You can mitigate the 'design by committee' problem by laying out a clear vision in your initial posts to the mailing list, e.g.

"So we're looking at a domain model to represent our Pet Store (as per JIRA-4). Does anyone see any major issues with this model?"

In terms of accepting actual physical contributions, you should start by accepting patches and performing public code reviews on them. That way contributors can already publicly see what sort of coding standards they need to adhere to. Make sure your commits are available in a commit mailing list as well - you need to be held to the same standards!

Read http://www.producingoss.org for more details on how to run a successful open source project.