I'll break the exciting news right away: I'm joining Postman to work full time on JSON Schema!

I'm pretty excited. This is huge not only for the future of JSON Schema but for me, personally, too. You might have some questions, in which case I can hopefully answer them here.

First and most importantly: this will not affect the governance of JSON Schema in any way Postman does not and will not seek any ownership over JSON Schema. The specification will maintain its status as an IETF draft publication for the foreseeable future. Everyone involved is committed to maintaining the existing, open development strategy.

Controlling JSON Schema is not in the strategic interest of Postman. The company has an Open Philosophy and already contributes in multiple ways to the open-source community. Postman's CEO has written before the importance of Open Source and how "data interoperability is critical." Seeing stable, sustainable development of open standards is important to Postman, taking control is not. Postman succeeds when the ecosystem succeeds — a rising tide lifts all boats equally.

If you're following the API space, you'll probably have seen AsyncAPI recently partnered with Postman. AsyncAPI have their own "AsyncAPI Initiative" organisation which houses their work and are looking to join a foundation. It's been great to hear and see the work Fran and the team have been doing since the Postman announcement, and I'm excited to follow on a similar path.

I intend to put to the JSON Schema team a proposal to join the OpenJS foundation in the near future. I've had a pretty good track record achieving or predicting success with previous initiatives of this nature. I am confident that this move aligns with the goals of the JSON Schema team and project and will be supported.

JSON Schema organisationally is a little different to AsyncAPI, who have already been working full time to create the specific.

JSON Schema is a loosely governed collective of individuals, across multiple time zones and working days, mostly alive during evenings and weekends. In absence of writing our own governance policies, we've tried to follow a guiding principle of “general consensus” used on the authorship of IETF specifications.

As anyone who works on open source in their own time will tell you, working a day job and then delving into further complex issues at 10pm isn't always easy. Especially if you also have a young family. You've got to really want to make it work and believe in what you're doing. The work is important and rewarding, but that's sometimes all the thanks you get.

I confess I've often found myself feeling like my day job was an obstacle to dedicating the time to JSON Schema that the community needs and deserves. I had previously considered the possibility of getting sufficient sponsorship to meaningfully work on JSON Schema, but the support just isn't there. Postman came along at the right time. Working there will mean not only that I'm able personally to give JSON Schema the time and attention it needs, but I'll also have help from a number of smart, dedicated co-workers. It's going to be great working alongside my new colleagues from AsyncAPI. I'm excited to see what we learn from each other!

I'll be working with Kin Lane, primarily to establish a path forward for JSON Schema, but also to help and advise multiple industry sectors on the effective use of JSON Schema. And of course, I'll be steering how Postman implements and interacts with JSON Schema itself, especially now OpenAPI 3.1 fully supports JSON Schema 2020-12.

Kin has been working out some sort of grand plan for a while, playing the API space like a very long game of chess, and JSON Schema is a key piece on the board. But, even with Kin's best game hat on, it's clear to see Abhinav Asthana and the team at Postman have ultimately made a large impact not only on how many developers build APIs. Now they want to give stable foundations to standards and technologies like AsyncAPI and JSON Schema.

In some ways, my work at Postman will be no more than a faster paced continuation of my existing work. I've had lots of ideas on the back-burner for a while. I've established a few connections in standards bodies that are having a real impact. I can't wait to accelerate the rate of progress in all of these areas and more.

I have no idea what the induction process at Postman looks like, but I plan to spend some time in the first week or so triaging existing JSON Schema issues, establishing teams and roles, and make a start on the process of joining the OpenJS foundation, assuming they will have us. Having looked into the prospect of joining the OpenJS foundation before, we (or at least I) were trying to compare with IETF and W3C. With the expectation of more software and tooling from JSON Schema, I've realised joining the foundation doesn't prohibit the publication of the specification being processed by a standards organisation.

There's going to be a roadmap, and several other community related updates, but you can be sure as many items as possible and that makes sense, will be up for discussion by the team.

And of course, as I've mentioned a few times before, the JSON Schema community has pulled together in a big way to make this possible. I'm so proud to be part of such a great team! There are no words sufficient to the task, so "thank you" will have to suffice.

Here's to a bright future for JSON Schema and the API landscape as a whole.

Thanks

Ben

-—

JSON Schema Open Collective: https://opencollective.com/json-schema

My personal support channels:

This update is cross-posted on the above sponsorship platforms.

P.S. I'm still writing a book, so stay tuned!

Photo by Greg Rakozy on Unsplash