My Open Source Fest Journey: Learning, Growing, and Understanding What Really Matters

Three weeks. That's all it took to completely transform how I think about open source software.

When I signed up for WeMakeDevs Open Source Fest, I was excited about the prizes (who wouldn't be?), but what I got was so much more valuable than any gadget. I got a crash course in what makes open source tick, what makes maintainers pull their hair out, and why sometimes the smallest decisions can have the biggest consequences.

The Beginning: Diving Into Kestra

For those who don't know, Kestra is an orchestration platform that helps you build, run, schedule, and monitor complex data pipelines. Think of it as the conductor of your data orchestra. During the fest, I focused on contributing to Kestra's plugin ecosystem, specifically working on Google Workspace and Microsoft 365 integrations.

My first major contribution was implementing a file created trigger for Google Drive. Sounds simple, right? Just detect when a file is created and trigger a workflow. Well, let me tell you about the journey from "sounds simple" to "oh, there's a lot more to this."

The "Aha!" Moment with Testing

Here's something nobody tells you when you start contributing to open source: writing tests is where you actually learn how your code works.

I mean it. When I started writing tests for the Google Drive trigger, I realized my initial implementation had a major flaw. The trigger was only returning one file at a time. But what if someone uploaded five files in between polling intervals? My code would just... miss them. Gone. Poof.

The reviewers caught it (shoutout to the Kestra team for their patience), and I had to refactor the entire output model to return a list of files instead of a single file. This meant downstream tasks could iterate over {{ trigger.files }} and process everything that came in during that interval.

That's when it clicked: tests aren't just about making sure your code doesn't break. They're about making sure your code does what users actually need it to do.

The Backward Compatibility Wake-Up Call

But the real learning experience? That came with PR #116.

I was migrating the CloudQuery plugin from state store to KV store. Seems straightforward, right? Just swap out the storage mechanism. But here's the thing that honestly never occurred to me before this moment: people are already using this code in production.

Real companies. Real data pipelines. Real workflows that run every single day, processing important business data.

When you change how state is stored, you can't just... change it. Users who upgrade to your new version might suddenly lose all their state data. Their carefully tracked sync positions, their incremental load markers, everything. And in data pipelines, losing state isn't just annoying, it's potentially catastrophic. You might re-process everything, miss data, or corrupt your downstream systems.

This is what backward compatibility means in the real world. It's not some abstract principle from a textbook. It's about respecting the trust users place in your software. It's about understanding that your code isn't just code anymore; it's part of someone's critical infrastructure.

The Kestra maintainers helped me understand how to handle this migration properly, ensuring that existing users wouldn't lose their data while new users got the benefits of the improved storage system. It was a masterclass in responsible software development.

The Gmail Integration: When State Management Gets Real

One of my most challenging (and rewarding) contributions was building out the entire Gmail integration for Google Workspace. This wasn't just a simple "send an email" task—I implemented Get, List, and Send tasks, plus a MailReceived trigger that automatically fires workflows when new emails arrive.

Here's where things got interesting: the trigger needed to track which emails had already been processed to avoid duplicates. Sounds simple until you realize you need persistent state that survives between trigger executions.

I spent about 6 hours (no exaggeration) trying to figure out how to persist the Gmail historyId between polls. My brain kept going in circles:

• How do I READ the previous state?

• How do I SAVE the new state for the next execution?

• Where does this data even live?

After what felt like forever, I finally figured out Kestra's state management system. The trigger needed to:

1. Read the last processed historyId from previous execution

2. Query Gmail for messages newer than that historyId

3. Process the new messages

4. Save the latest historyId for the next poll

Working on this taught me about API design, proper error handling, and how to write documentation that actually helps users. The back-and-forth with reviewers (especially François) was intense. We discussed:

• How to structure the output formats and use proper fetch types

• Handling edge cases like empty message lists

• Writing meaningful tests that actually validate the behavior

By the end, I'd written thousands of lines of code across multiple files, complete with comprehensive tests and examples. And it got merged! There's something incredibly satisfying about seeing your code become part of a project that thousands of people use.

The Community: The Best Part and the Frustrating Part

Here's where I need to be honest about something that's been on my mind.

The Kestra community during Open Source Fest was amazing. The maintainers were responsive, helpful, and genuinely invested in helping contributors succeed. François, Malay, and Anna provided thoughtful code reviews that taught me so much. They were patient when I made mistakes and celebratory when I got things right.

But here's the thing that bugs me: I wish this level of support existed year-round, not just during Hacktoberfest season.

Don't get me wrong, I understand why projects focus extra energy during these events. It's a great way to onboard new contributors and build momentum. But imagine if maintainers got this kind of support and recognition all the time. Imagine if companies that depend on open source software invested in ongoing maintenance, not just during October.

Open source projects are the foundation of modern software development. If we want these projects to thrive, to have good documentation, responsive maintainers, and high-quality code, we need to support them consistently.

The folks maintaining these projects aren't doing it for the fame or fortune. They're doing it because they believe in building something useful for everyone. They deserve our support, our appreciation

The Numbers (Because People Like Numbers)

During Open Source Fest, I

• Made x pull requests across multiple Kestra plugins (actually I didn’t count)

• Wrote thousands of lines of code (and even more lines of tests!)

• Fixed bugs, improved documentation, and added new features

• Had probably 100+ back-and-forth comments with maintainers

But more importantly, I learned how to be a better open source contributor and a more thoughtful developer..

To Anyone Thinking About Contributing to Open Source

Do it. Seriously.

Don't wait for the perfect moment or until you think you're "good enough." Start with documentation improvements, then move to fixing small bugs, then take on bigger features. Every maintainer was once a first-time contributor who didn't know what they were doing.

The community needs you. Your perspective matters. Your contributions, no matter how small, make a difference.

And to the maintainers out there: thank you 🖤. Thank you for the late nights, the patient code reviews, the detailed documentation, and the incredible software you build and maintain.

Final Thoughts

The prizes are nice 🤞🏼, but the real reward was the learning, the connections, and the understanding that when we build open source software, we're not just writing code—we're building something that brings people together and makes the world a little bit better.

Here's to more contributions, more learning, and more support for the open source community. Not just in October, but every single month of the year. Thank you We Make Devs and Kestra for organising this :)

Want to get involved in open source? Check out Kestra and join their Slack community. The maintainers are genuinely helpful, and there are always good first issues to tackle.

You can find my contributions on GitHub. Thanks for reading so far. Hope you’ve a great day :)