The future of the JSON schema gem

[iainbeeston]

@ruby-json-schema/owners

I have a lot of ideas for refactoring, modernising and slimlining the json-schema gem, as well as adding support for draft 6, 7 and eventually 8. However, I know everyone is busy and reviewing pull requests for json-schema isn't always a high priority.

I'm concerned that the project has become neglected, and with that in mind, I feel that someone needs to step up to take a bit more of a lead to steer the project into a better place. I'd be happy to be that person, and would be prepared to take on the responsibility of making sure the project is well-maintained in the future.

Could you please let me know your thoughts on the idea of me taking the lead on the json-schema project, which would entail cleaning it up and refactoring it as I see fit, and merging pull requests without the agreement of another maintainer. If nobody objects, I'll assume that everyone is busy with other things and is happy for me to push the project forward alone.

Finally, if you're no longer interested in maintaining the project and don't wanted to be "pinged" by contributors on issues or pull requests, let me know and I can change you from being listed as an "Owner" to a "Contributor".

[RST-J]

I'm fine with you taking the lead as proposed. Although I probably do not have much time to put into the project (and have been absent for about 1.5 to 2 years for personal reasons), I'd try to help with reviews if possible. Maybe also get back into development but I don't want to promise something I cannot keep.

[we4tech]

Hi @iainbeeston Let me know if I could be any of your help?

[k-rudy]

Hey @RST-J, any decision on the suggestion from @iainbeeston? I see many non-considered PRs and issues and that scares us to keep using the gem in production. Could you please update us on what has been decided?

[iainbeeston]

I've been thinking about this more since I opened the issue, and I've realise that I was being unrealistic. I have a lot of other projects competing for my limited time, on top of work and family life. I would love to bring this project up to date with the latest json schema drafts and refactor it into something more maintainable and see it progress into the future, but I can't spare enough time to make that happen.

Perhaps instead this thread should start the search for new maintainers?

[iainbeeston]

Is anyone interested in becoming a maintainer of json-schema?

There are a lot of open pull requests that need merging, but it's important to understand how they fit into the existing codebase before merging, as they might introduce new issues (the existing test suite is not comprehensive for more complex schema, such as loading from uris or fragments - see #248). Also the gem supports a number of unofficial extensions to the specification (such as default values) that add complexity.

Any maintainer should have a good understanding of the json schema specification. The most recent release of the json schema gem only supports the specification up to draft 05, but draft 06 and 07 have been released since, and 08 is scheduled to be released some time after June 2019. Although the code supports modular validation rules (that can be added and removed for different versions of the specification) and we can use the json schema common test suite to test compliance, I believe that adding support for drafts 6 and 7 will not be a trivial change.

If you're interested in becoming a maintainer please let us know on this issue.

[scalp42]

I came across https://github.com/davishmcclurg/json_schemer which supports up to draft 7.

@davishmcclurg what's the rationale for creating a different gem if you don't mind sharing? ☮️

[iainbeeston]

There's also https://github.com/brandur/json_schema

There are a lot of json-schema implementations out there in many different languages (although most of them are written in javascript)

[davishmcclurg]

Hey y'all. I created json schemer to get better performance and draft 7 support. Performance was a big thing I thought could be improved at the time. I was generating schemas for API validation and the overhead of this gem wasn't acceptable. If those things could be improved here, I'd happily deprecate my gem since I also don't have a ton of time to support it.

[RST-J]

To be honest, it is worse than I wrote last October. I do not have the time (or more honest, have other stuff that is more important to me) to even look at the PRs handed in here. I could do quick review stuff but that wouldn't meet my view of quality standards.
So, I'll do officially what actually already happened, given what I did (not) in the past: I'm stepping back from maintaining json-schema.

The sad thing is, it seems like there is no one who wants to keep up the development. Maybe one of the other two gems can/will go on. Given the architecture of json-schema it is probably easier to improve one of the other to support more standards (if they don't do it already) and have better performance (afair are json-schema benchmarks rather slow).

@iainbeeston how should we proceed with this?

[iainbeeston]

I'd recommend we at least put a disclaimer at the top of the readme, warning people that the gem is no longer maintained. It's also possible to put a post_install_message in the gemspec to warn anyone installing the gem that it's no longer supported, although I worry that this could be confusing if (in future) someone takes over maintenance and tries to revive it.

My advice to @brandur (author of json_schema) and @davishmcclurg (author of davishmcclurg) would be to add the json-schema common test suite to their tests if they haven't already (we have code in json-schema for doing this and that could be copied), as that's an easy way to be confident that any implementation adheres to the official spec. So long as there are some ruby implementations that match the spec, it shouldn't matter to anyone whether it's json-schema or any other gem, and it should be easy for people to migrate away.