This article by Andy Lester has some key thoughts for those trying to get involved in open source collaboration but aren't sure about what they have to offer. The biggest thing I take away from it is that actually implementing hardware or software is only a small part of open source development - and is arguably far less important than investigating and thoroughly characterizing problems with a technology. These might be things the open source project is trying to solve, or bugs with its approach to solving the problem.

http://www.softwarequalityconnection.com/2012/03/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/

Lester also highlights the importance of good documentation, and of the kind of contributor who tests things out by following the existing documentation, and reports back in detail when things don't work. He writes:

I commonly hear people say that they’d love to contribute but can’t because of three reasons: * “I'm not a very good programmer.” * “I don't have much time to put into it.” * “I don't know what project to work on.” There are three core principles to remember as you look for opportunities to contribute: * Projects need contributions from everyone of all skills and levels of expertise. * The smallest of contributions is still more than none. * The best project to start working on is one that you use already. The most damaging idea that I’ve observed among open source newbies is that to contribute to open source, you have to be some sort of genius programmer. This is not true.