Slashdot Mirror

← Back to Stories (view on slashdot.org)

Recruiting Help for Open Source Projects?

Posted by Cliff on from the opensouce-wants-YOU dept.

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."

3 of 35 comments (clear)

  1. Re:Make some strides yourself by Malcolm+MacArthur · · Score: 5, Interesting
    Stats for reference:
    Development Status

    1. Planning (10899 projects) [28%]
    2. Pre-Alpha (7314 projects) [18%]
    3. Alpha (6611 projects) [17%]
    4. Beta (7936 projects) [20%]
    5. Production/Stable (6062 projects) [15%]
    6. Mature (641 projects) [2%]
    7. Inactive (80 projects) [0.2%]
    Percentages rounded up to nearest whole percentage (apart from the last :).

    I'd say those stats weren't too bad...

  2. Don't Re-invent the wheel. by gaudior · · Score: 5, Insightful
    Are you sure you need to do this project? Is there another project already started somewhere that you could make significant contributions to?

  3. All theory, but... by Jerf · · Score: 5, Insightful
    This is all theory because I don't run an Open Source project myself yet, but I have something that I want to be a successful open source project someday. So I've spent a lot of time thinking about this, and also looking around at what is successful, and these are my thoughts:
    • Have a solid proof-of-concept implementation. You must, on your own, produce something that is usable, by which I mean "can actually do something useful better then anything else", not just "it executes without crashing". Until you have this, you will not be able to attract serious help of any kind. This is easily the hardest hurdle to jump in getting an open source project going. In my case, I've been working on mine for six months and I've probably got another six months to go before I can successfully jump this. But if I released what I have now, it would almost certainly get just a "so-what?" reaction from anybody who took the time to download it.

      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.
    • It must be easy to do the kind of work you are looking for people to do. That's a general principle that must be specialized to whatever it is you are looking for.

      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.
    • Documentation, damn it! The bastard step-child of Open Source projects. Look, the fact is, anything you want people to do early on is going to require documentation. Maybe you're final product will be so easy to use that nobody will need docs (usually because you're doing Yet-Another-(something) that we all know how to use, like a GUI word processor or something), but to get the project off the ground, you need docs for all of your target users. To an open source development leader, "users" aren't just the people running the program to get work done, those are special users called "end-users". You also have:
      • 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.
    • A solid design. I want to mention this explicitly, though it's already strongly hinted at in what programmers need. You need to start with a strong design for the program, because it is likely that the initial design will be in place for a long time. If it sucks, it could even kill a project that would otherwise be very successful. If it's OO, learn what OO means and how to do good OO design, same for any other paradigm you might want to use. The problem is that no contributor, no matter how good, will want to completely rearchitect any project, because they won't know it as well as you and they won't know what will bite them. (In fact, for my project, there are in theory other Open Source projects I could have at least started with, but the designs sucked so horribly they were unsalavagable.) I'm not certain, but it seems like one of my favorite Open Source projects, LyX, has been bogged down the last two or three years trying to re-architect the program into something that can grow again, more-or-less treading water in the meantime (and re-organizing the damn menus every release... but that's another story...). While you're at it, make sure you include hooks for everything that you determined you need, like documentation places and suck.

    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.