I've been wondering about getting contributions to a new open source product my team will be developing. There's encouragement for us to get as much support from the wider community as we're able, but I can also see this absorbing a lot of time making sure that 3rd parties located outside our office are on track regards things like code quality. Also at the start of the project we're likely to have a lot of informal discussions within the core team regarding design of the system, spikes etc. and taking these online to allow community involvement will be time consuming and I can imagine could make the discussion less effective.

There is a more human side to this which probably needs to be considered: allowing community involvement in the design process may also have its benefits regards perceived ownership of the project, and there's always a chance that early involvement could pick up on problems that the core team haven't noticed.

So the question: at what stage of an Open Source project should you invite contributions from the community?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers
3

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.

@karianna thanks, will give the link a read! But if there are already 123 JIRA tickets and you know you want a REST interface, then you're a fair way down the design path already, aren't you?
–
AlisonNov 22 '10 at 11:10

@karianna LOL, nice edit ;-) not sure it addresses my design question though. This book is gold; have you read the whole thing, and would you consider it THE reference on this subject?
–
AlisonNov 22 '10 at 12:46

@Alison - Yes it's considered to be the canonical text, but it's not always been well advertised I guess? It's the basis of the talks I give at conferences in this area. It could possibly do with a small update - I'll be speaking to Karl about that next year :).
–
Martijn VerburgNov 22 '10 at 12:53

This was discussed at length in the google IO talk Myth of the genious programmer, by Brian Fitzpatrick and Ben Collins-Sussman of Subversion. In short they concluded that it shouldn't be so early that there is nothing there yet (ie. "come look at my awesome project! there is not really much here yet but a lot of awesome things are planned!") or too late so all the decisions are already made (It's hard to get a word in on a solo project.)

The summary of that post is that software rots. If you want to keep it fresh, you have to do maintenance. And the more popular a project gets, the more bugs are going to be found, the more features are going to be added, and the more this maintenance task is going to bog you down.

In fact, this is a very common problem. There's a great talk by Fat called What Is Open Source & Why Do I Feel So Guilty? In this talk (which I highly recommend you watch) he tells the story of one of his OSS projects, and how over time, he found himself spending most of his free time doing ticket triage and management tasks. And he talks about how damaging this was. Which is something I can completely empathise with.

The solution, of course, is to add people to the project early and often. Your time is limited, and valuable. Invest it in growing your contributor base, and the rest of your problems start to take care of themselves.

As I say at the end of my post: "What is more important for your project: features or a future? Pick one, and prioritise your efforts accordingly."