23

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?

Armand
  • 6,508
  • 4
  • 37
  • 53
  • Open development right away but release the beta to a select number of users until it's stable. I talk about it here http://stackoverflow.com/questions/3066648/any-benefit-disadvantages-to-open-beta-vs-closed-beta-for-webapp/3067146#3067146 in great length. – Evan Plaice Mar 25 '11 at 13:59

3 Answers3

16

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.

Martijn Verburg
  • 22,006
  • 1
  • 49
  • 81
  • 1
    @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? – Armand Nov 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? – Armand Nov 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 Verburg Nov 22 '10 at 12:53
7

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.)

HaskellElephant
  • 251
  • 1
  • 5
2

I agree with Martijn Verburg. You should start soliciting contributions right from the start. I wrote a little about this before.

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."

Community
  • 1
Naomi Slater
  • 121
  • 1