We’re looking for a new lead maintainer for yojson, ideally with the support of their employer who can use the opportunity to give back to the community and attract talent. Yojson is a direct dependency of 89 opam packages.
I created yojson in 2010 to replace json-wheel as part of an effort to improve the performance of serialization code derived from type definitions. This was done at the time by json-static, a camlp4-based syntax extension. Specifically, yojson exports efficient functions for parsing and printing json elements directly without going through an AST, unlike its predecessor. This allows a type-driven code generator like json-static’s replacement atdgen to produce efficient parsing and printing code. In addition to this, yojson also provides a json AST like json-wheel used to. This AST can be manipulated directly and widely used by people who haven’t found out about atdgen or haven’t figured out how to set it up. It can also be genuinely useful as a last resort for handling untypable json data where needed.
Yojson is stable and requires light maintenance, typically less than one day per month. It’s up to the new maintainers to decide where they want to take the project in terms of new features, documentation, and community involvement.
As I mentioned for cppo, it may be possible, if we can’t find just one person willing to maintain it, to have a team of people in ocaml-community take responsibility for merging pull requests and seeing to it that the code remains compatible with future OCaml releases.
I find that a difficulty in maintaining a package is that requests from users and from contributors come at unpredictable times and require an unpredictable amount of work. Handling these requests promptly is important but creates an interruption in the work day of the recipient. Minimizing interruptions is an essential problem in software engineering, and I don’t think there’s a perfect solution. Things that can help include:
Having multiple maintainers per project, and multiple projects per person: I highly recommend people to join ocaml-community on Github and to standardize practices across projects so that everyone can help. This ideally allows people to take a task from a queue rather than being imposed a task at an inconvenient time.
Talk to your manager and have them agree that you spend some amount of your time helping with open-source projects that the company uses.
Join companies with an official policy that defines and encourages contributions to open-source software.
I’d definitely be interested but I need to get Cryptosense’s approval first as I’m not sure I’d be able to do a good job maintaining it on my free time.
Big thanks to you and to Cryptosense!
I certainly have a lot of generic recommendations but nothing specific to yojson. The generic recommendations revolve around making the job as efficient and pleasant as possible:
Share volunteers with a larger community (ocaml-community in this case) so as to shorten response times on issues and pull requests. This requires normalizing project structure and processes across projects.
Work toward making it easy for others to contribute (label issues as they arrive, use an easy/popular development setup, create templates for bug reporting, be upfront about criteria for accepting code, discourage pull requests for new features without a preliminary design review of the feature, …)
Work toward making it easy for maintainers to review and accept requests (some of the same stuff as above; ensure any incoming request is simple and doesn’t require the maintainer to redo all the work)
In terms of new features and creative thoughts, it’s probably best to discuss with users. Personally, I’ve always been dissatisfied with the lack of a compact, javascript-like syntax for browsing untyped json data. If data is a json tree of type Yojson.Safe.json, it shouldn’t take more than data[i].foo.bar to do what this looks like.