From Contributor to Founder: How Open Source Built Our Careers (And Can Build Yours)

The path from open-source contributor to company co-founder isn't the story most developers hear when they're starting out. 

We hear about the importance of side projects, building a portfolio, and grinding through technical interviews. But there's another path, one that's less discussed but potentially more powerful: becoming so valuable through consistent open-source contributions that opportunities come to you.

In a recent webinar, my co-founder, Jesus Manuel Olivas, and I shared the unfiltered story of how open source contribution built our careers, our expertise, and eventually our company.

What emerged wasn't a simple success formula, but a nuanced picture of patience, genuine motivation, and the compound effect of showing up for community projects year after year.

Here's what we learned, and how you can apply it to your own career.

Why Open Source Became Our Career Foundation

The most sustainable open-source contributors share something in common: they start by solving their own problems.

My first motivation to work in open source was trying to learn something for myself or for the work I was doing. You're working with real problems, you're trying to solve real problems, and that's the main motivation, at least for me.

This isn't the advice you typically hear. The common narrative positions open-source contribution as a form of altruism: give back to the community, help others, build something for the greater good. 

While those outcomes often result from contribution, they're rarely what sustains contributors through the unglamorous early stages.

If you want to read more about reasons why open-source projects fail, read my take here.

For Jesus and me, the catalyst was a major technical transition: Drupal 7 to Drupal 8. The change was substantial enough that our existing expertise suddenly felt incomplete. 

Rather than viewing this as a threat, we saw it as an opportunity.

The change from Drupal 7 to Drupal 8 was a really big breaking change. There was a lot of fear because we didn't know how the new things worked. Jesus had experience with Symfony, which the Drupal core was moving toward, and that was the opportunity I took to learn and be prepared for Drupal, which was my daily work at the time.

What started as a learning exercise building Drupal Console to understand the new platform became a widely-adopted tool. But the success wasn't the goal. The learning was.

This distinction matters because it affects sustainability. Contributors who start with external goals like fame, money, or job offers often burn out when those rewards don't materialize quickly. Contributors who start with internal goals like learning, solving problems, and understanding systems find value immediately, regardless of external recognition.

Building Visibility Without Chasing Fame in Open Source

One of the most counterintuitive insights from the conversation was about recognition: the contributors who receive it most reliably are those who weren't seeking it.

But, at some point, getting recognition for what you build is going to come after you build it. 

You don't build it to get famous or something like that. You build it because you need it, and you realize someone else needs it. At some point, if the project is successful, you will get the recognition.

This isn't just philosophical advice. It has practical implications for how you approach contribution.

When I evaluate candidates, I look beyond traditional credentials. If I have a resume in front of me, I really pay attention to their GitHub profile, what they're doing, if they're contributing. That really helps a lot.

This matters because GitHub profiles reveal something resumes can't: how someone actually works. 

Do they communicate clearly in pull requests? Do they respond constructively to feedback? Do they follow through on commitments? Do they help others? 

These signals are often more predictive of job performance than interview answers.

Entry Points for New Contributors to Open Source

If you're convinced that open source contribution might benefit your career but don't know where to start, I can offer practical guidance based on what I've seen work.

Documentation, translations, there's a popular tag in GitHub like "first issue" or something like that. That can be a motivator for people who are getting started.

But I always add a crucial caveat: just please don't make typo fixes because that doesn't work.

The distinction matters. 

Typo fixes, while technically contributions, don't demonstrate meaningful engagement with a project. 

They're the open source equivalent of showing up to a networking event, grabbing a business card, and leaving. You've technically participated, but you haven't built anything.

Meaningful entry points include:

• Documentation improvements: Not fixing typos, but clarifying confusing sections, adding examples, or improving organization. This requires understanding the project well enough to explain it.
• Translations: For multilingual projects, translations expand the project's reach and demonstrate both language skills and technical understanding.
• First issues: Many projects tag issues appropriate for newcomers. These are designed to be achievable while still requiring genuine engagement with the codebase.
• Bug reproduction: When someone reports a bug, helping reproduce it with a minimal test case provides real value and teaches you about the project's internals.

The goal isn't to accumulate contribution counts. It's to build genuine understanding of projects and ecosystems you care about.

My advice for choosing where to contribute: what technology are you interested in? Well, take a look at the open-source projects and try to get involved.

You'll contribute more effectively to projects you genuinely care about, and the expertise you build will be relevant to your career goals.

The Open-Source Network Effect: From Contributor to Co-Founder

Perhaps the most compelling part of my story is how open-source contributions led directly to co-founding Octahedroid.

We made a company based on that. That's where I know a lot of people. In open source, this is where I met my two co-founders, Jesus and Jorge, and a lot of people.

This wasn't a calculated networking strategy. 

I didn't contribute to open source projects, thinking this would help me find co-founders. I contributed because I was genuinely engaged with the work and the community. The relationships formed naturally through collaboration.

The pattern is consistent across the tech industry. Open-source communities are where serious practitioners congregate. When you contribute meaningfully, you're demonstrating your capabilities to exactly the people who might one day want to work with you.

Contributing to open source brought me the privilege of not applying for any job in my tech life. People would ask me, "Do you need a job? We have a job. Do you want to take it?"

The career benefits compound over time. 

Early contributions build expertise. Expertise leads to larger contributions. Larger contributions lead to recognition. Recognition leads to opportunities. Opportunities lead to more expertise.

But this flywheel only works if the initial contributions are genuine. You can't shortcut your way to expertise by gaming contribution metrics. 

The people you'd want to work with can tell the difference.

Practical Advice for Your Open Source Career Path

Synthesizing the insights from our conversation, here's a practical framework for early-career developers considering open-source contribution:

• Choose technologies you genuinely want to learn. You'll sustain contribution longer and build relevant expertise. If you're interested in frontend frameworks, contribute to frontend projects. If you care about infrastructure, find infrastructure projects. Forced contribution to projects you don't care about rarely lasts.
• Start with understanding, not committing. Before contributing code, understand the project. Read the documentation. Use the project. Understand its architecture and conventions. Your contributions will be more valuable when grounded in real understanding.
• Contribute in public. The career benefits of open source contribution depend on visibility. Private forks and unreleased improvements don't build your public profile. Even small contributions in public repositories demonstrate engagement.
• Engage with the community, not just the code. Answer questions in discussions. Help newcomers. Participate in project decisions. The relationships you build matter as much as the code you write.
• Be consistent over time. Sporadic intense contribution followed by months of absence builds less career value than steady, sustainable contribution. The compound effect requires consistency.
• Document your journey. Write about what you're learning. Share your contributions on professional platforms. Make it easy for potential employers or collaborators to discover your work.

In the End, Open Source is Learning That Compounds

When asked what early-career developers should expect from open-source contribution, I offer a guarantee.

The one thing for sure is you're going to learn a lot of things. You're going to learn a lot, whatever is the thing you are involved in.

This is the floor, not the ceiling. You will learn. You might also build visibility, create career opportunities, form valuable relationships, and develop expertise that distinguishes you in your field. But learning is guaranteed.

Start small. Stay consistent. Let the results compound over time.

Ready to explore how open-source expertise could accelerate your team's capabilities or your career? 

At Octahedroid, we've built our company on the foundation of open-source contributions and can help you navigate this landscape strategically. 

Contact us for a consultation to discuss how open source fits into your technical strategy.