If you’d asked me a few years ago what would shape my career the most lectures, degrees, or late-night coding marathons I would’ve hesitated. I’ve always respected education. I don’t think it’s worthless.
Here’s what I mean.
University taught me abstraction. Open source forced me to face reality.
University gave me eleant models layered architectures, SOLID principles, fancy UML diagrams. But when I joined an open source project, I had to dig through 50 files to figure out why an api was called twice.
There was no exam.
Just Git history, strangers in Slack, and problems begging to be solved.
I didn’t know the answer so I learned to ask better questions.
Open source made me ship. And break. And fix.
At university, you build apps that work in a vacuum.
In open source, your code lands in a living system used by thousands.
I started small
My first contributions were just humble README updates fixing typos, improving docs. It didn’t feel like much, but it was my way of learning how the community works.
Then I moved to “good first issues” across multiple projects.
Every issue taught me how projects were structured, how contributors communicated, and how even the smallest fix had value.
Then came Mattermost
Eventually, I found myself tackling a real issue in Mattermost. It wasn’t easy it took me three months to complete the full task. Between understanding legacy code, figuring out architectural decisions, and getting feedback from experienced reviewers, I learned more from that one issue than any group project at university. I even introduced myself to the community, networked with mattemrost brilliant engineers and watched all their public meetings.
Now I maintain Sveltos
Today, I’m actively maintaining the Sveltos Dashboard, contributing regularly and communicating with project leads to shape features. I don’t just write code I explain ideas, propose UI/UX changes, discuss trade-offs, and help drive the frontend experience forward.
And yes, I still learn something new every week.
I learned to communicate like a software engineer not just code like one.
One of the most underrated skills I picked up in open source wasn’t technical at all: it was learning to write a good issue. A thoughtful code review. A helpful comment on someone else’s draft PR.
At school, collaboration often means splitting a group project into pieces and hoping it compiles the night before.
In open source, collaboration means:
- Sharing context, not just code
- Justifying decisions, not just syntax
- Building trust across time zones and tech stacks
Working with maintainers and contributors in projects like Sveltos has taught me how to clearly communicate feature proposals, explain trade-offs, and push discussions forward — something no university curriculum ever asked me to do.
OSS gave me fire.
I’ll never dismiss the foundation university gave me. But open source made it matter.
In OSS, I wasn’t just writing TypeScript or React.
I was making decisions that affected real people.
I was contributing to tools used in companies and startups I admire.
And sometimes was building things I didn’t fully understand yet, but trusted myself to learn.
I jump into issues that I have no ideas how to fix just to publicly ashame myself if I do not complete them , and this method worked with me everytime. It’s the way i learned golang from an open source issue
It gave me the confidence to say “yes” to big tasks.
It gave me the humility to read 10 RFCs just to fix a minor bug.
It gave me the belief that learning never ends but neither does building.
If you’re in school, or just starting out, I’ll be real with you:
- You don’t need to master everything.
- You don’t need to wait until you’re “ready.”
- You don’t even need to be confident. You just need to be curious. Just jump in into that gituhb issue and shame yourself until you FIX it.
Open source won’t give you a grade.
It won’t hand you a syllabus.
But it might give you something better: a sense of purpose , networking and real skills.
And if you’re anything like me that might be the beginning of everything.