When (and why) do volunteers join an open source project and start making significant contributions (see definition below)? Does it happen whe the project is already usable and has deployment? Or does it also happen when the project is just getting its burst of deployment and there are very small barriers to usability to various people (e.g. bugs)? How much contribution comes well before deployment?

Of course "usable" and "deployed" may depend on the user, so this may depend more on the person getting involved. A second way of asking this question is to ask the volunteer if he/she was a user before becoming a contributor, or became a user and a contributor around the same time, or became a contributor well before becoming a user.

I'm querying OS volunteers and OS project founders (people with project history perspective) to see if I can get some answers to these questions.

Definition of significant contribution: for purposes of this survey,

• Any code contribution that makes it into the product is considered "significant"
• Socializing or throwing about ideas on the mailing list is not considered "significant"
• Some non-code contributions that make it into the product might be considered significant -- e.g. graphic design of a suite of icons/buttons, or writing pages of documentation

OS project overview of volunteeer patterns

People start OS projects from scratch for a whole set of reasons -- to learn a technology, have a hobby, or get VC funding. Rather than get into those reasons, I asked some OS project maintainers/managers to estimate when and why they got volunteers on those projects.

Did you get a significant bump in volunteer contributions to the project when it was in...

• Phase 1 -- still in progress and not in deployment or use outside of development team.
• Phase 2 -- starting to gain deployment or users outside development team.
• Phase 3 -- deployments or users lasting over a year or in significant numbers (100s or up)

mod_dav -- Greg Stein

Greg estimated that a significant bump in mod_dav volunteers came when the project was almost/barely usable, and another when it was completely usable.

• People often want to "hang about" in phase 1 but not contribute.
• Some people start to contribute when the project is just one quick feature away from being usable for them (phase 2) but this is actually rare -- when there are blocker features missing, most people go away.
• Most people start to contribute after they deploy the software and decide it would be even better to have an extra feature (phase 3) either as an optional improvement, or one required to extend deployment.
• Greg only released mod_dav when it did something useful so there was a barrier to entry before that
• The motivation of volunteers to be able to poke quickly and see results argues against complexity in open source projects.

mod_pubsub -- Kragen Sitaker

Volunteers arrived mostly in Phase 2.

• The phase of volunteer contributions to mod_pubsub basically ended, possibly before phase 3 arrived.
• "didn't actually work out of the box"
• "unpredictable performance"
• "so much stuff that it was hard to figure out what to start with"
• "large parts of it didn't get maintained and then the main contributors decided to take it private"

Mozilla/Firefox

Having talked to various people involved in Mozilla, I'm rather reluctant to characterize it. It was so big, so famous, had a major precursor that was usable (Netscape Navigator) but was itself unusable for a long time so that it's hard to even say when phases 1, 2 and 3 occurred. Still, I have some notes on this...

• when NS released the source for Mozilla it wasn't in a buildable state, and this deterred a lot of people who seemed otherwise likely to make contributions

Lightning -- Dan Mosedale

It's still phase 1 for Lightning but there are a few contributors even now. Dan says "my gut says that the interesting stuff happens once you start producing stuff that is usable or almost usable"

NetBSD -- Perry Metzger

Perry said that most contributions come in Phase 3.

• I was a BSD unix user for a decade before I hitched up.
• you only get lots of contributors when something is usable
• for stone soup, you must have a functioning pot and stone
• the "cooler" something is, the more the rough edges will inspire work instead of grumbling (or so I've found.) Also, the easier it is to contribute, the more people contribute. Documentation of internals on stuff is key... as is documentation, period.
• you can get more people to code with 2 more hours spent on docs than with 2 more hours spent on code
• transparent development (i.e. anoncvs + commit mailing lists) are important in generating outside developer interest, as is an obvious path to gaining cvs/svn/whatever access.
• start the investment in docs early or you will find it is too much energy later
• I'd say actually that phase 2 you do get developers and phase 1 is when noone cares at all

Project view summary: where major bumps in volunteer contribution occurred

Mature projects

Project	Phase 1	Phase 2	Phase 3
mod_dav		Y	Y
NetBSD			Y
Total	0	1	2

Inconclusive:

Project	Phase 1	Phase 2	Phase 3
Mozilla/Firefox	not sure where to put phase boundaries
mod_pubsub		Y	n/a?
lightning	some	n/a	n/a

OS project contributors

With contributors, I'm asking the "personal" form of the contribution/usability question.

Did you make significant contributions to a project when

• you couldn't yet use it? This means that you made contributions without the expectation that you'd be able to use the project immediately afterward.

• you were very close to using it? Especially if you made contributions with the expectation that with this contribution (and perhaps other changes in progress) you'd be able to quickly become a user.

• you were already a user? Making contributions to software that you were already using, might be to fix bugs that affect your usage, or add features or make the project more usable for other people.

Keith Wannamaker -- mod_dav and tomcat

Keith worked for me at Xythos when he became a serious tomcat contributor. Xythos was already using tomcat as a component of Xythos WFS when this happened, so count Keith as a "already using" for that effort.

Previously Keith contributed to mod_dav so I'll ping him to find out why he did that.

Mark Nottingham -- contributes patches to various projects

Mark is interesting because he doesn't have a long-term contributor relationship with the projects he contributes patches to. Instead, he has contributed patches to various projects. These have either been to software he was already using or could almost use.

• "Sometimes I try to attack [software that's in early development] but usually I find that the changes I need are so deep, it needs a complete rewrite".

Kragen Sitaker -- contributor to Wheat and Twisted

• got involved in Wheat when it was not yet usable (the founder of Wheat was charismatic and convincing)
• got involved in Twisted when he was already a user

Brian Kirsch -- Twisted

• got involved in Twisted exactly at the point when we (Chandler) had decided to use it -- this falls into the "very close to using" category because we had to supply fixes to Twisted in order to be able to use it.

Dan Mosedale -- contributions to various projects

• Dan becomes a contributor when he's already a user -- to scratch an itch

Perry Metzger -- contributions to various

• "stuff I started contributing to, I was almost always a user first"
• "NetBSD, I was a BSD unix user for a decade before I hitched up."
• "stuff I've written cold (including NetBSD^? components) usually I only got help once it was obvious they were useful"

Summary of contributor's reasons

Contributor	Couldn't use it yet	Very close to using	Already a user
Keith			Y
Mark		Y	Y
Kragen	Y		Y
Brian K		Y
Dan			Y
Perry			Y
Total	1	2	5

Comments

Add your random comments (not survey responses but comments about the survey or peoples' responses) in this section, please.

---

There is a slightly different kind of user contribution, but one that none the less can lead to a near-total dominance of "hearts and minds", as well as the market. There is a significant value in having a platform that others can build on. A huge majority of research tools for software development these days are build as Eclipse plug-ins. True, Eclipse was an excellent IDE to begin with, but it also made it easy for a graduate student to build a research prototype that plugs into a solid UI, parser, compiler, debugger, and various other bits of infrastructure software development tools need. This not only saves time in a big way, but also makes it feasible to run user studies validating the research idea, and allows cool demos at conferences. The important conditions for development of this "ecosystem" were first of all that Eclipse was architected that way, but also that the documentation was there for would-be plug-in developers, that the code for "core" plug-ins was available to serve as working examples, that Eclipse developers were helpful answering questions on the newsgroups, and now there is also a growing publishing market for books and manuals. As a result Eclipse first swept the university research labs, and now it's similarly sweeping the industry of add-on software tools. I think Chandler is uniquely positioned to do the same in the information management and collaboration space and should aim for attracting parcel developers as soon as it has a solid basic functionality working and the architecture has stabilized. -- Davor

I'll chime in with an Eclipse example. There is a Pydev plugin for Eclipse that I found almost usable enough for me. In my opinion it had only two blockers before I could start using it myself. So I went and implemented these myself, and sent in the patches which were adapted with some modifications by the maintainer. So I was sctratching my own itch, but it was a big step to take: I had not used Eclipse before, I had not done any Java programming before, and certainly everything about the Eclipse APIs and even Pydev itself was new. So I was surprised that I was able to send in my patches after just a few hours of work, and make Pydev (and Eclipse) usable tools for me. -- HeikkiToivonen - 31 Oct 2005

---

Ted pointed out that a different look at almost the same question resulted in this paper.