Hey folks, something I've been working on (behind the scenes) for a little bit is trying to get on top of the backlog that oapi-codegen has, and where we should be (starting to) focus our efforts.

As of writing, the prioritised list of changes that @oapi-codegen/maintainers will be looking at are:

• Some behind-the-scenes and visible changes to our supply chain security
  • including some changes that mean we will be able to more safely onboard new maintainers (in the future)
• Gin middleware
  • There are a number of very much overdue changes that need to be performed on the Gin middleware
• net/http middleware
  • Completing outstanding issues on the "Issues for all middleware" functionality
  • Then, we'll look at how we want to roll this out across the other middlewares
• Fiber v3
  • The yet-unreleased v3 release of Fiber
    • Codegen: add fiber v3 support #1937
    • Add fiber v3 support, update dependencies fiber-middleware#33
• Improving support for discriminators
  • fix codegen for same type used with multiple discriminators #2108
  • Support unions with multiple mappings pointing to a single underlying type #2071
• Adding the ability to add per-endpoint middleware

Lower priority but still on our minds:

• Ensuring consistency around the different servers and functionality available
• Adding an Issue Template
• Looking at options for improving our triage + review process

There are also some features we'll prioritise, if they arise, related to:

• adding new features to allow oapi-codegen to work better with new Go versions
• upgrading to OpenAPI 3.1 (and/or OpenAPI 3.2)

Sponsorship

As a reminder, "on paper" we have 2 maintainers, but at present, I'm the only maintainer who currently has time to work on the project.

This is an incredibly widely used project, and as noted in #1990 #1985, there's a lot of work in the project, purely to look at the open Issues, let alone fix them, or review the new PRs coming in.

One way you can get an issue more highly prioritised is to sponsor our time on the project - either one-time or on a recurring basis.

This is not intended to be "pay to play", but there are a lot of companies who benefit from the work we do on the maintainer team (as well as tonnes of hours of contributor time over the years)

If your company needs the features, then being able to make a case to pay i.e. for 3 hours of work for the maintainers to work on it upstream isn't too bad overall, for a lot of companies.

Meta: why can't I reply to this?

The intent here is to indicate what the current plan is for the maintainers.

We don't intend for this to be a direct way for folks to feed back on the current plans.

As above, if you're looking to a help with roadmap planning - please don't @-mention maintainers on issues, as we're trying to make it clear that "noisy users" don't get preference over "polite users".

We are putting things in place to look at expanding out how many folks can help with the project - please bear with.