/ open-source

Open Source

I didn't get into open source to build a resume. I got into it because I was curious — curious about how real software gets built, how maintainers think, how code reviews actually work when the person on the other end doesn't know you.

So I started poking around. Reading code. Filing issues. Sending small PRs and getting them rejected. Sending better ones. Over time, open source became my way of learning — the kind of learning no tutorial or course could give me. Jumping into a codebase I'd never seen, figuring out how things connect, and trying to make something better. Sometimes it worked. Sometimes it didn't. Either way, I walked away knowing more than I did before.

Twenty CRMYC-backed CRM Platform

Contributions

  • Built reusable UI components and fixed workflow inconsistencies across the application.
  • Resolved browser-specific behavior issues affecting workspace rendering.
  • Improved developer onboarding by identifying and fixing setup/documentation gaps.

What I learned

  • Finding my way through a large TypeScript codebase without getting lost
  • Seeing firsthand how product-driven teams make engineering tradeoffs
  • Taking reviewer feedback — not as criticism, but as a chance to get better

PSLab Android

Contributions

  • Investigated and fixed application crashes in hardware-control workflows.
  • Resolved navigation and state-management issues affecting user experience.
  • Participated in issue reporting, debugging, and validation of fixes.

What I learned

  • Getting comfortable with Android's debugging workflow — logs, stack traces, the whole drill
  • Learning to trace a bug back to its root when I had zero context on the codebase
  • Reading production mobile app code and actually understanding what's going on

Checkstyle

Contributions

  • Contributed a merged fix related to AST formatting logic.
  • Worked within a mature Java project with strict review and quality standards.

What I learned

  • Peeking inside how static analysis tools actually work under the hood
  • Navigating a mature, well-established Java codebase without feeling intimidated
  • Writing changes that survive genuinely rigorous code review

Beyond These

I've also spent time with Anki Android, Spectrum UI, Flutter Website, Appwrite Website, Stoccoin Website. Bug fixes, UI tweaks, documentation cleanup, issue triage — some were small, some never got merged. Each one was a chance to step into something unfamiliar and figure it out.

Why Any of This Matters

I didn't have a plan when I started. I was just a developer who wanted to see how things work. What I didn't realize is that I was giving myself something invaluable — the ability to walk into any codebase, read it, understand it, and make meaningful changes, fast.

That didn't come from a course. It came from staring at unfamiliar code, breaking things, learning why they broke, and doing it again. I'm genuinely grateful I had these experiences early — they've shaped how I approach software today.

  • Walk into any codebase — even one I've never seen — and find my bearings quickly
  • Debug problems without needing someone to hand me context first
  • Communicate clearly with maintainers who don't owe me their time
  • Hop between languages and frameworks without it feeling like starting over
  • Ship changes that hold up through real review cycles, not just my own testing

I'm still the same curious developer I was when I sent my first PR. Just a little better at it now.