Slashdot Mirror
Recruiting Help for Open Source Projects?
AsparagusChallenge asks: "Let's say that I do have an open source project. I've setup a CVS on SourceForge, made release announcements on freshmeat, placed a nice webpage and a message board to discuss CVS commits. That said, what's the best way to attract talented people to help with development? I'd like to hear comments from people that have started their own projects and have got more people to work with them. What are the best channels to find volunteers, how to ask for testers, forming a team and so on. Note that I'm not advertising my project; what I'm asking for are general hints."
and people will come
...that sourceforge has a "Project Help Wanted" forum, right?
It's 10 PM. Do you know if you're un-American?
If you really want to attract talented people to your project, do some significant work yourself upfront. Get something usable (or at least a proof of concept) working. OSS developers don't want to work on something that they can't be sure will ever come to fruition. How many projects on sourceforge are in "planning" or never come out of alpha?
reech bee-yond ur clip-0n
First, have some code that does something. Anything. A design document is not enough.
.sig.
Second, post at the 'help wanted' pages on Sourceforge.
Three, make sure your project isn't another 'me too' id3 tag generator. Do something original, or go help on an older project.
Four, Usenet. Go to brewnix.sourceforge.net For a time, I was running this project (but I have no skillz, so had to rely too much on others). I went to all of the Usenet groups appropriate to this project and made an announcement. Really make sure they are appropriate newsgroups. Largely, only geeks still use Usenet, so there are likely some programmers in the appropriate groups.
Finally, go ahead and tell us what your project is. There are at least one or two programmers on Slashdot. Oh, and put a reference/link to it in your
Jesus was all right but his disciples were thick and ordinary. -John Lennon
most developers are attracted to a project because:
1) They think it is cool
and/or
2) They need it themselves
Other than that, you might night to provide some sort of external motivator such as money, hacker respect, networking oppotunity, etc...
Let's say your making a linux game. Head over to the linux gaming community, there will be people there who are linux gamers, and also coders!
If you're making say a media player for windows, find a community of people who are looking for an alternate media player for windows.
No matter what your project is there is someone out there who will work on it.
I'm a perfect example. I know how to code, but I'm not involved in any OSS projects. Not because I don't want to and not because I can't. I'm not involved because I'm not actively seeking a project to work on. But if someone came up to me and asked "hey, I saw you in that forum/irc/newsgroup talking about XYZ. You know how to code? cause I got this cool project!" I would probably contribute something to them. Even if it was like a single file of code.
The GeekNights podcast is going strong. Listen!
This may require a bit of creativity. If you're going to create some sort of stand-alone web server middleware thing, then you need to find the coolest, most unusual aspect of the final design, and implement it inside of Apache, with an eye towards making the code translate easily back to your eventual own server. If you're making a new widget set, you might write a few widgets of your own, but display them inside of a GTK window until you have your own window class. This principle doesn't necessarily mean you need the whole final system in skeleton form (though that's better if you can get it), but you need something that shows you're both serious and capable, which sets you apart from the riff-raff.
If you are looking for programmers, you must make it relatively easy to add functionality. That means a careful design with strongly seperated concerns is vital. If nobody can pick up your program and twiddle a line without the whole house of cards coming down, nobody will bother with it. If you're looking for graphics help, you'll need to make it easy to add (or change the) graphics in the program without knowing how to use the compiler. If you're looking for documentation help, it must be easy to document the program. (Pick the doc standard, make it easy to add help to the program without knowing how to use the compiler.) Ideally, for all of these, you should include a tutorial of some kind; how to create a plug-in from scratch, a step-by-step guide to changing the title screen's font (hopefully not too many steps, the act of writing the guide will show you what to make easier!), a step-by-step guide on adding help.
It's not so much the obvious "the easier it is, the more likely it is someone will do it", though that's trye. It's more of a gambling payoff thing; you need your contributors to be able to sit down with your product and experience a "payoff" in the form of an actual improvement as quickly as possible, so that they'll keep working on it.
- Programmers. Docs for this bunch means well-formatted and commented code (documenting anything not obvious to someone on first glance), and for any non-trivial project, some sort of overview of the design, ideally detailed enough that someone can read the overview, pick up any source code file, and (in conjunction with the comments) figure out where that source fits into the project as a whole. It probably also means some sort of coding standard for code submitted back to you.
- Documenters: You'll need an overview of what the program is, and probably a skeleton of the necessary docs.
- Testers: If you have a testing framework, document it. What, you don't? Get one. Document things that have been problem spots (bugs keep re-appearing), so they can be scrutinized. Make a release checklist.
Already described some of the docs the artists and such need.Note that you only need docs for the groups of people you are trying to attract. In the early phases of an open-source project, you may neither need nor even necessarily want end users. In that case, no need to write docs for them (or at least don't make them public). The only docs the end-users need is "This program is not ready for end-users. Please check back later to see if it's usable.", changed appropriately as you start to need actual beta-testers and stuff. It is a serious mistake for a project to attract end-users before the project is ready, as the users will sap away development time with support needs, with no infrastructure/community to support them.
Certainly there are successful projects that haven't done some of these things, but I think that's success in spite of bad planning, not because of it.
Everything boils down to it must be easy to contribute. The number of projects out there bitching because nobody is willing to program for them, when the leader can't be bothered to even format the code decently, let alone comment the code, provide a blue-print for the design, or even have a design in the first place, boggles my mind. It's like the usability folks have found... every barrier to entry knocks away a percentage of people, and any you can remove helps. Even if a hypothetical wizard coder in the language your project is written in can understand your code by reading it for three or four hours and getting the Big Picture, doesn't mean they aren't more likely to join your project if there's a document they can read that gives them the Big Picture in five minutes (leaving them that much more time to actually contribute, or learn something else), for instance, and that goes for everything.
Too many projects make the mistake of expecting the contributors to jump through hoops to contribute, instead of making it easy. I think it's part of the Open Source hubris that we see so much of. Don't fall victim to it.
>>>Make a really good product...
:)
:)
.deb packages correctly, building a user interface, and that's just what I've found until now. I don't think that the "lone programmer" paradigm will be enough for it.
I expect to be doing it
>>>Do you know that sourceforge has a "Project Help Wanted" forum, right?
Well, that's why was I asking. I'd like to hear experiences of other people with that kind of things.
>>>Get something usable (or at least a proof of concept) working
Working code ready.
>>>Four, Usenet.
That's something I still have to try, thanks.
>>>go ahead and tell us what your project is
https://sourceforge.net/projects/elcad/
Please don't slashdot my poor homepage
I didn't want to appear as simply promoting, but thanks for asking.
>>>I think one of the reasons that people build open source projects is to prove themselves
I have high expectations about that project, and can't find the time for fixing autoconf, setting
I suspect that I got lucky because my project has the magic term 'mp3' in it's title.
What I did was to start my project, post it to Freshmeat and SourceForge and make regular releases when new functionality was added - this is necessary to make your project known to random people.
All the time I was developing I was answering emails from users who needed help installing, or tweaking things, and that got fed back into future releases.
After a few releases it was getting obvious that one or two users were being helpful above and beyound that which I'd expect from a random user. These users were sending patches, playing around with the software in interesting new ways, and asking for very specific features which would be useful to other people - but which I'd not considered at all.
These were the people that ended up getting write access to my CVS repository, and these are now "my little helpers".
All of this happened naturally, the only things I really did were to publicise the project itself in my Advogato diary, freshmeat, and online. If people want software you want to make them find yours - then you want to have something which works well enough for them to use it. If people have a hard time using/installing/understanding your project they'll give up on it very quickly. (Sometimes they'll even refuse to use it again; thinking "Oh I tried that once - it sucked")
Finally I always asked for help on my projects page - making it clear to visitors that I'd be extremely greatful to recieve code, logos, themes, documentation, and suggestions from users. 99% of people won't give you anything - but the 1% really makes a big difference.
Three suggestions I'd make to writers of any new software:
Finally I guess this is a good point to say thank you to all the people that spared the time to contribute to my project - your contributions are much appreciated :)