Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Status and support

Open
#375 3 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
10/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
python

Research direction

No files, tests, or code entry points are named. Read the issue and its three-comment thread first, then review the repository's current activity and support situation; this is done only when maintainers decide whether and how to grow the core developer team.

Written by the indexing model from the issue text.

Description

Hi @p1c2u,

First of all, I’d like to express my appreciation for this library and the work you and the community have invested so far. IMHO, this is conceptually the best approach to leveraging OpenAPI server-side, i.e. implementing request/response validation and unmarshaling completely independent of a particular web framework, which makes it reusable, and offering adapters and extensions/middlewares for some popular web frameworks. This is a beautiful separation of concerns which many other projects are lacking. If it was up to me, all other OpenAPI server related projects should build on openapi-core (and your related projects) and not reinvent the wheel over and over. One of those projects I mean is Connexion which, as far as I can tell, is the most feature-rich OpenAPI-first solution for Python at the moment and quite popular. But it’s a monolith with regard to its OpenAPI-related code, so that community is maintaining a non-reusable implementation just for this one project. And with newer releases of the OpenAPI spec, e.g. v3.1, all those projects will take a long time for adding support because forces are not joined.

I think openapi-core should be the common foundation like, e.g., jsonschema is pretty much used everywhere where JSON Schema validation is needed. But for this to become a reality, I believe openapi-core needs to mature a bit more, add some missing features, become more reliable in terms of activity and community management, and then a ton of communications work will be needed for convincing projects like Connexion to adopt it and drop their own implementation. I imagine this is just a side-project for you and you’re managing it in the best way possible, time allowing, that’s why I’m wondering whether you’ve been considering to grow the core developer team.

I fully believe in the value and the benefits of OpenAPI, and that’s why I’m generally puzzled why the OpenAPI-related tooling across numerous popular programming languages is in such bad shape. I’d love to see it improve, particularly for Python, and that’s why I’m reaching out. 🙂

Dominant language
Python
Stars
368
Forks
140
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python-openapi/openapi-core

All issues in python-openapi/openapi-core

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.