One trick, if you’re having trouble coming up with something, is to think beyond yourself as an individual and to the larger groups we fit in. What do you and your spouse need? What does your team at work need? What does your need?

It’s often easier to do that than just to look at your direct itches, and it’s a better fit into open source.

—

The problem with ‘what project pisses you off the most’ as an approach to finding an itch is that it isn’t new work; your tiny involvement isn’t going to stop it pissing you off, though you may understand why it pisses you off better; and an unhappy relationship with your first project seems the best way to turn you into an open source arsehole.

It might be more constructive to think about a project you like which has a half-baked feature. Or inconvenient bugs. Start digging into it and figure out how to build it – blog that info if it’s at all non-simple. Build fixes are a very easy way to start rolling the patches in.

Hunt and read the documentation, patch it if need be, but don’t focus on being a documentation creator as most projects aren’t setup to embrace documentation patches the way they embrace code patches, and the curve from beginner to expert is much steeper with docs.

Use issue trackers for your patches, not mailing lists. Mail goes stale within a week at the most; issues last years.

Talk to the project. Best bet is to find an IRC channel and start lurking. That’s a great way to ask those early awkward questions (”Dumb question, but…?”). Then move to the mailing list/issue tracker as the discussion becomes more authoritative on your part (”Okay, I’ll go ahead and redo that…”).

*end transmission…. child awake*