Best option is actually to get a job where you'll be working with other senior programmers and then understand your company's source code. That's how I did it - my first job had Ken Arnold as the CTO, then when I got to Google I'd lurk on Jeff Dean or Rob Pike's code reviews (everything is public internally at Google, you can see what everyone's working on). The big advantage of this is that you understand the business context behind the code; it's really hard to understand code in isolation without understanding the purpose behind the code and the goals for which it was written. A secondary advantage is that you've got ready-made mentors.

If you can't get a job and need to go the open-source route, then Rust, Chromium, V8, Django, and the Linux Kernel are all good options. Again, the guiding principle is to pick software where you're familiar with the outside, so you have context when you go look at the inside. Reading software in isolation is hard, so you're often best off volunteering to fix a couple low-priority bugs on the bug queue, and then diving in to start with them. Existing volunteers will often point you to the right spot in the code to get started if you're doing productive work for them.