Returning to open source: collaboration first, code second

My first real experience with open source was through EddieHub in 2022.

I did not contribute a huge amount of code. That is also not the part I remember most clearly.

What stayed with me was the experience around the code: asking questions in public, learning how people reviewed each other's work, seeing contributors help one another, and discovering that a pull request could be a conversation rather than a transaction.

EddieHub has since closed and Eddie has moved on to bigger goals, but one principle from that community has stayed with me:

Collaboration 1st, Code 2nd

Four years later, I understand that line differently.

Coming back as a working engineer

In 2022, open source was mostly a place for me to learn how software communities worked. In 2026, I am returning with professional experience building applied AI and backend systems: APIs, data flows, agent-based applications, evaluation pipelines, cloud infrastructure, and the less glamorous reliability work that makes those systems usable in production.

That experience gives me more technical context, but it does not remove the need to be a good newcomer.

Every mature project has its own history, design constraints, naming conventions, testing philosophy, release process, and maintainer bandwidth. Knowing Python or TypeScript does not mean knowing a codebase. Working professionally does not mean arriving with the right answer.

So I do not want my return to open source to begin with "what impressive feature can I build?"

I want it to begin with better questions:

• What is this project trying to protect?
• Which problems do the maintainers actually want outside help with?
• Can I reproduce the issue before changing anything?
• What is the smallest useful contribution I can make?
• Can I leave the code, tests, documentation, or discussion clearer than I found it?

That feels much closer to collaboration first.

The goal for September

I have one deliberately small goal: contribute a useful pull request before the end of September 2026.

Not ten PRs. Not a contribution graph streak. Not a giant feature written over a weekend.

One contribution to an active project where I can understand the problem, communicate with the people maintaining it, make a focused change, test it properly, and learn from the review.

I am looking mostly at projects close to the work I already do: Python backend systems, AI application infrastructure, observability and evaluation, agent tooling, APIs, and developer tooling around those areas. I am also paying attention to community signals: a clear contributing guide, recent maintainer activity, well-scoped issues, and evidence that external contributors actually receive feedback.

The technical fit matters because I want to be useful. The community fit matters because that is what made open source meaningful to me in the first place.

What I want to document this time

I also want to write down more of the process.

If I read an unfamiliar codebase, reproduce a bug, misunderstand an issue, learn a testing pattern, get useful review feedback, or discover a better way to communicate a change, that is worth recording even when the final diff is small.

Some of those notes will become short TILs. Others may become longer posts about reading code, debugging, evaluation, APIs, or contributing effectively without creating unnecessary work for maintainers.

The PR will be one output. The learning around it is another.

Open source gave me an early lesson that software is a social system as much as a technical one. I want to come back to it with more engineering experience and some spice of ai tools without losing that lesson.

Collaboration first. Code second.

That is the constraint I want to keep.