Skip to content

Feat: Proposed content strategy to support repositioning OAI #71

@RCheesley

Description

@RCheesley

Parent: #67

Summary

As part of the repositioning work in #67, we need to shift OAI’s content from mostly reactive updates ('we released X', 'we spoke at Y') to a more intentional mix of thought‑leadership and real‑world stories that:

  • show how OpenAPI, Arazzo and Overlay are being used in practice
  • position OAI as a forward‑looking steward of the API ecosystem
  • make the community and governance side of OAI much more visible
  • make it obvious how people can get involved and why membership matters

This issue proposes five content areas to guide what we publish on the website, LinkedIn and email.

I've tried to keep it fairly lightweight and where possible re-used content from other things (e.g. that might come out of member clinics or be created following panel webinars) so that it's not a heavy editorial calendar, but more a set of rails we can use to guide us so that, over time, our content tells a more balanced story that supports the new positioning.

Content areas overview

# Content area Core idea Example outcome
1 The future of APIs Show OAI as a forward‑thinking strategist planning for an AI‑native, agentic API ecosystem OAI is referenced more frequently in 'future of APIs' conversations and speakers are invited to contribute outside the direct industry
2 Specs in practice Demonstrate how OpenAPI, Arazzo and Overlay solve real organisational problems, especially for non‑technical decision‑makers Budget holders see OAI’s work as strategic infrastructure which underpins their business operations, rather than just developer tooling
3 Community and governance Highlight OAI as a collaborative, member‑driven community rather than a standards body Members feel visible and influential, prospects see clear 'seat at the table' value
4 Ecosystem insights Position OAI as a curator and connector of the wider API ecosystem, influencing and sharing more than just its own projects OAI becomes a go‑to source for API trends, reports and synthesis
5 Getting involved Make it obvious how organisations and individuals can influence the future of APIs via OAI (membership and contribution) More people move from passive users of the specs to active contributors and members

These areas can be fed from and feed back into the membership programmes - for example:

  • an interesting case raised in a member clinic might become a 'specs in practice' blog post
  • a webinar panel discussion could be turned into a 'future of APIs' themed article
  • a SIG milestone can become a 'community and governance' story

Content area 1 – The future of APIs

Intent

Moving OAI beyond 'spec maintainer' to being seen as one of the groups thinking ahead about how APIs and API standards will work in an AI‑native, agentic world (or insert any other relevant future-facing buzz words which might arise over time!)

Example topics

(note, these are AI generated so please take with a pinch of salt, we can come up with ideas collaboratively)

  • AI‑readiness for API specifications
  • Agentic workflows and autonomous systems
  • The evolution from single APIs to orchestrated workflows
  • API governance in regulated industries
  • Cross‑industry API standardisation challenges
  • OpenAPI + Arazzo + Overlay as a unified solution to emerging needs

Possible formats

  • Thought‑leadership articles from board members, TSC members and contributors
  • 'Future of …' interview series with experts in different industries
  • Trend/insight posts after major events (for example APIdays, DeveloperWeek)
  • Conference talks where we make OAI’s role explicit
  • Occasional technical vision papers to spark discussion and contributions

Example working titles

(note, these are AI generated so please take with a pinch of salt, we can come up with ideas collaboratively)

  • 'Why every API needs to be AI‑ready (and what that actually means in practice)'
  • 'From single calls to workflows - enabling agentic systems with Arazzo'
  • 'The three‑layer API stack - description, orchestration and adaptation'

Content area 2 - Specs in practice

Intent

Make the value of OAI’s work obvious to non‑technical decision‑makers by showing how the specifications solve real problems.

Example topics

(note, these are AI generated so please take with a pinch of salt, we can come up with ideas collaboratively)

  • How Overlay enables financial services API governance
  • Arazzo use cases in payment workflows or healthcare integrations
  • Using OpenAPI at scale – implementation stories from large organisations
  • Industry‑specific challenges and how they were resolved
  • How developers gain in productivity as a result of standardisation
  • The cost of non‑standardisation (“API chaos tax”)

Possible formats

  • Member showcases and case studies
  • 'How [company] uses [OpenAPI/Arazzo/Overlay]' posts
  • Implementation patterns and best practices (lightweight, not full training material)
  • ROI‑style pieces where we can credibly quantify time saved, incidents avoided, integrations sped up

Example working titles

(note, these are AI generated so please take with a pinch of salt, we can come up with ideas collaboratively)

  • 'How [FinTech company] uses Overlay to meet regulatory requirements without rewriting APIs'
  • 'The real cost of API chaos and why standardisation is no longer optional'
  • 'Three ways Arazzo reduced integration time by 60% for [company]'

Content area 3 – Community and governance

Intent

Highlight OAI as a collaborative, member‑driven community rather than a standards body. Also surface the value members get from being part of that.

Example topics

(note, these are AI generated so please take with a pinch of salt, we can come up with ideas collaboratively)

  • Member spotlights and stories
  • Contributor recognition
  • SIG work and updates
  • Governance decisions and the reasoning behind them (at an appropriate level)
  • TSC insights
  • How member feedback shaped a spec or decision
  • Cross‑project collaboration with other LF projects

Possible formats

Example working titles

(note, these are AI generated so please take with a pinch of salt, we can come up with ideas collaboratively)

  • 'Meet new member [company] - why they joined and what they’re working on'
  • 'Inside the Moonwalk SIG - what we’re experimenting with right now'
  • 'How member input shaped the Overlay specification'
  • 'What happened in the OpenAPI Initiative this month?'

Content area 4 - Ecosystem insights

Intent

Position OAI as a thoughtful curator of what’s happening across the API space, not just a promoter of its own specs.

This doesn’t mean we have to write everything - we can also highlight and contextualise good work from others. This is already being done at the moment to some extent.

Example topics

  • API industry trends and observations
  • Adjacent technology developments (AI, platforms, security, etc.)
  • Interactions with other standards and foundations
  • Insights from conferences and events
  • Research synthesis and interpretation
  • 'State of …' views on parts of the ecosystem

Possible formats

  • Annual report on spec adoption / migration (for example 2.0 → 3.0 → 3.1) - not sure if this could be done but it might be interesting to track
  • Conference recap posts (key themes, member announcements, new collaborations)
  • Short trend analysis posts
  • 'What we’re watching' series - technologies or approaches OAI is exploring
  • Curated reading lists ('this month’s top API reads from our community')

Example working topics

  • 'What we learned at APIdays Paris – APIs and AI in the wild'
  • The technologies our team were most excited about at DeveloperWeek'
  • Five open source projects doing interesting things with OpenAPI
  • A joint 'State of APIs' style report with other orgs - maybe AsyncAPI (if they’re interested)

Content area 5 - Getting involved

Intent

Make it very obvious how people can move from 'user' to 'participant' - whether that’s as an individual contributor or as a member organisation.

Example topics

  • Membership value and opportunities
  • Contribution pathways (code, docs, SIGs, advocacy)
  • How to join and participate in SIGs and working groups
  • Speaking and writing opportunities
  • Success stories from people who got involved
  • Practical benefits of participation (learning, visibility, influence)

Possible formats

  • 'How I got started' interviews with contributors
  • Member benefit explainers (for example 'what actually happens in the clinics')
  • Short video vox‑pops with maintainers or BGB members
  • Event and opportunity announcements (CFPs, working groups, task forces)
  • Behind‑the‑scenes looks at member benefits (for example opening up one clinic as a taster)

Example working titles

  • Three ways your team can shape OpenAPI’s future (even without membership)
  • What actually happens in the OpenAPI monthly member clinics
  • From lurker to contributor - one developer’s journey into the community

How we’ll use this

Rather than dictating a specific publishing schedule, I'm hoping that deciding on these five content areas will help to:

  • giving us a shared language for what kind of stories we want to tell
  • making sure that, over time, our blog, LinkedIn and email output touches all five areas
  • providing a menu of ideas for anyone who wants to write or speak on behalf of OAI

It also ties directly into other issues under #67:

I'd envision this content being primarily shared via LinkedIn and email channels.

Next steps

  • Agree that these five areas make sense as the backbone of OAI’s content
  • Identify 1–2 'quick win' pieces for each area (could be as simple as a blog recap or interview)
  • Create a simple content tracker (even a spreadsheet or GitHub Project using issues) listing:
    • topic
    • content area
    • format
    • owner
    • status (idea / drafting / published)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions