Hey folks!

As you may be aware, May is Maintainer Month, which makes it a great time to think about how you're using Open Source.

The Open Source we consume (and build) is never done in a vacuum - there are tonnes of people (maintainers and contributors) who are actively working towards the projects, building community, helping each other solve problems, reviewing code and squeezing it in between their day jobs, personal lives, and other commitments.

It was a year ago that we noted that we wanted to create a more sustainable model for oapi-codegen, and we thought this would be a good opportunity to reflect back on the last year.

I've got a blog post coming later in the month in partnership with the Open Source Initiative, so keep your eyes peeled (edit: #1990).

We'd like to say a huge thank you to our sponsors up until now:

Support from our sponsors has meaningfully changed things for the project, allowing better prioritisation and focus, and for instance my sponsorship from Elastic (my employer) allows me 4hr/month to work on it in work time - generally working towards solving issues that affect our usage of the project, but that absolutely benefit everyone.

And an honourable mention to Canonical, who are funding us through thanks.dev, an unnamed company who funds us through Tidelift, and a number of individuals who've sponsored one-offs - the contributions are very welcome, too.

Progress in the last year

A large amount of the sponsorship time in the last year has gone towards the general maintenance of the project, allowing me to prioritise this alongisde my other projects, blog, podcast appearances, personal life and busy job, to name a few things!

In the last year, we've had 6 releases with contributions from ~30 people:

• oapi-codegen v2.2.0
• oapi-codegen v1.16.3, deprecating the v1 release officially
• oapi-codegen v2.3.0
• oapi-codegen v2.4.0
• oapi-codegen v2.4.1
• nethttp-middleware v1.1.0 (+ 2 patch releases)

(A summary of the releases for oapi-codegen can be seen here, via the excellent OctoChangelog)

We're also gearing up for releasing v2.5.0 in hopefully the next week or two, but it depends on how much free time I have to tackle the last issues. You can see what's currently planned for this release here.

Although not something explicitly called out, another thing we did this year was made a start on defining the project's current governance, so it's clear to the community, and we can improve it over time.

In last year's post, we noted that there were a number of areas that we'd love to invest in, with sponsored time. How many of these have actually had progress, with the time in this last year?

Continue to work on community management, triaging and addressing issues, feature requests and discussions

The sponsorships we've received has been making progress towards this, but there's always more that can be doing.

Additional time to focus on the community will also feed into being able to use insights from OpenSauced as well as CHAOSS metrics

No progress was made on this.

Build out a proper documentation site, similar to Ogen's

We've not technically done this, but we have rewritten our docs from scratch (in our README) and now have a much higher bar for making sure that our documentation (and examples) are fleshed out for new contributions.

This does mean that previously raised PRs will have this retrofitted (usually by us, the maintainers).

Build a playground, similar to play.sqlc.dev, for oapi-codegen

No progress

Better plan out our roadmap Actually have a roadmap that we work towards

No progress - it's still "whenever I feel like I have time to get things ready for a release"

Further improving the stability of oapi-codegen by working with companies and developers to better understand their usage - for instance on a video call - which would then feed into our existing test suites

No progress - if you're interested, please reach out!

Improve tooling and libraries that sit alongside oapi-codegen

I can't actually quite remember what I meant about this 🤔 I think this is for projects under the oapi-codegen GitHub org, but may also be for some of the projects we rely on, too.

Work providing support for OpenAPI 3.1, by taking the libopenapi support and fully integrating it

This is a huge piece of work, and cannot be feasibly started until we've got some significant sponsorship, especially as it'll then duplicate the work we need to handle (for both kin-openapi and libopenapi).

Work towards bug fixes + feature improvements

There's been a lot of work on this in the last year - but many more to go.

I think a lot of y'all would be surprised that it can take ~2-4 hours to get a single issue closed - consider that at time of writing we've got 505 issues and 172 PRs.

Provide a (monthly?) planned release cycle that can be depended on

As above, no progress on consistency in our releases.

Making prebuilt binaries

No decision made on this, yet

Paying it forward - taking money we receive and sponsoring projects we heavily rely upon

This is still on my TODO list - perhaps during this Maintainer Month 🤞🏼

A next-gen ability to customise the generated code which should make it much easier for specifications that you don't control

This was achieved through the implementation of OpenAPI Overlays, in v2.4.0 and has changed the way that I'll interact with OpenAPI specs I don't own. If you're not using it, you're missing out!

Supporting backports to older versions, when customers require them

No progress, due to no sponsorships with that in mind.

What's next?

• I'd love to make some progress towards OpenAPI 3.1, but that can't come without significant time investment (aka would appreciate that being explicitly sponsored)
• Complete some outstanding fixes on nethttp-middleware, and then roll out changes to make all middleware more consistent based on recent changes in the nethttp-middleware
• Work towards the next milestone
• Maybe get us down from ~500 issues to ~400?
• Document our security policy, Code of Conduct and when we'll update dependencies for CVE fixes
• Add "presets" functionality to have on-by-default best practices

Call for more sponsors

We'd hugely appreciate any and all additional sponsors to help with the project's maintenance.

It doesn't have to be a monthly subscription - there are opportunities to donate one-offs with custom amounts on GitHub Sponsors.

Looking forward to seeing where we get to in the next year, and hearing any feedback below!