Slashdot Mirror
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?"
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.
Stephan
http://stephan.sugarmotor.org
The last time I messed with it it was pretty straightforward. Is it somehow more complicated now than "type in some name/version info for the release, upload a source tarball"?
Well, that and free web hosting for the project site.
-- The act of censorship is always worse than whatever is being censored. Always.
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...
http://savannah.gnu.org/
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
ReleaseForge takes away some of the pain.
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.
> You could also ask the university to finance a developer for this specific
> issue, or maybe put a professor with a clue on the job.
Universities don't work that way. If you want one of the profs to assist you, you must engage his interest (Which may be very possible. You might also get a prof to assign you a grad student).
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
wrong on almost every count I'm afraid.
google hosting (mostly but not all)
How much more open then five years under the GPL can I be.
Yes I want someone to share the project, but employ and reimburse? I think you miss the point. I want to find ways of finding people who would want to join in.
Volunteering means they get to choose what they do, not me.
A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
It's GPLv2.
c++;
Karl Fogel is somebody who has worked on several successful open-source projects. He wrote an excellent book called Producing Open Source Software: How to Run a Successful Free Software Project. I recommend that you read the book. You can buy paperback copy from, say, Amazon. Alternatively, if you use a search engine then you can easily find free PDF or online HTML versions. Regards, Ciaran.
But without knowing what your project is, it is hard to know what you are doing wrong. Because you probably are doing something wrong if your project is generally useful but noone is willing to help. I also run an open source project (on a really slow site so no link :)) and have gotten quite a lot of code contributions from other people. Here are some tips on what I did to try and attract people. Take it with a grain of salt, I know nothing about nBody modelling.
Presentation is everything! If you can't convey interest to a potential contributor in less than two minutes after they have visited your site for the first time, then you have lost. You need to present your project in the most favorable way possible. You need to show me why I would want to use your code, why I would want to choose your modelling package over any of the hundreds of alternatives. I found no screenshots, no API documentation or tutorials during the ten minutes i spent browsing your project. Just a lot of text. Boooring!
In the same vein as above, you need top quality documentation. And it needs to be very visible. Preferably a front page link. One reason why the parser generator Bison is so popular is because it includes a detailed introduction to language parsing in general. So if you want your toolkit to be popular a good idea is to include an easy introduction to nBody modelling.
Present what your project is capable of doing, or what tasks it is supposed to solve. Can i write a space flight simulator using your library? Can I write a Python wrapper? I don't know.
If I get seriously interested in nBody modelling then I'm likely to want to contact you with questions about the code, bug reports and patches. But your email address isn't available. I know you have an issue tracker but that is no substitute for email. New people often perfer personal communication.
One thing I noticed is that you are using CMake for building, which is cool. But most people aren't as used to CMake as to autotools and make so you need to provide explicit and complete instructions for building your project. It is little details like that that makes your project much more appealing for potential developers.
And last (because it is not so important), use dependencies. For example, if you can use the hash table implementation in glib instead of writing your own. Then do so! You might be able to write a good hash table in less than 400 lines, but by using glib's hash table you just saved yourself from maintaining 400 extra lines of code. There are probably both particle and linear algebra packages you could depend on to make the burden of maintaining your code easier for you.
Football Odds
I'm in similar situation (1 developer, several years old project, about 1000 downloads/monts). I got accepted into GSOC one year ago and had two students. I didn't have any applications from students who need and use my program, so I couldn't expect the students to stick with the project after the end of GSOC.
It takes time to mentor students, and if students don't know the code and aren't really experienced, 3 months of their work won't make a real difference to your project.
The 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.