Open Source Journey

Looking back at my previous blog posts feels incredibly humbling. I can see how much I've grown through this journey and honestly, it's been one of the most fun experiences I've had in my academic career. Why? Because I got to browse through some absolutely brilliant and amazing projects that are actually used in production.
Let me take you through the key lessons I learned from contributing to four different open source projects.

Communication Over Confidence
Project: BEHAVIOR-1K
My first contribution taught me the most fundamental lesson of open source.
I spent full 3 days just setting up the project and understanding the codebase. When I finally identified the issue, I faced a dilemma. There was a line of code that seems very important but I had to remove to fix the issue. The function returned False if it identified anything other than True in a list, but there was also an assert all(...), child_values has NoneTypes line checking for NoneType values.
Should I remove it or Keep it?
Instead of making assumptions, I created a Pull Request with a [WIP] tag to open a conversation with the reviewers. This turned out to be the right call. In open source, especially as a newcomer, communication is the golden key. Nobody expects you to be perfect but they do expect you to be thoughtful. Don't be afraid to ask questions. Maintainers would much rather answer your questions than dealing with a poor PR.

Start Simple, Build Confidence
Project: Scikit-learn
After the intense first experience with BEHAVIOR-1K, I needed something more approachable. I went straight to Scikit-learn's good first issue label and found a task that seemed manageable: changing relative imports to absolute imports in Cython files.
From this

from ...utils._typedefs cimport float64_t, float32_t

To this

from sklearn.utils._typedefs cimport float64_t, float32_t

Was it a simple task? Yes. But I learned something out of it.
This was my first real encounter with Cython, and I discovered how Python libraries achieve C-level performance. I learned what cimport means, why float64_t exists, and how type definitions help optimize the code. Even a simple task in a well structured project teaches you something new.
Simple contributions are not lesser contributions. They're opportunities to learn the project's architecture and tooling. Furthermore, they build your confidence for tackling harder issues later.

Embrace Challenges
Project: Dagster
After building confidence with Scikit-learn, I wanted something more challenging. Dagster, a data orchestration platform used by real companies in production, had an interesting bug.

callable objects with custom signatures were crashing the type hints resolution system.

The problem was technical

class MyWrapper:
    def __init__(self, fn):
        self.__signature__ = inspect.signature(fn)

    def __call__(self, **kwargs):
        ...

This would crash with TypeError: <callable object> is not a module, class, method, or function.
At first, I thought this is too complex for me. But kept trying and I managed to find the solution. Instead of passing the object to typing.get_type_hints(), extract the type information directly from the __signature__ object.
I've learned couple things while contributing to this issue.

• Python's signature protocol and the __signature__ attribute
• The importance of comprehensive testing in production systems
• How to read and understand complex codebases with decorator systems and dependency injection

Don't be afraid to tackle issues that seem slightly beyond your current skill level. The struggle is where the real learning happens.

Contributing to Tools You Use
Project: Optuna
By my fourth contribution, I felt much more comfortable with the open source process. I chose Optuna, a hyperparameter optimization framework which I've heard about while studying Machine Learning. I found an issue asking to modernize the code by replacing .format() with f-strings.
Old way

"{cls}({kwargs})".format(cls=..., kwargs=...)

New way

f"{cls}({kwargs})"

It was fairly easy issue but I wanted to contribute to a tool I actually use and understand. Working on Optuna felt much more comfortable than my first Scikit-learn contribution because I had context about what the library does and why it matters.
Contributing to projects you actually use is always a good way to get this going. Not only does being part of the amazing project feel good, but it also makes you feel proud that you contributed to a big community.

The Joy of Exploration
One of the most unexpected pleasures of this journey was simply browsing through brilliant projects. Each repository I explored, whether I contributed to it or not, taught me something about software architecture, testing, or documentation. It's like getting a behind-the-scenes tour of how professional softwares are built.

I'm having a lot of fun doing this, and I hope that comes through in my writing. Open source contribution isn't just about adding lines to your resume. It's about being part of big community and contribute to tools that developers around the world rely on.
Looking back at these four contributions, I'm proud of what I've accomplished. Looking forward, I'm excited about what comes next. Each contribution has taught me new technologies and new possibilities.
If you're thinking about contributing to open source, just start. Find a project you use, look for a good first issue and take that first step. The open source community is very welcoming and who knows? you might just have fun doing it.