Need more maintainers / contributors

[philsturgeon]

Hey folks, trying to get a v10 out at the moment but we're blocked on #268 and #283 so if you can get to that I'd really appreciate it.

As a larger thing, I am struggling with doing far too many jobs, including trying to grow an entire reforestation charity which is planting thousands of trees and managing multiple woodlands all over the country. It's a LOT and I cannot be throwing any/much more time on maintaining OSS stuff I don't even use for anything.

See more over here: https://phil.tech/2022/bundling-openapi-with-javascript/

tldr we need to either

1. get some enthusiastic fresh blood in here as maintainers.
2. find an alternative library that's got feature party and I'll start the deprecation and redirection process, helping write migration guides.
3. revive the json-schema-reader rewrite to handle big ticket items like "$id" and "$ref" changes in JSON Schema draft 2019-09 and OAS 3.1 #145.
4. y'all start throwing a whole load of sponsorship money in here and I'll contract out the work.

Discuss!

[philsturgeon]

There is a new effort from the JSON Schema crew on getting everyone aligned on what $ref is meant to be about, how it should work across OAS and JSON Schema, etc.

https://github.com/json-schema-org/referencing

Probably relevant. No brainspace to try.

[philsturgeon]

Specifically first I would appreciate help getting #288 over the line, more context #290.

[jonaslagoni]

We are still discussing what to do for AsyncAPI (regarding references in general) but wanted to give you our current dilemma, before your deadline, to get your thoughts on the situation @philsturgeon.

The main reason we are looking towards this library is that we need it for our parser (indirectly in Spectral, which we also help maintain).

You can find the full discussion we are having here, regarding requirements for ref resolvers in general, both functional and non-functional requirements, but here is the TLDR (if we were to help out, as the library in its current state dont quite fit into our use-case):

• Change focus from JSON Schema to resolving references for any JSON format, where the standard/behavior changes based on context (of course still support resolving references for JSON Schema). This will add support for
• Based on the above change, the name of the library probably doesn't make much sense anymore.
• Ideally, it would be great to work together on this on a neutral ground (wherever it makes the most sense), to have clearly defined ownership and processes in place when/if things go south to not hurt the community building the tool (sorry, doomsday minded 😄). But also so it's a place for AsyncAPI, JSON Schema, and OpenAPI communities to work together.

We are of course still discussing requirements and use cases, etc, but did not want to leave you hanging here without providing some feedback before your deadline.

Would love to hear your thoughts on the above "issues" and whether we can get aligned 🙂 Also happy to jump on a call if you'd like a better explanation of our situation.

[jcmosc]

Hey @philsturgeon, curious what the plan here is. I realise I'm asking at the 11th hour...

I recently left my job to focus on building an API design platform this year. So I'm happy to help out as a maintainer. Though my focus for OSS is going to be over at https://github.com/criteria-labs/criteria-api-tools. It's not going to get up to parity for some while yet though as I am prioritising certain features over others.

Though looking at the changes in recent specs, e.g. how $ref is now treated as delegation instead of inclusion, plus differences to OpenAPI Reference and other places $ref appears in OpenAPI. I think a wholesale redesign or new project is inevitable.

[philsturgeon]

Thankfully @jonluca has given this project a new lease of life handling maintenance. I'll leave its future up to them, but I am going to close this issue as the ultimatum is no longer relevant.

[relu91]

Thankfully @jonluca has given this project a new lease of life handling maintenance. I'll leave its future up to them, but I am going to close this issue as the ultimatum is no longer relevant.

I'm evaluating using this library for a project, does this mean that the warning message in the Readme is now obsolete?

[philsturgeon]

@relu91 yep! removed that message.