You don't "learn how to create my first fully working project" "through open sources", or indeed by looking at any type of existing project.
You learn by doing, and an existing project never tells you why it is the way it is: what options could nave been used, but weren't - and why they weren't! And those "didn't do's" are the most important part.
In overview, a project is pretty simple:
1) Design brief.
2) Specification and test criteria
3) Design documents
And any part of that can cause a recycle to earlier parts for changes, and very, very often does. For example, you will go round 4, 5, and 6 many, many times in a single project evolution - and will often go back to 3, or even 2 - and occasionally to 1!
So give it a try, come up with an idea that you might be interested in implementing, and sketch out what you want it to do - that's the design brief.
Flesh that out with details of how the user interacts with it, and how it interacts with other systems such as Database, etc.; decide what will qualify it as "done". That's your specification and test criteria.
Use that to work out your overall design: classes, structures, interactions, layers, ... That's your design documentation
Then start coding, testing that code, and making sure it works!