Open source depends on intrinsic motivation with the same ferocity that older business models rely on extrinsic motivation, as several scholars have shown. MIT management professor Karim Lakhani and Boston Consulting Group consultant Bob Wolf surveyed 684 open-source developers, mostly in North America, about why they participated in these projects. Lakhani and Wolf uncovered a range of motives, but they found "that enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver." A large majority of programmers, the researchers discovered, reported that they frequently reached the state of optimal challenge called "flow." Likewise, three German economists found that what drives participants is "a set of predominantly intrinsic motives" - in particular, "the fun... of mastering the challenge of a given software problem" and the "desire to give a gift to the programmer community."
From Drive by Dan Pink.
Open source can do a lot for your programming career, or at least, a lot of programmers who've done well have participated a great deal in open source - which is not the same thing - so a lot of programmers participate in open source because it's good for their careers. This is a good idea, but it's not enough to produce great results in your career. There's a bit of a paradox: to make your open source contributions benefit your career, you need to find a reason for doing open source which goes beyond the benefit it brings to your career.
If you think about effort applied once, you judge its success or failure by the product it creates. If you think about effort applied over time on an ongoing basis, you judge its success or failure by the process it involves. The benefits from involving yourself in the open source process are (with very few exceptions) much, much greater than the benefits of creating any arbitrary open source product.
Open source devs have a saying: "Scratch your own itch." It represents the belief that you're going to write the best code when you solve your own problems, because the process becomes brief, honest, and immediate. The OOP and XP communities gave us an acronym, YAGNI, which is kind of a mirror image to "ccratch your own itch." YAGNI stands for "you ain't gonna need it" and represents the belief that if you can't prove for a fact that you need to make a given decision right now then you throw it out. Don't build the feature, don't prepare ahead of time, only solve the problems that are right in front of you.
YAGNI and "scratch your own itch" don't just keep code clean, elegant, and succinct, they also keep it honest. The worst code you will ever encounter in your career will contain program logic which does something completely different than it claims to, either in its comments or its method, variable, and object names. Programmers spend more time talking about good and evil than priests or preachers do. The reason is simple: bad code is nothing but lies.
If you go into a project determined to write some open source code because it's a vital requirement for your career, the moralizing which comes with programming will combine with that seriousness and turn you into a royal Puritan asshole. So you have to make your open source code fun. What happens if you don't have an itch to scratch? You find a toy to play with. Don't find a job to do; that's not how it works.
There's another reason, too. If you're starting out writing open source, then by definition, you haven't yet established a habit of writing open source. As an experiment, try to create two habits: a habit to do something serious every morning, and a habit to do something fun every evening. With the first, you face an uphill battle, but not with the second. The best way to learn something is to make it fun.