hero Archives - OpenAPI Initiative

Feb 20

OpenAPI Community Heroes – Erik Wilde

By OpenAPI Initiative 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 Initiative specifications, Special Interest Groups (SIG), or across the OpenAPI Initiative (OAI).

Our next Community Hero is Erik Wilde. Erik is an API industry expert and OAI Ambassador, and is responsible for the OAI tracks that have been a feature of the API events landscape in 2023 and 2024, with more to come in 2025. Erik has a background in research and academia, having held the roles of Associate Adjunct Professor and Assistant Professor at Berkley. He has contributed to many publications, patents, and standards, and worked with various industries and sectors, such as healthcare, education, finance, and government.

Erik filled us in on why he is involved in the OAI and his views on the role of standards in the industry.

What drives your interest and involvement in the OpenAPI Specification?

OpenAPI is one of the fundamental building blocks of today’s digital economy. It’s just a minor exaggeration to say that 100% of organizations today depend on OpenAPI in some place of their IT landscape to be able to do what they do.

Standards sometimes get a bad reputation as constraining things too much. And of course they do constrain things and there also are standards out there which possibly could have been designed better. But the important aspect is that standards create real value and they do so because people agree that using them is better than not using them.

OpenAPI has become the dominant standard for API descriptions and is effectively powering today’s global digital landscape. It’s thrilling to be part of that movement, and it is rewarding to try to help with improving the standard itself and improving the way how people learn about the standard and how to use it. We have ambitious goals for the OpenAPI Initiative to increase our visibility and make it easier for people to learn and adopt OpenAPI. I am optimistic that 2025 will change a fair bit how OAI is operating and how we engage with and help the global API community.

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

Right now it is probably the visibility and community around OpenAPI. I have been organizing OAI Tracks at various conferences for almost two years now. It’s always rewarding and interesting to see the many different contributions and ways how organizations are using OpenAPI.

OAI has an excellent technical arm that makes sure that OpenAPI remains a technically sound and well-designed specification. What we currently lack is a better connection with our community of OpenAPI users.

On the one hand we need that to make sure that more people are learning what OpenAPI is and how to use it. We also want more people to read our case studies and reports (planned for 2025!) so that they better understand what it takes to use OpenAPI well.

But on the other hand we also need more and better feedback from the community. What are the features people find most useful? What are features that seem to introduce complications? What are features that are missing? And what does the tool landscape out there actually implement, which brings us to the surprisingly difficult question to decide what “implementing OpenAPI” really means (which is a fascinating topic in itself and another major 2025 activity for OAI).

I think we need a larger base and better visibility in the community as a necessary step to better plan how to evolve the specification in a way that’s most useful for its users.

The OpenAPI Initiative is now a multi-specification organisation. How will the project change now that we are delivering more specifications to the API community?

Quite a bit of that is terminology and branding. We have a rather unfortunate name now that we’re not just managing the OpenAPI specification. We’ll be able to work with it, but we need to reassess our branding and things like our information architecture in general.

Our website is currently undergoing a major analysis and redesign and hopefully we will end this year with a prettier, easier navigable, and easier manageable website. One part of it is just improving things that we’ve known for a while, but taking the multi-specification aspect into account is one of the major reasons for the redesign.

What’s great is that our two new specifications are fitting into rather specific and easily explainable gaps. This means that our story of how we support the API landscape becomes more complete and overall a more convincing story. It also means that we can tell better stories of how tools and tool chains can be used because there are interoperable descriptions of various aspects throughout the API lifecycle.

In the end, being a multi-specification organization has increased the potential of OAI as a unique provider of solutions in the API space. But it also has made it a bit more challenging for us to tell our story and the story of our specifications. What do you see in the future for the OpenAPI Specification?

One of the important tasks going forward is to better understand if and how could be improved to better support AI scenarios. It might be as simple as adding some guidance around API design and how to best write the OpenAPI description for AI consumers. This is particularly interesting for AI agents which probably would want to discover higher-level information on how to use an API, for example in an Arazzo workflow description.

But we may also see that AI scenarios are requiring updates to OpenAPI, to other OAI specifications, or maybe will need entirely new specifications. We’re only at the beginning of understanding the potential and impact of AI scenarios, but I am sure that a year from now we will have a better idea about how to make OpenAPI more AI-friendly.

Personally, I think the current version has proven to provide enough value for us to invest more into explaining that value and making it easier to realize. It’s not OAI’s goal to turn into an API consulting firm, but given our unique position in the API landscape we can provide trainings, case studies, and reports with more authority than most other entities out there, and it would help our users if we did more of that.

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

First and foremost our “sister specifications” that are also part of the Linux Foundation have to be mentioned: AsyncAPI and GraphQL. And then there’s of course gRPC which is not part of the Linux Foundation but still can be considered an open standard. So these are the big ones complementing OpenAPI when it comes to providing open and established technologies for various API styles.

When it comes to OpenAPI itself then of course we have standards like JSON Schema, OpenID, and OpenID Connect (OIC), which are very central to using OpenAPI APIs and need to be treated as an almost integral part of OpenAPI by now.

What we may also see is some variant of a catalog format, where it is possible to advertise API catalogs and to describe APIs in those catalogs with machine-readable API descriptions and other metadata that may be helpful to work with the API. Since we do see more and more scenarios where scaling the API practices is one of the challenges, we may see such a catalog format emerging as a way to more easily share APIs.

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

Yes, it would be great to see more people getting involved with OAI. We want to play our part by creating more useful content going forward, in particular in terms of training, case studies, and reports. These things will help OpenAPI users, but the more we can create these based on feedback, the more likely we will create the ones that have the most impact.

In my mind, APIs still are too often treated as a mere side-effect of having an IT landscape where components need to be connected. Of course we need APIs on this very basic level, but in many organizations there is a lot of unrealized potential because APIs are not managed strategically. We still need to be better at telling the story of API representing business capabilities, the option value that they bring to an organization, and the steps it takes to create the right APIs and to create them the right way.

We’re only getting started with Getting APIs to Work at OAI, and given that we have big plans for 2025 this is the ideal time to join the movement, start engaging with OAI, and help us to better understand how we can better help you and the API community in general!

Author: Erik Wilde

Nov 29

Love0

OpenAPI Community Heroes – Karen Etheridge

By OpenAPI Initiative 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 Community Hero is Karen Etheridge. Karen is a regular OpenAPI Specification contributor and describes herself as a “general busybody”. Karen told us about what drives her involvement in OpenAPI and what she hopes to see in Moonwalk.

What drives your interest and involvement in the OpenAPI Specification?

As a long-time backend software developer, I’ve worked with HTTP/REST APIs in several projects. A few jobs ago, we started defining our APIs with internally-developed code to use hooks in the dispatch process to perform data validation; as I pulled these data definitions out into formalized JSON Schemas, I discovered that the ecosystem for JSON Schema validation was incomplete, so I published my work to open source, as JSON-Schema-Modern.

A few years ago I was invited to join the Technical Steering Committee for the JSON Schema specification (json-schema.org), where I helped edit the latest release, draft2020-12, and where we’re now working on putting together revisions for the next release.

As part of my work in a later job, I moved into the OpenAPI space and built a new implementation of the OpenAPI v3.1 specification to perform validation of HTTP requests and responses, publishing that as OpenAPI-Modern. As I worked through this implementation I had many questions and observations about the spec, so this naturally led me to talking to the OpenAPI teams and community; shortly after, I began submiting improvements to the specification itself, and was subsequently pulled into a reviewer team for the specification and schemas. No good deed goes unpunished! 🙂 And now, this autumn, we’ve just gotten versions 3.0.4 and 3.1.1 out the door, and are now talking about changes for the upcoming 3.2 and 4.0 versions!

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

A lot of OpenAPI 4.0, codenamed Moonwalk, is still up in the air right now, so now is a perfect time for people to jump in with their opinions and requests! We’re working through the way requests and responses are expressed in OpenAPI and thinking about whether the current “shape” makes sense, and what modifications we need to make tooling easier. We’ve been throwing around the terms “ontology” and “taxonomy” a bit, and thinking about what these concepts mean for OpenAPI descriptions.

One thing that has come up regarding the current document structure is the oddity between expression of request parameters in a list (with the “name” property adjacent to all other properties), and response parameters as an object (with the “name” as the property name, one level above all other properties). Expressing parameters (such as request headers) in a list doesn’t really make sense, because HTTP headers don’t have a natural order, but also it’s convenient to group all header properties together, rather than having the “name” be at a different level. So we haven’t quite yet worked out what to do here.

One thing on my radar that I want to address in Moonwalk is the way multipart requests and responses are expressed in OpenAPI — the way the structure is described in the HTTP RFCs doesn’t really match how the current OpenAPI specification models them, so I think there are some improvements to be made there. They’d be backwards-incompatible, so these changes would have to be in version 4, not 3.2.

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

The Arazzo Specification and Overlays (both with a 1.0 version hot off the presses) look really promising, although I haven’t had much of a chance to dive into them yet. The ideas behind Arazzo are really interesting, as up until now each API is defined in a description wholly separate from every other API, whereas Arazzo workflows will tie them together and show how multiple APIs are related to each other. This will really help future low-code applications that drive their API calls directly from OpenAPI descriptions. The more sophisticated we can get with describing the full flow of an application, the more automatic code generation we can do, which is great for programmer productivity.

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

Absolutely! We need to hear from the community so we know what we should work on next. How are you using OpenAPI in your projects, and where would you like to use it more? We’d especially like to know what things you find difficult or confusing, or perhaps types of APIs that you find difficult to express right now.
We do hear from users from time to time that are frustrated that their favourite software suites or IDEs aren’t fully OpenAPI 3.1-compliant, so if tooling vendors have any roadblocks here, we really want to know, so we can help.

Additionally, we love hearing about new tools that do things we didn’t expect, and what other things we could be capturing in OpenAPI descriptions that we haven’t thought about yet. Let us know what you’re doing and we’ll showcase you on our Tooling page! (https://openapi.tools)

Sep 17

Love1

OpenAPI Community Heroes – Lorna Mitchell

By sensiblewood Blog

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!

Jul 25

Love1

OpenAPI Community Heroes – Frank Kilcommins

By sensiblewood Blog

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.