Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Free as in Lunch
One of the attractions of Free Software is that it (usually) doesn't cost anything to use. Giving away your code and just having people use it for free doesn't really do you any good, though. You want other people to give you something in return, typically either money or code.
The question that you need to ask is this: "What's in it for them?" People contribute to hippyware projects for a few reasons:
- They need a feature that's missing, and adding it themselves is cheaper and/or easier than buying an existing product that has it.
- It's fun.
- They think that contributing to a project will look good on their CV.
If your company hires developers, the last of these reasons is the easiest to exploit. Make it known that you favor applicants who have made contributions to your codebase. Of course, this practice assumes the existence of a pool of people who would like to work at your company. If that's not the case, you're left with the other options.
The second reason varies a lot, depending on the project. It's relatively easy to get contributors for any project that's associated with some fashionable buzzwords, but much harder with projects that are perceived as dull. OpenOffice.org provides a good example. Around 80% of the development is still done by Sun. Most of the remaining 20% is done by the former Ximian team at Novell. Only a very small number of individuals contribute. Part of the reason for this structure is the codebase. OpenOffice.org is a massively complicated, poorly documented blob of C++. It's very difficult for someone to jump in and get started.
At the opposite end of this extreme is LLVM, which has Doxygen documentation for most classes, a clear structure, and a number of well-written tutorials. From the point when I started to look at the code to the point of having my first patch committed took less than a week, in spite of not having used C++ for several years (a fact which, unfortunately, is obvious in some of my code in clang).
Don't discount small contributors, though. My total contribution to LLVM is very small in comparison to the size of the projects, but when you add up all of the contributions of a size similar to mine, you get a significant total. If the code that you release is easy to modify, you'll get a lot of "drive-by" contributors—people who write one patch, fix a bug, or add a feature that interests them, and then are never seen again. Time spent documenting your code can generate a significant return from this kind of contribution.
The first incentive in my list above is usually the best source of contributors. Who benefits from your project being improved? In the case of something like a compiler, the answer is quite easy to see. If you look at big contributors to GCC and LLVM, you'll see several CPU manufacturers. They benefit from compilers producing good code for their architecture. You'll also see a lot of software companies, which benefit from having their code compiled by a compiler with no usage restrictions.
As I hinted earlier, I'm also involved with GNUstep, which is an open source implementation of the APIs derived from the OpenStep specification that Apple calls Cocoa. A number of recent improvements have been contributed by companies using GNUstep to port Mac applications to Windows and Linux. It's cheaper for them to hire a GNUstep developer to implement a missing feature than it would be to rewrite their codebase using a completely different toolkit.
Something like a climate model simulation is a much trickier question. One group is immediately obvious as a potential source of contributions: skeptics. Certain groups have a vested interest in demonstrating flaws in climate models, and finding bugs in the simulation is an easy way of doing that. This ready-made group has a vested interest in doing a thorough code review.