Report and proposal on joining the OpenJS Foundation

[Relequestual]

The OpenJS Foundation is a Linux Foundation organisation focused on the Javascript ecosystem, looking to support projects and foster the development of the community and ecosystem.

On 2021-04-20, I met with Scott Nicholas, Robin Ginn, and Jory Burson, representing the OpenJS Foundation and the Linux Foundation.

I want to share with you my thoughts and reactions as a result of the meeting and further research.

You can watch a recording of the session using the following link:
https://postman.zoom.us/rec/share/1B6bU6RM2WxSNueb3zOSHUzxH2wxNyHQ4vvjKK0A6waT0xPYEbnnF8Sw6X6oRKMt.dSgEpYxtKRtsZcan

Read the report here...

I had previously reached out to the JS Foundation (it has since merged with the Node Foundation), and was impressed with the onboarding requirements. I say impressed because you aren't left to complete all the requirements on your own, but they offer support in order for you to meet those requirements as an open source project.

Let me walk you through a recap of why we're at this junction, and how the OpenJS Foundation can help elevate JSON Schema and aid it moving forward.

Formalisation

JSON Schema is run largely by the community. A small number of individuals fell into leadership positions and continued to publish the specification through personal drafts in the IETF. As it became more noticeable that the project hadn't simply died, or at least had a new lease of life, the community once again asked, when will JSON Schema become formalised?

While generally formalisation is a signal of maturity and stability allowing other formal specifications to reference them, JSON Schema has done a lot of growing up in the last 5 years, and has gained ubiquity for validating JSON data. Strictly speaking, an IETF personal draft should not be used in production, but you'd be hard pressed to find someone woking with APIs that doesn't recognise how JSON Schema offers unparalleled interoperable validation for JSON instances.

While we aren't as front and centre as other specifications or even the libraries that implement the specification, we've seen huge growth in the community, and focus on community is increasingly important for the next phases of JSON Schema.

Safeguarding

This year I was fortunate enough to be offered a full time position at Postman to allow me to focus on JSON Schema. While some of you know me well enough to know I'll safeguard JSON Schema from any ownership by Postman, many of you don't know me, and if you're to use JSON Schema as a standard in your own project or product, you don't want to worry that it might only work with Postman in the future.

While it's true Postman may gain advantage from having me on hand to answer questions and provide product feedback, that is by no means how I spend most of my time, and Postman want to maintain their existing open source reputation.

Having JSON Schema join the Open JS foundation makes sense for safeguarding purposes. Should something truly wild happen at Postman, JSON Schema is still safe, and able to operate as we are already doing.

Avoiding misunderstandings - operations and governance

As our organisation grows, we will face various operational and governance challenges. You could ask, do we need to grow beyond simply providing the specification? That depends.

I believe JSON Schema is the best in class solution for its problem space (that's why I wanted to contribute in the first place), but still doesn't provide tooling or have ubiquitous adoption or buy-in from the majority of major venders. There are other solutions people may use, however I don't believe any are as flexible and powerful as JSON Schema for the use cases we want to support.

My hope is that other companies like Postman will agree on the value JSON Schema offers the community and the larger ecosystem, and look to sponsor individuals to work part or full time on JSON Schema. Recognising our already very international team, documented operational processes help avoid misunderstandings that could potentially arrive via cultural differences. A Code of Conduct will help, and having a vast experience of other project leaders and teams to support us in other decisions will save us from making mistakes, allowing us to focus on our primary goal working on JSON Schema.

Financial and legal

We have some finances. We don't have any policy on how they should be spent and who has the authority to approve spending. We could do with legal advice in terms of the name and logo.

Maybe we want to support individuals developing implementations or associated tools. Maybe we want to pay for some new graphics for a website. The only way we would currently do this is based on myself or someone else who has access to the funds hoping it looks like I'm doing the right and honest thing.

Reach, promotion, and elevation

While JSON Schema often feels ubiquitous, it's easy to forget we (the people reading this), likely move in circles who are well informed about JSON Schema and APIs. And, while there is a level of ubiquity with APIs, other use cases need a lot of work to standardise confidently, showing users how flexible yet reliable JSON Schema can be.

I outlined in a little detail in my recent talk at APIDays Interface 2021 (https://www.youtube.com/watch?v=im_uu_9p7Jo) why we need to extend our lines of communication, and extending our reach on social media can play a part in that.

You can read more about the OpenJS Foundation and whey offer here: https://overview.openjsf.org

What does it look like?

OpenJSF have four categories of projects: Impact, At-large, Incubation, and Emeritus.
If we formally seek to join, we would start as an incubator project, in the process of establishing the requirements to be formally adopted.

The Project Progression document (https://github.com/openjs-foundation/cross-project-council/blob/main/PROJECT_PROGRESSION.md) details the process, so I won't go over it in detail, but I invite you to read it.

While I confess a bias towards liking processes, I find the detailed process and onboarding checklist reassuring, showing the OpenJS Foundation have vast experience working with open projects, and want the ecosystem to continue to be trustworthy and stable. The checklist includes things like transfer of trademarks and making sure code of conducts and legal notices are in place.

What now?

While I've been focusing on the foundations required to elevate JSON Schema since starting at Postman, such as ADRs and our CoC (and even providing a space for those discussions), I believe joining the OpenJS Foundation is a really key move for JSON Schema.

JSON Schema has already established itself as a fundamental tool, used by many in production, and leading the way on writing open collaborative data definitions for important new and developing specifications. As such, releasing a 1.0 should be well considered, with buy in from major vendors in the industry.

We're already collaborating with initiatives that have a larger impact than I dreamed was possible. We owe it to the community to do as best a job as we can, and I believe that now means engaging with users on more than an individual contributor level.

I propose we look to join the OpenJS Foundation, which will dramatically aid in the projects elevation.

Unless there are any major objections here, I'll create an issue at the start of next week and look to begin filling in the required form.

[karenetheridge]

Would this imply that JSON Schema is a javascript-first or javascript-only technology, or give any favouritism to any particular implementations, tools or backends? Would it preclude future partnerships with, or accepting funding from other technology groups?

[Relequestual]

Would this imply that JSON Schema is a javascript-first or javascript-only technology, or give any favouritism to any particular implementations, tools or backends?

The OpenJS Foundation wants to support key projects that are important to the javascript ecosystem. While JSON Schema is incredibly important to that ecosystem, the real benefit is the level of interoperability between languages. There are other projects in the OJSF that are multi-platform, such as libuv, which says it was built primerily for node.js (https://github.com/libuv/libuv/blob/v1.x/LINKS.md)

Another option would be for us to find out about joining as our own "inititive" under the Linux foundation, as @fmvilas has done with AsyncAPI. If a few more people raise similar concerns, I'll put the breaks on and we can discuss it further!

Would it preclude future partnerships with, or accepting funding from other technology groups?

I don't think so. We saw AJV get funding from Mozilla, and that's an incubator project in the OJSF. But, let's get clarity on this from someone in the OJSF.

[joesepi]

Short answer: No and No. Would not give or expect any favoritism. Would not preclude any partnerships or funding.

Our Trademark Policy sets pretty good guidelines that they could interpret for potential scenarios, including funding. The crowdfunding section is new and is intended to protect the project and its core maintainers, for example it can help prevent people going rogue raising money using the project brand. https://openjsf.org/wp-content/uploads/sites/84/2021/01/OpenJS-Foundation-Trademark-Policy-2021-01-12.docx.pdf

[fmvilas]

I say go for it 🚀