My First Open Source Release Contribution — What OpenChoreo Taught Me

A few years ago, I thought open source was simply about fixing bugs or adding new features.

After contributing to OpenChoreo, I realized that open source is much more than writing code. It is about learning from experienced engineers, understanding how large software projects are built, and improving yourself through collaboration.

Recently, I was excited to see my contributions included in the OpenChoreo v1.2.0-rc.1 release. Seeing my GitHub username in the contributors list may look like a small achievement, but for me, it represents months of learning, debugging, reading code, and improving through code reviews.

The Beginning

When I first looked at the OpenChoreo repository, I honestly felt lost.

The project was much larger than anything I had worked on before. There were controllers, APIs, Helm charts, workflows, tests, CI pipelines, and many directories that I had never seen in a single project.

At first, I thought I needed to understand the whole codebase before contributing.

I was wrong.

Instead, I learned to understand one issue at a time.

One function. One package. One pull request.

That made everything much more manageable.

Every Pull Request Was a Lesson

One thing I really appreciate about OpenChoreo is the maintainers.

They didn’t just review my code and click “Merge.”

They explained why something should be changed.

Sometimes they suggested a cleaner approach.

Sometimes they pointed out edge cases that I had completely missed.

Sometimes they shared better ways to structure the code to match the project’s standards.

Those review comments became one of the best learning resources I have ever had.

Every pull request taught me something new.

I wasn’t only fixing issues. I was learning how production software is designed, reviewed, tested, and maintained.

Thank you to all the maintainers who spent their valuable time reviewing my pull requests. Your feedback helped me improve as a developer, and I learned a lot about industrial software development standards through every review.

Learning Beyond Writing Code

Before this experience, I thought software engineering was mostly about writing code.

Now I see it differently.

A good solution is not just one that works.

It should also be easy to understand, maintain, test, and fit naturally into the existing project.

Sometimes I spent more time reading existing code than writing new code.

Sometimes fixing a bug took only a few lines of code after hours of understanding how that part of the system worked.

That completely changed how I approach programming today.

My Contributions

During this journey, I had the opportunity to contribute to different parts of OpenChoreo, including workflow validation, API improvements, Helm configuration, CLI enhancements, controller logic, and several bug fixes.

• feat(cli): add resource to occ config context scope by @kavix in https://github.com/openchoreo/openchoreo/pull/4145
• feat(helm): enable WebSocket upgrades by default on KGateway by @kavix in https://github.com/openchoreo/openchoreo/pull/4080
• fix(helm): gate KGateway TrafficPolicies on gatewayClassName by @kavix in https://github.com/openchoreo/openchoreo/pull/4079
• fix(controller): cascade Resource deletions and surface precise finalize statuses by @kavix in https://github.com/openchoreo/openchoreo/pull/3917
• feat(helm): make gatewayClassName configurable in control and observability planes by @kavix in #3915
• fix(controller): set workflow failed condition on validation failure by @kavix in #3877

None of these contributions were made alone. Every merged pull request was the result of discussions, review comments, suggestions, and guidance from the maintainers.

That collaboration is what makes open source so valuable.

More Than Just a Green Checkmark

Getting a pull request merged always feels good.

But what stayed with me the most wasn’t the green “Merged” button.

It was everything I learned before reaching it.

How to understand an unfamiliar codebase.

How to communicate with maintainers.

How to improve code after reviews.

How to write software that follows existing project standards instead of personal preferences.

These are lessons that are difficult to learn from tutorials alone.

Looking Forward

This is only the beginning of my open source journey.

There is still so much to learn, and I know I am far from being an expert in Go, Kubernetes, or cloud-native technologies. But every contribution gives me another opportunity to improve.

I’m grateful to the OpenChoreo community for creating such a welcoming environment for new contributors and for sharing their knowledge through every review and discussion.

I hope to continue contributing, learning from experienced engineers, and giving back to the open-source community that has already taught me so much.

Thank you to everyone who reviewed my pull requests, answered my questions, and helped me become a better software engineer.

Here’s to many more contributions ahead.