Skip to main content
Tag

community

OpenAPI Community Heroes – Lorna Mitchell

By Blog

Welcome to the next installment of our series of posts on people we consider to be heroes of the OpenAPI community. These people go above and beyond to contribute to the OpenAPI Specification (OAS), Special Interest Groups (SIG), or across the OpenAPI Initiative.

Our next latest Community Hero who makes a huge contribution to OpenAPI is Lorna Mitchell. Lorna is VP of Developer Experience at Redocly and a member of the Technical Steering Committee for the OpenAPI Specification. Lorna is a software engineer, published O’Reilly author, open source maintainer and general API enthusiast, who describes herself as “getting stuck on an OpenAPI question one day, and never left!”

Lorna gave us her thoughts on all things OpenAPI and Arazzo.

What drives your interest and involvement in the OpenAPI Specification?

My whole career has been around getting computers to talk nicely to one another! I’ve built APIs, taught APIs, written books on these subjects, advocated for APIs, now I work on API developer tools. APIs are important, interesting, and mostly under-celebrated.

What do you consider to be your most significant personal contribution to the development of OpenAPI?

That’s a hard question! I’ve made very tangible additions such as designing the webhooks support for 3.1, but I think being a regular at the TDC meetings and in the GitHub projects, enabling other people to be heard and have their contributions accepted has been really important. Now I’m a technical steering committee member myself, which is pretty significant!

What do you see as the most exciting proposed features of version 4 of OpenAPI?

It all looks promising.

How will the Arazzo Specification benefit the development of the OpenAPI Specification?

Arazzo gives us a way to connect API calls in sequence, and it’s a good reflection of how APIs are actually built and used today. Building on the foundation of OpenAPI is brilliant for the ecosystem and we’ve needed something like Arazzo for quite a while.

What do you see in the future for the OpenAPI Specification?

As the project matures, we’re seeing more of an ecosystem around OpenAPI. Within the project itself, we’ve got Arazzo, Overlays, and more examples and learning resources. In the wider industry, lots of exciting new tools are springing up and people are starting to skill up more on what they can do with OpenAPI.

What other standards developments do you consider particularly significant for the API economy?

Seeing AsyncAPI release a new major version last year was exciting, there are lots of interesting use cases in that space. I’m also really interested in how we manage these large API landscapes so APIs.json is one to watch.

Should more people get involved in developing the OpenAPI Initiative specifications and why?

Yes please! More help is always welcome, but what I’d really like is to hear more voices. More questions in the GitHub discussions, more comments from more different people on the proposed changes. End users, tools makers – everyone should have their say, and I hope they will join in!

OpenAPI Community Heroes – Frank Kilcommins

By Blog

Welcome to the next installment of our series of posts on people we consider to be heroes of the OpenAPI community. These people go above and beyond to contribute to the OpenAPI Specification (OAS), Special Interest Groups (SIG), or across the OpenAPI Initiative.

We are delighted to share our next Community Hero, Frank Kilcommins. Frank has over 15 years of experience in the technology industry, with his roles spanning from software engineering to enterprise architecture. His mission is to inspire, engage with, and support the API community and SmartBear customers across the end-to-end API Development Lifecycle and Management space.

Before joining SmartBear, his most recent roles focused on API-led Digital Transformations and architecture modernization within multinational enterprises. In addition to his roles at SmartBear, Frank is a member of the OpenAPI Initiative Business Governance Board and has spearheaded the new Arazzo Specification for API workflows.

What drives your interest and involvement in the OpenAPI Specification?

APIs are critical to the digital world around us, and it’s an area of tech that I’ve been heavily working on for the last decade. I’m naturally drawn to the resilience and affordances brought by specifications and standards and as a result, I’ve been championing OpenAPI adoption and usage within various jobs engaged with HTTP-based APIs. My initial engagements with the community and OpenAPI Initiative were from a learning perspective (and still are) but over time I’ve been able to support others and contribute back as well.

What do you consider to be your most significant personal contribution to the development of OpenAPI?

I would have to say championing the Workflows Special Interest group and driving the creation of the Arazzo Specification have been my personal highlights.

My contributions on the core spec have been mostly verbal or via the Slack workspace apart from revamping the https://spec.openapis.org site to be multi-spec ready. Within the broader OpenAPI Initiative, I’ve also looked to improve some of the related artifacts and repositories. This includes things like ‘community’ to streamline the information on Special Interest Groups and participation, ‘OpenAPI-Style-Guide’ to have a dedicated barbell logo and usage instructions (yes, it matters 😉), and in a very small way the OAICourses material.

What do you see as the most exciting proposed features of version 4 of OpenAPI?

The structural changes are going to significantly reduce the verbosity of OpenAPI descriptions which is great for humans and machines dealing with large API surface areas. Additionally, the hardening of external referencing and improved multi-document support will make our lives as tooling builders much better, and in turn the developer experience for end-users.

How will the Arazzo Specification benefit the development of the OpenAPI Specification?

Arazzo addresses a very natural problem in aiding the description of deterministic use-case-orientated sequences of calls to APIs, be they in a single OpenAPI description, or spanning multiple. In general, thinking and building software in terms of use cases is what comes naturally to humans, so we predict that Arazzo will help improve the state of API design and design thinking. This niche focus can benefit OpenAPI by reducing the burden of supporting such capabilities both from a core spec perspective as well as that of authors who are currently challenged with trying to embed such associations within markdown or extensions.

Moving forward there is scope/vision for the sharing of components between OpenAPI and Arazzo which will bring another set of benefits to the community.

What do you see in the future for the OpenAPI Specification?

I’m excited by the launch of the Arazzo Specification, and the maturing of the OAI into a multi-specification project under the Linux Foundation. This combined with continued work of the Special Interest Groups will help to drive a more rounded OpenAPI Specification by addressing the needs of the community across industry verticals and specialist topics.

Personally, I would like to see a certification process for specification compliance (some of this being spearheaded by Henry Andrews with the OASComply project). Ensuring tool vendors advertise the compliance levels improves transparency for API practitioners and end-users. Ultimately, it can potential also help speed up the adoption of newer specification versions.

What other standards developments do you consider particularly significant for the API economy?

The elephant in most rooms right now is AI. It will be interesting to see how AI will consume standards, connect with standards-based APIs, and indeed help humans produce, understand, and consume APIs. The Arazzo Specification, as well as designs for OpenAPI 4, are specifically crafted with AI in mind. For example, Arazzo specifically has the semantic determinism to ensure that API sequence execution can be safely handed off to an AI agent.

The evolution of AsyncAPI into a v3 generation is also one to watch. Future collaboration between OAI and AsyncAPI is natural as in many practical situations those producing or consuming APIs are not limited to a single style.

In other areas, I’m particularly interested in developments within OAuth, the OpenID Foundation for OpenID Connect as well as FAPI. Keeping the financial theme, PSD3 also holds promise with respect to enforcing API standardization and performance. It’s also encouraging to see various governments, including the EU, form opinions on the importance of APIs and put forward opinions on API standards and specifications.

Should more people get involved in developing the OpenAPI Initiative specifications and why?

Absolutely! As I mentioned at the outset APIs are the critical tissue that enables much of the technology around us. If you have an interest or passion in APIs, then the OAI is a community that welcomes participation. Just like any open-source project, involvement and participation comes in many forms and caters for a diverse range of skills.