Recruitment Options For a Small-Scale FOSS Project?
thermian writes "I've been developing my open source project for several years now, and I've never found a solution to one fairly important issue. How can a small-scale project attract new members? My project is pretty specialist, (no URL, sorry, I can't afford to get my server nuked) and I find that while it gets a fair bit of use, most users come to my software out of a need to solve their problem, or use my tutorials to learn about the subject, and none seem inclined to stick around and help make the product better. This is a fairly serious problem for me now, because my software has recently been adopted by a university, and I'm just not in a position to manage the entire set of applications and update everything on my own. Just preparing a version for release to students has been especially hard. The open source maxim 'Many eyes make all bugs shallow' only works if those 'many eyes' are available. So do you have any suggestions as to how, and where, to find people who fancy joining open source projects?"
Suggestion: post your project name.
The secret to creativity is knowing how to hide your sources. - Albert Einstein
It only takes one man to change the Wisdom of the Crowd to Tyranny of the Masses.
Every once in a while on linuxquestions.org someone will ask where they can help out. Might be a good place to start.
Just a guess ?
. waterwingz
You can't really "recruit" FOSS developers. They'll join if they find your project and find it interesting enough. The best thing you can do is increase exposure. So why, when you managed to get a story posted to /., did you decide to hide what the project is? You had the perfect opportunity to expose thousands of developers to your project and you decided not to take that opportunity. Bad move.
It's really difficult to give advice without knowing the specifics. For instance, you might have luck adding a plugin system, so that the barrier to entry is low enough for more people to join in without feeling like they have to become a proper developer. But that only works for some types of application.
Bogtha Bogtha Bogtha
You may also consider adjusting the amount of time you have to devote to various tasks to increase the amount of time you spend cultivating the ecosystem. For example, if you spend 70% of your time coding, 20% managing documentation / the web site / etc., and 10% of your time with PR, answering user e-mails, reaching out to users, etc., try upping the 10% to 20% or more. Linus' coding chops were only one part of why we've all heard of Linux.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
Not publicizing the project name suggests you're either guarded with the project... and if you're concerned about the bandwidth, you're probably self-hosting, which means you're probably not on SF.net, Berlios, etc... which in itself suggests you're not as open as you'd like to think you are. Also, it sounds like you want someone specifically to share the workload, but you didn't mention any form of reimbursement. Nobody who's any good will volunteer to be your employee. If you want an employee you have to pay, and if you want a partner you have to share. At first glance, it doesn't look like there's much of either going on.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
I have this exact same problem with two of my open source PHP projects. No give, all take. It's been like this for years despite my best efforts to motivate people.
I have a few developers on one project that have never really contributed anything too, I have tried several methods in motivating them but all I get is the one liner commited from them and then nothing for years.
I wish I had an answer to this problem, but I don't think there is one. Everyone is interested in the popular projects and the rest are left out.
Why did the OP not link to that page? Surely Google can handle a little slashdotting! For those who don't want to follow the link -
The nMod nBody Modelling Toolkit provides software to run experiments in the field of nBody modelling on a normal home computer.
This means modelling asteroid/comet motion, spacecraft flight, planetary systems, or stellar cluster/small galaxy systems.
The toolkit contains a Particle Particle nBody model, an OpenGL viewer to display the output of the nBody model, and a number of utilities for generating new projects and editing existing output files.
If you really want people to jump onboard with your project, then you need to publicise it. No point complaining that nobody helps if folks have never heard of it.
Awful UID - but I have been here ages...
For some people shameless self-promotion feels very sleazy. Apart from that, not everyone looking for help on their project is going to get a story on Slashdot. His question was probably accepted because it was legit and not just an attempt to tap /. for talent.
If he would have included info about the project there would have been a dozen +5 Funny post that said: "Well for starters you could try posting on /. harharhar."
Personally I find this question interesting an I think it warrants more than "post the link".
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
Get accepted into the Google Summer of Code!
... and very exciting to see the increase in developer interest!
It's becoming increasingly more competitive for organizations to become accepted as the program continues to evolve, but any established project with a vibrant user community has the potential to get accepted. Once accepted, Google basically provides an incentive for students to become involved with a project's development by seeding them with a summer stipend. It's a little more involved than that, but that's the gist.
This is the first year BRL-CAD gets to participate and I can already say it's looking to be a lot of fun. It forces a project to organize, coordinate, market, and communicate more. It's a lot of work but well worth it
Cheers!
Sean
If you have a user list then quite often a plea for programmers/testers will achieve results. I have done this a few times for my major project and it has always worked.
I also disagree wiht parent that you should have posted the url on slashdot. You would have been slashdotted, for sure, the chances of finding interested developers is low. Most would have just been idle browsers.
A post on your own user list is far more likely to give results since the users have a vested interest in the software and are far more likely to be open to being "recruited".
Engineering is the art of compromise.
Suppose your user base where bigger. Say 100k users. Or 10 million. Could anyone still expect you to help out anyone of those users? Ofcourse not, and in that case these 10M users would be forced to help themselves (to some degree) anyway. The same goes for a university that decides to add X students to your userbase.
Probably it's more a question of why you are working on the project, and what you get from that. Set your own priorities, decide how much time you want to invest, and go from there.
May I suggest you ask the university to do some inhouse filtering of issues/questions (eg. using a local webpage / contact person), and give you a regularly updated 'top 10' list of what they consider most urgent/important.
- If you want to support the widest possible userbase, then you might work on those issues that *also* affect other users of your project.
- If you put this university first, then you could work their list from the top down.
- If you're just doing it for fun, you could cherrypick from their list whatever issue seems most interesting.
--Do only what only you can do. -Edsger Wybe Dijkstra
I have tried and failed to help out on some open-source projects in the past, eventually abandoning them because I couldn't figure out the basics. I'm a pretty good mostly-C programmer with a smattering of other languages, and most of my experience is in embedded systems.
Here are some questions to which it should be easy to find answers:
1. How do I get the code?
1a. Where is the repository, and what type (cvs, svn...)?
1b. What branch/version should I check out?
1c. What external projects/libraries/etc. does it depend on, and how do I get them, and which versions of them do I need? (If allowed by the license, consider hosting a version with your source for one-stop shopping.)
1d. Ideally put this in a step-by-step "for dummies" set of instructions on your project's web page. Or you could make available a script to run that does it all for you - but well-documented so I can figure out what the script is doing and why. Oh, and make sure it works for you if you follow it exactly on a virgin machine!
2. How do I build it?
2a. What language(s) is the source written in?
2b. What compiler(s)/build system(s) do I need, and where do I get them?
2c. Where are the makefile(s)/build files etc. and what does each of them build, exactly?
2d. See 1d.
3. How do I run/use it, and where is the target(s) (executable, shared lib, whatever...) that was built?
4. How can I get help if I need it?
4a. IRC chat is useful, but if most of the developers are on the other side of the world, it would be nice to also have a mailing list to which to post so I don't have to stay up all night. Preferably a mailing list that allows attachments for error output or screenshots.
4b. Ideally your FAQ should actually be made up of questions people have actually asked, especially if they are asked frequently. FAQs rarely do this for some reason - I've often seen the same question asked over and over in help forums, and never answered.
4c. Answer the questions people are asking. Even if the answer is "if you can't figure this out, you don't belong here" - try to phrase that as nicely as you can.
5. What is your process for managing versions and how/when they are changed in your repository?
5a. If you allow checkins of incomplete code, how do I know if I've found a real bug that I should fix, versus something that will be "fixed" when the person working on the feature checks in the rest of it?
I've had trouble finding these answers on small, big, and really big projects.
Those are the ones I can remember having trouble with right now. If you think the answers to these should be obvious, you are looking for programmers who either have experience in all the tools you are using, or who are smarter than me. Which is alright, but either way, it would be nice of you to at least put down a list of required skills and experience, so I don't waste my time trying to help and then give up in frustration.
Thanks for letting me vent.
I'm sorry to word this so aggressively, but what the hell are you doing? Open Source does not mean "I am free labor for everyone." Nor does it mean, "I am a doormat, please walk all over me."
Listen, I'm no Linux kernel developer. I'm a poetry guy who was looking for a cheap way to get my poems out in front of eyeballs back in 1994, and coincidentally the Web had just appeared. So I'm only a long-time Web geek at best. And maybe that's not the kind of experience that some would respect. But I've put out probably 100 Open Source products in that time -- 50 phpBB mods, 10 Greasemonkey scripts, 5 Movable Type plugins, and a handful of awful, awful old scripts that nobody should ever use. I'm a father of two with a full-time job, and I've have had 15 year-olds tell me they couldn't be bothered to read the readme, because their time is more valuable than my own. I've had people come to my forums, stomp their virtual feet, and demand that I support them for free in much better fashion. After all, they ask, why did I release a product if I don't intend to add their feature requests and do the installations for them?
Listen, their agendas are not your agendas. Their timetables are not your timetables. And most most MOST importantly, your job is not to be their serving wench. It's not a job at all! Get it straight in your head what you are doing this for. I can't tell you why you do it, but making yourself so stressed out that you have to post on Slashdot begging for help (but not giving out your project name, so you can be an even bigger martyr when it all goes south) IS NOT THE REASON.
You know what I do? I say yes if I can, maybe if maybe, and no if I cannot. And I mean it. Don't make it more than that. Stop feeling obligated. And if you made promises that do obligate you in ways that you cannot meet, it's not the end of the world, but get back to the table and renegotiate. If people blackmail you with statements like "I guess I need another product" or "YOU put it out there, YOU DO IT" then just put that burden right to the side. I don't get bothered that someone might uninstall the app. They're cutting their losses (their lost time) and in the process they cut my losses (of time invested in someone who cannot help himself or herself) too. If you say you cannot build a feature and someone complains, tell them to build it. Seriously. Don't be mean, don't be vindictive, don't be snide. Mean it. If you are stressed and this isn't even your paying job, then draw lines and see who comes to your side. If they don't, then it didn't really matter to them. In which case, you're free to work on what matters to you, in a way that is healthy and sane.
My Greasemonkey scripts for Digg &
When someone reports a bug, rather than fix the bug, guide them on how to fix the bug. Maintain a developer forum and direct users to post bugs over there. (I bet you aren't doing this.) Even if you end up practically fixing the bug yourself, share the credit with the guy you guided. Share the cred: in the end, that is the only currency of FOSS development.
Set up a wiki and encourage users to document. Use excerpts from forum discussions to build the wiki initially.
You have users for god's sake: that means whether you know it or not, you have a community. If they're nagging at you w/ requests, that means you already have a conversation going. Give them the tools and incentive (that means you stop fixing things alone) to contribute. Involve them. At the very least you can ask them to prioritize the feature requests.
Stop coding now. You're buried too deep to see the bigger picture. (I'm guessing, of course.)
Finally, have fun. If it's no longer fun, either make it fun, or stop doing it.
- writing better developer-level documentation
- providing a list of "starter projects"
- giving talks and webinars about Amanda's internals
- rewriting parts of the application in a more accessible language (Perl)
- making myself highly available for answers and advice
I've tried to increase investment byThe first most important point is to write an already worthwhile program: it has to be able to offer completely new and innovative, or perform the competition's function with improvements for a certain user-base. The second most important thing is to get other "developers" (a very broad definition, since anybody from university students trough application programmer to hobbyists interested in your project could be capable of adding some useful code and look through parts of the source, which they will do in order to sufficiently understand the organization of your project, sorry for this unbelievably long parenthesis) to get interested in solving a problem or adding a function to your project. The motivation factors could be various: maybe they absolutely need an added function in your program to accomplish the task they intend to use it for and the effort needed to write something similar from scratch would be larger then extending the already existing code-base, or maybe your application is already works very well for them but they miss useful additional features, better ease of use or want to eliminate a certain bug.
In order to augment attraction of potential developers you have to offer improved accessibility to your project (nicely formatted and documented source code, a doxygen-like online source tree with additional comments, an up-to-date FAQ and maybe even a short "manual" which concisely explains the manner in which you've laid out your project.
Once somebody has implemented his own creation into your project, you've got a bite. Now you have to make it as convenient as possible for him to share his modification (a visible "submit modifications" section of your website, encouragements to submit personal additions on the "contact" section, etc. If he satisfies your current code standard can add his modifications into your next release, contact him with thanks, hints and your own take on the modification and its future.
When the new "co-developer" has the impression of being able to contribute something useful and appreciated to the project, and if he accepts the direction you are heading and the guidelines you provide, the relation can flourish.
Of course, not every contributer will turn out to be a long-lasting co-developer and friend (also, forks happen), but you have to offer optimal conditions if you want to further the probability.