Feeling stuck in your day job? Tinkering with the same libraries, juggling different versions, or endlessly maintaining old code? You’re not alone. I’ve been there. When I worked as a developer in software product companies, I felt truly alive and curious only when I changed roles and faced new challenges. In consultancy, things moved too fast to go deep—leaving me stagnant.

This feeling isn’t uncommon. Talk to experienced engineers at meetups or your workplace, and you’ll find almost everyone has felt like a “frog in the well” at some point in their career.

Beyond the Bubble

There are many ways to break out of this bubble without constantly changing jobs. One path that often comes up is contributing to open source projects. It’s frequently seen as a go-to way to learn, explore, and grow—and it absolutely can be. The key is finding the right fit.

Maybe you’ve wanted to try a new role but never had the chance. Maybe you’ve wanted to explore a new language or framework. Open source can offer those opportunities—on real projects that people actually use, not just small hobby experiments that fade away.

Along the way, you’ll discover that contributing to open source:

• Connects you with new people
• Exposes you to different expectations and workflows
• Gives you the freedom to explore and experiment

What is Open Source?

If you’re new to open source, here’s a quick primer:

Open source software is publicly accessible software that anyone can view, modify, and distribute. It’s built by communities of contributors from around the world.

Since the GNU Project in 1983, open source development has grown tremendously. Today, it’s hard to imagine building proprietary software—or even doing your daily work—without relying on open source libraries, platforms, or tools.

My First Attempt (Failure Story)

In 2011, I was working as a developer on a product that used Adobe Flex for its frontend. It was my first job after graduating in 2010. I was doing well—confident in my skills and comfortable in my role.

At the same time, I saw some of my former classmates contributing to open source projects and getting recognized for their work. That world intrigued me.

The first piece of advice I received was simple: find something close to your work and your interests.

So I chose Apache Flex. Adobe had just open-sourced Flex and donated it to the Apache Software Foundation. It felt like the perfect fit—it was the same technology I used every day.

I joined the mailing list, excited and motivated to contribute.

That excitement didn’t last long. Almost immediately, I was flooded with emails—threads full of experienced contributors discussing topics I barely understood. My confidence started to fade. The same person who felt capable at work suddenly felt completely out of place.

Still, I pushed myself to pick up an issue that seemed simple. But once I started, I was lost. I didn’t know where to begin, and more importantly, I didn’t know where to ask for help. This wasn’t like my workplace, where there were clear roles, teammates I could turn to. Here, everything felt unstructured and distant.

I hesitated to ask questions on the mailing list. I didn’t want to sound inexperienced or “silly.” After struggling for quite some time, I managed to put together a fix and opened a pull request. And then… nothing. It wasn’t prioritized. There were bigger issues the maintainers were focusing on.

I waited for feedback, but none came. Eventually, I gave up. I left the mailing list, stopped following the project, and never went back to that pull request again.

Why it Failed?

Looking back, it’s clear why this attempt failed. It wasn’t the project—it was my approach and my mindset at the time. Here’s what went wrong:

1. Lack of experience with ambiguity

I was less than a year into my career. At work, everything was structured—tasks were clearly defined, and guidance was always available. Open source was the opposite. Issues were often loosely defined, and I wasn’t yet comfortable navigating that uncertainty.

2. Fear of communication

Unlike my workplace, this was a remote, distributed community. I didn’t know anyone personally, and that made me hesitant to ask questions. I was afraid of being judged. In reality, that fear held me back more than anything else.

3. Jumping in too quickly

I tried to contribute immediately without first understanding the project or the community. I didn’t spend time observing discussions, understanding workflows, or learning how contributors collaborated.

4. Imposter syndrome

The biggest issue wasn’t technical—it was psychological. Seeing so many experienced contributors made me feel like I didn’t belong. I started doubting my own abilities.

One important thing to clarify: the initial advice I received—to find a project close to my work and interests—was not wrong. In fact, it’s still one of the best pieces of advice for anyone starting out in open source.

The problem wasn’t the choice of project. Apache Flex was a good fit for my skills at the time. The real issue was how I approached the contribution process. I focused only on what to contribute, not how to contribute within a community.

To be fair, this was before many open-source projects widely adopted Codes of Conduct to make participation more welcoming and inclusive. Based on my limited interaction, I can’t judge the community fairly. But with over 15 years of experience now, I believe it was likely more welcoming than I assumed—if I had taken the time to engage.

At that stage in my career, I simply wasn’t ready. And that’s okay.

My Second Attempt (Success Story)

In 2023—more than a decade after my first failed attempt—I found myself back in the open source world. This time, it wasn’t entirely by choice. I was assigned to work on an open source project that my company was supporting. But something was different this time.

Instead of jumping straight into contributing code, I started by listening. I joined community calls regularly—even before the project had a name. At first, I was just there because it was part of my job. But soon, the idea of reshaping how cloud services could be used in the future started to fascinate me. I began observing how the community worked. Who spoke? Who made decisions? What problems were being discussed?

One thing quickly stood out. There were many subject matter experts—people with deep knowledge in areas like threat modelling and security controls. But there was a gap. No one was actually doing the groundwork. There were ideas, discussions, and expertise—but no clear structure, no roadmap, and no one driving things forward.

This time, instead of feeling overwhelmed by the ambiguity, I leaned into it. I started small. Before each community call, I spent a few hours doing my own research. I didn’t fully understand threat modelling, but I tried to piece together what the project might need. Then I shared my thoughts openly—with no expectation of being “right.”

To my surprise, the community responded very positively. People started reaching out, thanking me for driving the project forward and asking for my opinion. That was a turning point—I realized I had gone from being an outsider to someone whose contributions actually mattered.

What started as small contributions—notes, ideas, early drafts—began to shape the direction of the project, FINOS Common Cloud Controls. Slowly, we started building a framework together. Not because anyone had a perfect plan, but because we were making progress step by step.

After two months, I was moved off the project to focus on a client engagement. But by then, something had changed. I had built a connection with the project and the community. Out of curiosity—and a genuine sense of ownership—I requested to continue contributing in my own time as a representative of my company.

Over time, my role in the FINOS CCC evolved. People came and went. New contributors and organizations joined. But the vision remained the same: to shape how cloud services are used in financial institutions, with the right level of controls in place. I went from being a contributor, to an active participant, then to a project maintainer, a working group lead, and eventually an ambassador—speaking about the project at FINOS conferences. What started as an assignment became something much more meaningful.

Why the Second Attempt Worked

So why did this attempt succeed where the first one failed?

The biggest difference wasn’t the project—it was me.

1. Comfort with uncertainty

In 2011, ambiguity overwhelmed me. In 2023, I embraced it. With over a decade of experience, I had learned that not having all the answers is normal. I trusted myself to figure things out along the way.

2. Not doing it alone

This time, I wasn’t a lone contributor. I had a small group of colleagues alongside me, and that made a huge difference. Even though we hadn’t worked closely before, we quickly became a support system for each other. It felt like stepping into something new with familiar faces—safer and more encouraging.

3. Focusing on contribution, not perfection

Earlier, I hesitated because I didn’t want to be wrong. This time, I shared ideas freely—even when they were incomplete. That openness helped move the project forward.

4. Active participation in the community

I didn’t just show up to contribute code—I showed up to listen, learn, and engage. Attending calls regularly helped me understand the vision, the people, and the direction of the project. Nothing felt “over my head” anymore because I was part of the conversation.

5. Leveraging what I already knew

I wasn’t a security expert. I didn’t know much about threat modelling or writing controls. But I knew AWS. And I knew that if the project involved cloud systems, that knowledge would be useful. Instead of focusing on what I lacked, I contributed what I had.

6. Growth beyond technical skills

One of the biggest surprises was how much I learned outside of coding. I learned by listening to principals and CTOs handle tough questions. I learned how to communicate ideas clearly, how to ask for resources, and how to encourage collaboration.

I was pushed into areas I had never explored before—public speaking, facilitating meetings, and leading discussions.

7. A sense of ownership

Over time, the project stopped feeling like “just work.” It became something I cared deeply about. I wanted it to succeed—not because I had to, but because I was invested in it.

In the end, the relationship was mutual: the project benefited from my contributions, and I grew because of it.

How to Find the Right Project

Finding the right open source project can make all the difference. As I learned from my own experience, it’s not just about picking a project—it’s about finding one that fits you.

Here’s a simple way to get started:

1. Find a project you care about

Start with something you already use or are curious about. It could be a library you rely on, a framework you want to learn, or even a tool you use daily. Interest makes a huge difference—it keeps you going when things get difficult.

2. Engage with the community

Before writing code, spend time understanding the project. Join community channels like Slack, Discord, forums, or mailing lists. Choose these channels wisely—pick the ones that suit you and avoid overwhelming yourself with too much information at once. Listen to discussions. Observe how people collaborate. This step is often overlooked, but it makes a big difference.

3. Make your first contribution

Look for issues labeled “good first issue” or “beginner-friendly.” These are intentionally designed to help new contributors get started. Don’t aim for big changes early on—small, consistent contributions build confidence and momentum.

Your first contribution doesn’t have to be code. It could be improving documentation, fixing a typo, or asking a thoughtful question. The goal is to get comfortable with the process.

Setting the Correct Mindset

Finding the right project is only part of the journey. Just as important is having the right mindset when working in open source—because it can feel very different from a typical workplace environment.

Here are a few things to keep in mind:

• Contributions are voluntary: People contribute on a best-effort basis. Everyone has different priorities, so responses and progress may take time.
• There is less structure: Unlike your day job, there may not be clearly defined roles or responsibilities. This can feel uncomfortable at first—but it also creates opportunities to step up.
• Progress can be slow: Decisions take time, discussions evolve, and direction may change. Patience is key.
• You learn through feedback: Code reviews and discussions are one of the best ways to grow. Be open to feedback—it’s part of the process.
• Direction can change: Open source projects evolve based on community input. What you start may not always be what gets shipped—and that’s okay.
• Share your ideas openly: Don’t wait for perfection. Sharing early helps move the project forward and invites collaboration.
• Help create a welcoming environment: Open source thrives on community. The more welcoming and supportive you are, the better the experience becomes for everyone—including you.

Myths About Open Source

Before concluding it’s important to talk about misconceptions about open source that stop people from even getting started. Let’s clear up a few of the most common ones:

Myth 1: “I need to be an expert”

Reality: Everyone starts somewhere.

Most contributors you see today were once beginners trying to understand the same codebase. Open source is not about knowing everything—it’s about learning in public and improving over time.

Myth 2: “I don’t have enough time”

Reality: Even a small amount of time is enough.

You don’t need to spend hours every day. Even one or two hours a week can make a meaningful contribution over time. Consistency matters more than intensity.

Myth 3: “I need to write code to contribute”

Reality: Contributions go far beyond code.

Documentation, testing, reporting bugs, improving examples, or even helping others in discussions are all valuable contributions. In many projects, these are just as important as writing code.

Myth 4: “Open source communities are unwelcoming”

Reality: Most communities are supportive and encouraging.

While every community is different, most open source projects genuinely want contributors to succeed. Many have adopted Codes of Conduct (such as the Contributor Covenant) to make participation safer, more respectful, and inclusive.

From my own experience, the biggest barrier wasn’t the community—it was my assumption about it. Once I started engaging, I found people far more helpful and welcoming than I expected.

Everyone’s journey is different, and so are the opportunities we come across. Sometimes, the right opportunities don’t present themselves—and in those moments, we have to create our own.

Open source is one of the most powerful ways to do that.

Think of it like walking into a shoe shop. Not every shoe will fit you. Some may look good but feel uncomfortable. Others may fit well but not excite you. The key is to find the one that fits you—your interests, your skills, and your goals. And just like any good pair of shoes, there’s a price. In this case, it’s your time and effort. But when you find the right fit—something that matches both your interests and your commitment—the return is immense. That’s when growth accelerates. That’s when you start enjoying the journey.

Choose the right open source project, and it won’t just be another activity—it can become a catalyst for your career and personal growth.