Contributing Upstream Instead of Forking: My grape-swagger-rails Story

Recently I had a chance to contribute to grape-swagger-rails, helping modernize the project and release v1.0.0.

Even the interaction model and styling clearly showed its age.

The Typical Company Solution: Fork It

In many companies I worked with, the usual approach for issues like this was:

• create an internal fork,


• patch the problem locally,


• never contribute changes upstream.

Honestly, that's often the fastest short-term solution.

But this time I wanted to try something different.

Contributing Upstream

Instead of maintaining another private fork, I decided to contribute directly to the project.

I reached out to the grape community and started working with maintainers, especially @dblock.

Together we:

• upgraded the Swagger UI integration,


• improved compatibility,


• modernized the frontend,


• fixed bugs,


• and prepared a major release.

That work became:

• grape-swagger-rails v1.0.0


• followed by two additional bug-fix releases.

The Result

The project now ships with a much more modern Swagger experience.

After

Becoming Part of the Community

One thing I definitely didn't expect when opening my first contribution was eventually becoming part of the grape team.

That was honestly a very happy moment for me.

This experience reminded me that contributing upstream can have a much bigger impact than solving problems only locally.

Links

• Project:
  


• Changelog: https://github.com/ruby-grape/grape-swagger-rails/blob/master/CHANGELOG.md#100-20260509
  

Big thanks to the grape community and especially to @dblock for the collaboration and support throughout the releases.