No, it's not.
If the code-base of projects you look at is too daunting, consider:
- Choosing a (even) smaller project to work with.
- Choose a smaller task within the project:
- Write an example/tutorial/demo for something
- Update and fix documentation (all projects, OS or no, need better docs)
- Fix many low-priority but easy to fix bugs (great exposure to code, devs are usually happy, low risk)
- There are ways to contribute without commit access to the core source, such as:
- Submitting patches, which can be commented on.
- Forking and submitting pull requests (see above)
- Forking and working away on your own, just to see where it takes you. If you're happy, ask the devs to take a look at whatever you've done to see if it makes sense.
To overcome your "fear" of not having your commits accepted, go for safe points at first. This will allow both you and the dev-team to gain confidence in your relation, and to learn each other's way of thinking. As you improve (both in skill, experience, code quality and understanding of your OS project's team and it's dynamics) you will be able to tackle greater task while introducing less hassle.
It also helps in asking for suitable starting points, and see what the team might find suitable for you.
As an example, I've contributed a bit to Buildbot over the years. I started just fixing a few small issues, then I bumped the quality of the Mercurial source steps by fixing some glaring bugs. Finally, I rewrote most of the Web-pages and swapped out html-pasting in code to a template based HTML generation solution. The latter was a few hundred commits over a few months of hard work.
I've also done some Mercurial work, but those guys are more picky and the technology is more complicated, so I haven't yet gotten any fixes into the core. I've made a few bug reports and written a few small extensions, but I haven't gotten anything bigger off there at the moment.
Hope it helps.