My journey into open source didn’t start with a perfectly planned goal or roadmap. Like many developers, I had been using open-source tools for years without really thinking about what it meant to contribute to them. At some point, though, I became curious about how these projects actually worked behind the scenes and how people became part of them.
That curiosity eventually led me to explore Google Summer of Code (GSoC) and the organizations that participate in it. While going through different projects, I came across OWASP, an organization I was already somewhat familiar with because of its work around web security. Among its projects, BLT (Bug Logging Tool) stood out to me.
Interestingly, this wasn’t the first time I had looked at BLT. I had applied to GSoC 2025 with OWASP BLT as well. I wasn’t selected that year, but the process introduced me to the project and the community around it. Instead of treating it as a one-time attempt, I decided to stay around and keep contributing whenever I could. Looking back, that decision ended up shaping my open-source journey far more than I expected.
Getting Familiar with the Project
When I first started exploring BLT, I assumed it was just a simple bug-reporting platform. But after spending some time reading through the repository and documentation, it became clear that there was much more to it.
The platform is designed to help collect and manage bug reports while also recognizing contributors through a transparent leaderboard system. What made it interesting was how the project combined community participation with security-focused workflows.
Before attempting any contribution, I spent time just understanding how things worked. I cloned the repository, tried to run the project locally, explored different parts of the application, and read through issues and past pull requests to see how other contributors approached changes.
At first the codebase felt a bit overwhelming. But instead of trying to understand everything at once, I started focusing on small sections of the project connected to specific issues. Slowly the structure started making more sense.
That process taught me something important about open source: you don’t need to understand the entire system to begin contributing. You just need to understand enough to solve one problem.
Finding My Way Around the Ecosystem
As I became more comfortable navigating the project, I started contributing improvements in different parts of the BLT ecosystem.
Some of my work involved the main BLT web application, which is the core platform where bug reports are submitted and managed. While working there, I got a better sense of how the platform handles contributors, issues, and the workflows around security-related reports.
At the same time, I explored other parts of the ecosystem as well. I contributed to the BLT Leaf app, which helps track pull requests and activity across the different repositories that make up the project. Seeing how that system worked gave me a better understanding of how development activity is monitored across the ecosystem.
I also spent time working with components that handle automation and infrastructure, including the GitHub app that powers many of the automated workflows used across the repositories. These tools help manage tasks like validating contributions and maintaining consistency across different parts of the project.
Another interesting part of the ecosystem involved the Cloudflare-based deployment of BLT, which showed me how the platform integrates infrastructure and edge services to support its functionality.
Working across these different pieces made me realize that BLT isn’t just a single repository. It’s a collection of interconnected components that work together to support the overall platform.
What Open Source Taught Me
Contributing to BLT taught me a lot more than just how to write code for an open-source project.
One of the biggest things I learned was how to approach a large codebase without getting overwhelmed. In the beginning, the size of the project made it feel difficult to know where to start. Over time I realized that breaking things down into smaller problems makes the process much more manageable.
I also learned how important clear communication is in open source. Writing good pull request descriptions, explaining the reasoning behind changes, and responding to feedback from maintainers are all part of the process.
Another realization was how collaborative open-source development really is. Code reviews, discussions, and shared ideas all shape the direction of the project. Being part of that process helped me understand how real-world software evolves over time.
Perhaps the most important lesson was that progress usually comes from consistent small improvements rather than one large change.
The Community Experience
One of the most enjoyable parts of contributing to BLT has been interacting with the community behind it.
Maintainers and contributors are generally open to questions and discussions, which makes it much easier for new contributors to get involved. Seeing how people collaborate and help each other understand different parts of the project made the whole experience far less intimidating than I initially expected.
Being part of these interactions helped me grow not just technically but also in how I approach collaborative development.
Looking Ahead to GSoC 2026
My involvement with OWASP BLT originally started while preparing for Google Summer of Code 2025. Even though I wasn’t selected that year, the experience encouraged me to keep contributing and learning more about the project.
Since then, I’ve become much more familiar with the codebase, the ecosystem around it, and the community that drives the project forward. Because of that, applying for GSoC 2026 with OWASP BLT now feels less like starting something new and more like continuing a journey that has already begun.
I’m excited about the possibility of contributing further and helping the project grow.
Final Thoughts
Looking back, the most important step in my open-source journey was simply deciding to start.
My early contributions were small, but they helped me understand how open-source collaboration actually works. Over time, those small steps led to deeper involvement with the project and the people behind it.
If someone is thinking about getting started with open source, my advice would be simple: start small, stay curious, and don’t worry about understanding everything right away.
For me, this journey with OWASP BLT is still unfolding, and I’m looking forward to continuing to contribute and learn along the way.
Top comments (0)