How to evaluate an open source project with joining in mind?

Question

Assuming I've found an open source project I'm interested in, how do I evaluate the project(the members, the activity level, etc) to determine if joining the project will be a good use of my time and energy?

Answer 1

Look at the source control history.

From that, you can see checkins, review code, gauge the activity level, and generally see the quality of commits. You can learn the most from just looking at the source code activity.

Answer 2

You can do several things:

1. Look at their mailing list archives, see how the community behaves in public
2. Look at the frequency of their releases and the quality of the release notes
3. Look for a clear mission statement and a list of features/requirements on their site
4. Check its maturity - if you're looking to be mentored/eased into a project then a mature project is more forgiving than a brand new project. The reverse is also true.
5. Look at the structure, is it a Benevolent Dictator or a community council approach
6. Look for their joining instructions, friendly? clear?

That's a start anyhow :)

Answer 3

Join if you will enjoy¹ working on the project.

---

¹: "enjoy" could mean whatever makes you happy.

Answer 4

Base it on your goals (not sure what they are). If you're trying to get programming experience, you don't realy have much to lose by trying it out. If anything, you may learn how 'not' to code.

If you're trying to make a name for yourself by attaching yourself to a great project, you may have a tougher time. Try searching the net for any blogs or comments from other developers and users of the software (If it is that far along.). Take a look at the coding progress. Is it moving along at a pace to your liking.

Trying to find out if the other members "play nice with others" may take a combination of some of the practices I just mentioned.

Try it out. "It don't cost nothin'" - John Belushi, Animal House.

Answer 5

Test the waters a little bit first. Hang out in the mailing lists, irc channels etc and watch how things work. Fix a bug or add a known requested feature yourself and submit a patch. See how it is accepted ... do they work with you to get it edited and included or fight you?

Also evaluate yourself. Do you really have the time and interest to stick around and be worth the project investing in getting you up to speed?

Answer 6

Look at the test coverage. Contributing to a project with a history/mandate of only accepting pull requests/patches with passing tests is going to be a much more successful and enjoyable process than trying to collaborate on something with developers who can't/won't write unit tests.

I've had to work on updating old versions of abandoned libraries a couple of times for work. Normally, I'd be excited to get paid to contribute to open source projects. But when there are no tests and poor documentation, it's just hellish.