If those are the hurdles one sees, I'd suggest starting by contributing documentation. It's welcome help in almost all cases, since it's something the people th

If those are the hurdles one sees, I'd suggest starting by contributing documentation. It's welcome help in almost all cases, since it's something the people that do know the problem domain in and out often have too little time, and too little need for. Also, as someone who is not yet fully emerged you're in the perfect position to design documentation from the point of a user who isn't familiar with the code base. It usually also consists of small jobs (fixing documentation, keeping it up to date, making sure documented behavior is tested) and bigger projects (tutorials, cookbooks, main manuals). So it's possible to start out small and work your way up. From documentation you can go to testing and code cleanup contributions (X needs a better error message, Y is not the way library L says you should do it anymore) and then, depending on the project, on to larger tasks.