Roadmap/where is this project headed?

[marefr]

Hello and thanks for a great project.

I have been experimenting a bit with this lately and I have some feedback/questions where this project is headed. I really like and enjoy the handler interfaces generated, makes total sense, but I feel this project might try to do too much, rather than sticking to the core OAS functionality while being open for extension.

Others and including me are asking where the roadmap went, #1363.

I see quite a lot of issues and discussions asking about custom features, questions about generated code customizations, to name a few:

• Recommendations for splitting a large API into multiple handlers? #1181
• Optionally trading performance for smaller generated code footprint? #1395
• ease of collaborative work: file per schemas, client, server methods #1339

You do have a way to enable/disable certain features which is great, but I still see a few drawbacks with this approach and I have some feedback/questions below:

• Every single customization needs a feature flag (except custom OAS headers)
• In general I fear this project might eventually try to do too much and become bloated with features and dependencies. Or that you eventually have to say no to new features.
• Generated code depends on github.com/ogen-go/ogen which in turn depends on some 3rd party libraries that might or not might be used in the generated code which might lead to dependency versioning problem for users.
• [General limitation] There's no easy way to extend/customize (hook into) the code generation besides above mentioned feature flags which probably adds more and more of a burden on maintainers, code generation bloat and possibly frustration of users that might require custom forks.
• [minor] Not possible to enable/disable feature as arguments to ogen tool, configuration file is required.

Coming back to the roadmap, if there is any, is your goal to support anything and everything besides OAS or do you want to keep things to the core?

I do have a few ideas how we might be able to open up the code generation to be open for extension if you're interested? Taking ideas from protobuf generators or Hugo's broad templating support might be interesting approaches.

With a greater flexibility of extending the core then, for example, existing features such as OTEL and request/response validation could be hooked in as extensions extending the core code generation or just simply register as middlewares.

Keeping the core lean while still allowing custom extensions. Is there any plans or interests in this? I'm available and interested to help out in that case, just let me know.

Thanks again