Recruiting Help for Open Source Projects? 35
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."
Make a really good product (Score:4, Insightful)
Open Source Development HOWTO (Score:2, Interesting)
Re:Open Source Development HOWTO (Score:1)
Re:Make a really good product (Score:2)
So, the best way to make a very good product is to have very good developers onboard, and the best way to get them onboard is to lure them with a very good product
There's two other ways. 1) do it yourself. 2) pay them.
You do know... (Score:3, Insightful)
Why not.. (Score:2)
Make some strides yourself (Score:3, Informative)
Re:Make some strides yourself (Score:5, Interesting)
Development Status
- Planning (10899 projects) [28%]
- Pre-Alpha (7314 projects) [18%]
- Alpha (6611 projects) [17%]
- Beta (7936 projects) [20%]
- Production/Stable (6062 projects) [15%]
- Mature (641 projects) [2%]
- Inactive (80 projects) [0.2%]
Percentages rounded up to nearest whole percentage (apart from the lastI'd say those stats weren't too bad...
The classical way (Score:2, Insightful)
Do it yourself (Score:1)
So my advice would be to work on something until it's done enough to do something useful. Then those who want to help will do so. You'll be free to reject what you don't like with the excuse that it doesn't fit into the program. When they complain you can point out that you've written the entire thing.
And people who just like to give advice without submitting any code should be told to write some code or STFU.
Harsh, I know. But users are a huge pain, and unless you want to spend all your time managing, you've got to kick all the other cooks out of the kitchen.
Ditto (Score:3, Interesting)
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
2 things (Score:4, Insightful)
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...
Don't Re-invent the wheel. (Score:5, Insightful)
Help not wanted (Score:1)
I think one of the reasons that people build open source projects is to prove themselves. The programmers want to be able show someone (a possible employer) what they have done.
(Although employers most likely want someone who can work with a team more than a "Lone Ranger")
Depends what you're making (Score:3, Insightful)
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.
Slashdot (Score:1)
use net news groups (Score:1)
All theory, but... (Score:5, Insightful)
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.
Thank you everybody (Score:4, Informative)
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
Thanks for not posting a link (Score:1)
Here's how it was for me. (Score:3, Informative)
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 [advogato.org] 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 :)
Re:Here's how it was for me. (Score:1)
Make sure your prototype is QUALITY code (Score:2, Insightful)
This will make it much easier for new developers to make positive contributions once they do join; that will make them much more likely to stick around. I have seen projects where the code was a mess; who the heck wants to join a team and have to spend most of your time untangling spaghetti or figuring out "what in hell was he doing here"?
The only proven way is offering money. (Score:2, Informative)
Generally, lack of contributors shouldn't be a concern - if it is, then the scope of your project is too big. Keep your scope narrow and goals simple (work on the assumption that you will never get any contributors other than yourself), focus on perfection rather than size or time, and your project will be successful.
A Few Ideas... (Score:1)
If most of the end-users -aren't- necessarily
programmers, they may have a presence outside
OSS circles (newsgroups, eGroup conferences,
mailing lists, or even meetings at phys. venues,
if you have time to travel).
Join the most populated ones, or those most
open to your presence &/or input.
Of course, not all groups welcome geeks,
for some reason; I include here both:
- groups with more luddites than technology-
friendly folks at the helm, and
- groups that have grown up around a com-
mercial product, eg sold at near-zero
cost by a one-person development firm
The latter comes -close- to the Open Source
model, since the developer gets -lots- of
user-feedback, but holds tight onto the
source-code (often with no succession plan
in case of the principle's untimely death).
In each case, one -might- even have to hide
one's open source orientation, eg in order
to get more detailed or complete feedback
from the user community, who may have been
"trained" (eg by the "worshipped" developer)
to shun open source advocates, as if they
were missionaries.
Even those who see benefit in OSS models
are likely to remain silent in such groups,
ie in order to ensure continued support
from the non-OSS developer.
We've set up an alternative eGroup & project
& continued to drop bread-crumbs leading to
these, for the benefit of open-minded members
of the non-OSS groups/lists.
"Softly, softly... catchy monkey"
You have to write code! (Score:2)
If you have no talent yourself, forget about attracting those who do in order to assemble a project out of nothing. You can't do that with an empty web site; the usual custom is to start a software company, get some VC, and pay people.
Isn't any of this obvious? But then if you had any brains, you would not ``Ask Slashdot''.
Re:You have to write code! (Score:1)
And at risk of sounding presumptuous, I DO have talent of my own
Open Software Job Bank (Score:1)
talented people (Score:1)
try a LFSP [paulgraham.com]