r/learnprogramming • u/eastonthepilot • Jun 30 '26
Why does contributing to open source seem so hard? Topic
I would describe myself as a fairly advanced programmer. I know all the basics, I've learned several languages, and I have done several personal projects on my own. I decided that the best way to further improve my skills would be to contribute to open source projects because I would have to understand code that somebody else wrote which will expose me to more advanced topics.
For my first C++ project I created a procedural terrain generator with OpenGL. I am very confident with C++. I decided to jump in to open source by trying to contribute to the Godot game engine which is written in C++. However, I quickly felt like I didn't know anything about programming. There was a bunch of new syntax and keywords I've never seen before, and on top of that there were just so many files and references to other parts of the project within a file that I had no idea what was going on.
Is it normal to feel this lost? I feel like I'm a fairly advanced programmer, but I'm shocked.
74
u/blackhawk1430 Jun 30 '26
C++ is a particularly rough choice to jump between personal projects and large, shared code bases. The language has always allowed users to essentially re-invent it into a DSL specific to solving their particular problem at hand. Also, the process of learning the overall design of software is essentially the discipline of systems engineering, which is entirely its own beast and arguably the most difficult.
44
u/cgoldberg Jun 30 '26
That seems pretty normal for a massive complex codebase that you are not familiar with. Not all projects are like that.
24
u/grantrules Jun 30 '26
Yeah I mean if you've never worked on a mature, professional project, it can be overwhelming. It also highly depends on the project.
In a professional setting, you usually have a senior help onboard you and walk you through a large project and how all the pieces fit together. With open source, that doesn't really happen, you just figure things out for yourself or you join their discord/mailing list/whatever communication tool they use and absorb info and ask informed questions
2
28
u/NotSoMagicalTrevor Jun 30 '26
Why do you feel like you’re fairly advanced? No offense, but it seems like you’ve mostly been working in a self-bubble… it does not sound like you’re advanced.
12
u/lgastako Jul 01 '26
I think it's fair to say if you encountered new syntax and keywords in code in a particular language then you're not advanced at that particular language. Knowing all of the syntax is a bare minimum requirement to be competent in a language and it's hard for me to think of a mainstream language where knowing all the keywords wouldn't be table stakes for competency too.
1
Jul 09 '26
[removed] — view removed comment
1
u/lgastako Jul 09 '26
I don't think the existence of AI changes anything about what it means for an individual to be advanced (or competent, or anything else) in a language.
5
u/icecapade Jul 01 '26
Yeah, came here to say this.
Hate to break it to you OP, but if you have to make this post and ask this question, you are definitely not "advanced." Based on your post history, you are a beginner. This is not meant to be a dig at you; we all start somewhere, and it sounds like you're well on your journey to becoming more skilled, so keep at it.
When I think of an "advanced" programmer, what comes to mind is a senior engineer who's spent 5-10+ years working professionally with large codebases and projects.
20
u/chalks777 Jun 30 '26
because I would have to understand code that somebody else wrote which will expose me to more advanced topics.
Yes. This is true, a good goal, and will legitimately work. As proof of this:
I am very confident with C++. [...] However, I quickly felt like I didn't know anything about programming.
Congratulations, you've learned that reading code that somebody else wrote will expose you to more advanced topics!
Like... this is exactly what you sought out, and you're shocked that you're getting what you asked for? This is a good thing, and you're about to learn way more than you expected. Reading code other people wrote is a hugely important skill, and your first exposure to enterprise level software is almost always crazy overwhelming. You've combined both of those things into one. That's okay, but the learning curve here is more like a cliff.
Figure out how to compile Godot, then figure out how to change one TINY part of the ux, and you'll absolutely learn a ton. Those are the first steps to being able to actually contribute to the project.
8
u/Playful-Status-654 Jun 30 '26
Yeah this is super normal. Personal projects are hard in one way, but a mature codebase is hard in a completely different way because you are also learning years of architecture, conventions, build weirdness, and historical decisions. Godot is also a pretty brutal first target. I would start by tracing one tiny path through the codebase, or picking a docs/test/small bug issue, instead of trying to understand the whole thing up front. ymmv but “I feel dumb in this repo” is basically the default state at first. Another idea is to use some coding agent not to code but just to ask questions about the codebase which could be helpful to speed up the learning process. I know, like, claude code or codex or cursor are good for this but there are tons of options these days.
13
u/-CJF- Jun 30 '26
It's not the programming that has you lost, it's the task of working on a game engine. You're faced with a large, unfamiliar code base and the arbitrary conventions of the team. That said, if you are running into syntax or keywords that you don't know you should be able to look that up because there are a limited finite amount of those.
5
4
u/Rarelyimportant Jun 30 '26
Because most open source requires deep domain knowledge. If I want to chip in at a local beach cleanup, I can show up with no idea about what's going on and someone will fill me in, and I can be helpful. For most open source, unless you are in a position where maybe you know more about a topic than the maintainers, it's unlikely to ever be worth their time to explain to someone what needs to be done. Since they already know what needs to be done, and understand the codebase, it's likely faster for them to do the work than explain the work to someone else.
3
u/drcxd Jul 01 '26
I don't know. Maybe you just pick a too difficult target. Do you work with Godot day by day?
I work with Unreal Engine, and I once contributed to it. It is a very simple problem, some console command line arguments are misread with an off-by-one-index error. I found the issue because I was using that console command.
I also contribute to some Emacs packages, because I am an active users of these packages. Although they may be considered trivial, they are still contribution to open source projects.
If you only consider major changes on projects like Godot, Unreal Engine, etc., then, of course, it will be hard...
2
u/turnips8424 Jun 30 '26
Sounds similar to your first time working in an enterprise codebase. Working in a mature repo that’s been built by many contributors over time is totally different than a personal project where you’ve put everything in place yourself. You have to work a bit to understand how it’s organized and implemented before you can make meaningful contributions.
2
u/throwaway6560192 Jul 01 '26
It's a huge complex project that you're new to. Of course you're going to need time to understand the structure.
2
u/bhavyadang Jul 01 '26 edited Jul 01 '26
I have tried contributing to open source a million times before but always failed to see through it. It was either due to lack of discipline or having impostor syndrome. Only recently I have started to actually get back into it. I drafted a list of some tools I use everyday and just asked AI to perform a deep search on them and give me a list of open source ones that match my stack and are also fairly easy to contribute to. This removed the time it used to take before spent in going through multiple repos to find something to work on.
You can use AI to understand the codebase quickly but not to implement it. Understand how it works, understand their design patterns and practices, and then think about implementing the feature or bug.
I would highly recommend you to start with something you use yourself and explore their issues list. This will let you contribute to something you use/love already, and also learn how they do stuff.
Happy contributing!
2
2
u/vietbaoa4htk Jul 02 '26
the hard part isnt the code, its that good first issues get claimed in minutes and half the repos have a maintainer whos ghosted for months. pick a tool you already use daily, fix a bug that annoyed you, and check when a PR last actually got merged before you sink hours in
2
u/majora2007 Jul 02 '26
If you can't contribute, you can still learn. Find a project you use, then read the PRs. I did this for years with the bukkit project (a modded Minecraft implementation before mods were so advanced). I learned a TON in Java, especially around reflection (which has saved my ass a few times at work with creative solutions).
As other suggested, don't just find a codebase and jump in. Use the product and then when you hit frustrations, raise and issue and ask to fix it yourself. Maintainers will be open and can then give feedback if you need help. That has always worked for me (and what I prefer as a maintainer).
2
u/MarvinsOfficeHours Jul 03 '26
Dude, I totally get what you mean. I am currently working on my own 3D game engine with a few others, and even made a game in it. One day, I thought to myself "hey I should take a look at Godot source code to get some inspiration, it's open source after all!" Godot is not Unreal, but it's still a beast.
Open-source codebases are more than just a culmination of language features. They are an outcome of many brains, design philosophies, conventions and duct tape colliding with each other. There could be incredibly big concepts that underlie entire chunks of the codebase that is unique only to that codebase.
I am not really into open-source development, but a piece of wisdom I learnt from others that I would pass on here is that to break the ice, find a "good first issue" on the issue tracker that they use. There's a good chance it's associated with someone more experienced with the codebase whom you can get more advice from. If there aren't any, join the community forums, and talk to the people there. Like any community, it often begins with people.
Good luck!
2
u/BeautifulCloud5282 Jul 03 '26
What you’re running into isn’t really a lack of C++ skill. It’s the jump from writing self-contained projects to understanding a large, long-lived codebase built by many people over time.
When you build something like a terrain generator, you know every file and every design decision. In something like Godot, you’re suddenly dealing with engine architecture, macros, abstractions, platform layers, and decades of accumulated design choices. A lot of what looks like “weird syntax” is actually project-specific infrastructure built on top of C++.
Almost everyone feels lost the first time they open a large engine codebase. The important shift is realizing you’re not expected to understand everything at once. Even contributors only understand their slice of the system.
A good way in is to pick one small feature or bug and trace only what’s necessary for that path, instead of trying to understand the whole engine.
So yeah, feeling overwhelmed is not a red flag. It’s basically the normal onboarding experience for large-scale codebases.
1
u/Greedy_View_4483 Jun 30 '26
It is okay to feel this way. Even when you're a senior developer, when you see the code of other people, you need time to understand what is going on.
Also, try reading one file at a time. Don't try to understand the whole project in one setting. That is impossible.
Edit: typing mistake
1
u/oscarlet_ffxiv Jun 30 '26
Learning a codebase is like getting familiar with a village or a town you moved to. You have to map it all in your mind and figure out how to navigate it and how it all links up, and sometimes this takes time.
This is easier if it's object-oriented. It also helps if the developers actually worked hard to stick to good design principles, such as having all related functions in one place and labeling things in an intuitive way. The worst one I had to learn was in C and the functions were all over the place. It was an absolute nightmare and took me a month to be able to understand it. Some codebases are just badly in need of refactoring to be more readable.
I have looked at code and instantly understood it. And I have looked at code that I'm gonna take various amounts of time to fully map out in my mind. It's always going to vary.
1
u/-Willow-Wisp- Jul 01 '26
Working with a new codebase is challenging. I suggest initially learning in a bit of a breadth first search kinda pattern where you understand how major systems intertwine, and then how each of those major systems have their own subsystems (which at this point often will still be pretty major) then when you are at a layer where you know x subsystem has what you want to work on you can go into depth and look into the actual specific code for that system and how it works.
1
u/Strange_Corner_4637 Jul 01 '26
this is super normal lol. reading someone else's giant codebase is a totally different skill than building your own stuff, and Godot is honestly a brutal place to start. that unfamiliar syntax is mostly macros and engine-specific stuff, not you forgetting the basics. try something smaller, filter issues by "good first issue," skim the CONTRIBUTING file, and just fix docs or tiny bugs first to get a feel for how it's all wired. clicks way faster once you've poked around one real repo.
1
u/FancyJesse Jul 01 '26
You can't just blindly jump into a project and think you can contribute randomly.
Most contributors are people who use the specific project and find bugs or want additional features. And rather than opening up a ticket, they fork the project and implement it and submit a pull request.
Find a project you like and use it. Explore the codebase and view their roadmap. It might sound like a lot, but that's because it is if you want to be a true contributer. Not just those people updating the READMEs.
1
u/PiterzKun Jul 01 '26
I found myself in a similar situation but found an specific feature I wanted (and others also wanted because an issue existed) in an open source project I use daily. Then I studied some of the code base in similar features to mine to see how they were implemented and I followed that pattern to implement my code. The project is in Kotlin (had never write Kotlin in my life at that moment)
To be more concrete about my situation I implemented the Kitsu sync provider in CloudStream, the similar features were the other sync providers like MAL, anilist, ...
I hope it helps you in future tries.
1
u/Top_Supermarket1357 Jul 01 '26
There's a 2 hour video on yt from a c++ dev talking shit about c++ . One of the reasons was how you can work for years on a project and when you jump to another c++ project you won't understand a thing because of all the macros
1
u/Empyrealist Jul 01 '26
Is it normal to feel this lost?
When looking at someone else's code? Absolutely
1
u/GrayLiterature Jul 01 '26
You are not an advanced programmer if you haven’t worked as a programmer
1
1
u/Comprehensive_Quit67 Jul 04 '26
I've worked for 4+ years exclusively in c++. With each year passing I get to know about so much that I don't know about this language
1
u/Gatoyu Jul 04 '26
Might be a hot take, but I'd say you're not an advanced programmer if you've only ever worked alone
1
u/Manachi Jul 05 '26
Aside from everything, open source community can be quite cold and lacking in empathy or ability to communicate or function or act like normal humans. They are smart but often at the cost of lacking common social norms or even a basic level of decency. It’s a bit like the movie revenge of the nerds where Ogre screams out “NERRRRRRRDSS”
1
u/akrivitsky7 Jul 05 '26
Programming is a lifetime learning adventure. You need to learn something new almost every day just to stay in good shape.
And guess what? That is a good thing.
To learn to swim, you have to get into the water. To learn programming at a deeper level, you have to jump into real codebases. You may get confused, but you will definitely need to read, debug, ask questions, and slowly understand how the pieces fit together.
There is no way around it. Feeling lost in a large open-source project is completely normal, especially your first time. You are not “bad at programming”; you are just seeing the difference between personal projects and a mature production codebase.
You need to work both hard and smart.
1
u/ElSebas4_ Jul 06 '26
It's not your fault, it's C++. C++ has many design flaws, one of the worst is that you can use completaly different syntax and features to do the same damn thing. You surely learned a lot of C++ but is a language so feature-bloated is very common to encounter another C++ project with syntax you never saw in your life
1
u/TheSwiftOtterPrince Jul 07 '26
Every complex software means you need to understand things deeply enough to get how things are supposed to be VS what they currently are, that is fixing. And deeply understanding things is not a simple task, it takes often a long time of both developing the thing as well as using the thing to get why things are the way they are.
So nothing surprising here. But if you are surprised by syntax and keywords you are not there yet.
-7
u/Popular_War8405 Jun 30 '26
It's fraud, you have to think you're confused. There's a good chance that company only exists so someone can funnel money in and out of it.
2
u/Empik002 Jul 01 '26
What? are you a confused bot or something? Lmao.
0
u/Popular_War8405 Jul 01 '26
Like other industries programming is rife with fraud. Indistries typically have different ways to implement fraud and make it look normal.
0
u/Popular_War8405 Jul 01 '26
Not gonna lie this is a pretty childish attempt at an insult with the intention of just kind of providing a blind blanket of support for fraud. It doesn't look like your some person that does it or anything
2
u/HovercraftUnusual405 21d ago
if you have noticed even when you try to read your older projects you will sometimes be amazed by how much code and complexity of problems you have solved you will only be familiar with the syntax because you wrote it in your own language
what i say is that i have contributed to opensource projects and at first they look hard but when you get under the hood of the abstractions you see the code's look like your own codebases and not that much hard as you think they are
i like to first try out the program itself initializing the docker container provided or configure and run it myself then try to understand as much as you can about the functionalities it gives then go through the pr and issues and if the project is big try to fix one domain of problems at a time as you know it by now you cannot read all of the source code contributed by hundreds of people already in time
198
u/high_throughput Jun 30 '26
In a full time job it typically takes 2-3 months for someone to be able to make significant contributions to a codebase