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.

[damacus]

Is there any way we can improve this situation? I've seen this pattern many times before.

It looks like both Voxpupli and Sous-Chefs use this Gem day to day, and are used to running repositories that were once loved but don't have a current active contributor. I wonder whether something similar to their collectives could be done for this and other Gems?

As long as we can decide what good looks like, then I think we can keep this Gem updated and keep the quality as high as desired by @RST-J. All we would need to start is a small group of interested parties to join this org, and start adding in tests.

Sorry if this is a bit presumptuous. But hopefully this stirs something into action.

(see Vox Pupuli and Sous-Chefs for their repos)

[scalp42]

@damacus might want to move to https://github.com/davishmcclurg/json_schemer as it's maintained

[bastelfreak]

Hi, if this helps, Vox Pupuli could keep maintaining the project in their (our, I'm part of Vox Pupuli) namespace. We're happy to help.

[iainbeeston]

@bastelfreak I’d be happy to do that, if no one in @ruby-json-schema/owners objects. If I don’t hear anything from any of the other maintainers I’ll assume they don’t mind, and I will transfer this repo over to the box pupuli organisation.

[bastelfreak]

sounds good to me!

[scalp42]

@bastelfreak can we prevent the divide here with @davishmcclurg?

[RST-J]

@iainbeeston I would have suggested the same, so just do it. I think we both were the only ones to respond the one or two times when something about the future of this project came up, so I do not expect any reaction and even less objections from others in here.

Would be glad if it is taken over. :+1:

[bastelfreak]

@iainbeeston I invited you to the Vox Pupuli GitHub org so you're able to migrate the repo. @scalp42 sorry, but I'm not sure if I can follow. Divide from what?

[scalp42]

@bastelfreak davishmcclurg/json_schemer is already maintained

[iainbeeston]

@bastelfreak Thanks for adding me to the vox pupuli organisation, however I need the permission to create repositories before I can transfer it. Can you set that up for me please?

Can I also confirm which rubygems user I should transfer the gem to? Should it be “voxpupuli”?

[bastelfreak]

can you check the permissions again? You should be able to transfer the repository. The rubygems user is voxpupuli.

[iainbeeston]

@bastelfreak I’ve tried again but I’m afraid I still get the same error when I try to transfer the repo to voxpupuli

[bastelfreak]

can you check your inbox/github settings? You need to accept the invitation for voxpupuli first

[iainbeeston]

@bastelfreak My bad, I assumed I wouldn't need that. Could you please send another invite (the first has expired) and I'll try again

[bastelfreak]

sure, I sent it again.

[iainbeeston]

@bastelfreak I've transferred the repo and invited voxpopuli to be an owner of the ruby gem. Can you confirm both are correct?

[davishmcclurg]

Hey again all, I'm the maintainer of another ruby json schema implementation: davishmcclurg/json_schemer. I'm curious if there's any interest here in somehow combining our efforts. I recently released a new version that supports the latest drafts, but it took me a few years before I found the time. I see that work here seems to be picking up a bit and I'm wondering if it makes sense to focus on one gem or the other so that we can better keep up with json schema in the future. I haven't thought too much about the specifics yet, just wanted to gauge interest first. Let me know what you think—and, of course, it's no problem if you prefer to keep the projects separate.

Related: https://github.com/davishmcclurg/json_schemer/issues/142

[pboling]

FWIW, I'm in the process of re-writing json-fuzz-generator from depending on this gem to depending on @davishmcclurg's json_schemer. Once I'm done with the rewrite I'll rename and re-release the gem.

[ekohl]

@davishmcclurg I can't speak for others, but I think at this point this gem isn't receiving the attention it deserves. Vox Pupuli is set up to support a team of maintainers, but at this point I'm not sure people are actively doing so. I think an ecosystem is best served by a single implementation that's well maintained.

Moving forward, I think either people (preferably multiple) should stand up and really own this gem, or formally suggest json_schemer as a replacement.

If people are interested in the former, as a member of the Project Management Committee (see https://voxpupuli.org/elections/) I can help set that up.