►
Description
This is a pretty unusual edition of our SIG meeting. We have an important announcement for our community, so set a reminder to not miss it.
The meeting is live-streamed to our YouTube, Twitch and Twitter channels:
- https://www.twitch.tv/asyncapi
- https://youtube.com/asyncapi
- https://twitter.com/AsyncAPISpec
You can also join us live on Zoom as usual. Connection details are here: https://github.com/asyncapi/asyncapi/issues/464
A
B
D
D
B
A
A
A
F
B
A
A
F
A
G
D
D
A
I
A
So
so
far
for
those
that
watch
the
live
stream,
we
have
two
guests
from
postman,
it's
kin
and
nabinov.
We
have
also
zoltan
that
joins
us
regularly
on
our
meetings.
We
have
lauren
that
just
joined
who's-
I'm,
I
guess
you're
here,
because
you're
representing
the
micro
rocks
the
awesome
awesome
testing
tool
that
just
recently
integrated
with
asking
api.
E
A
B
B
A
So
yeah,
so
let
me
just
catch
up
the
intro,
so
it's
a
our
usual
public
meeting
that
you
can
join
every
second
week.
Sometimes
it's
in
a
time
zone
for
asia
and
pacific.
Sometimes
it's
in
the
time
zone
for
americas,
which
is
now
today,
it's
a
special
meeting.
That's
why
it's
not
just
available
on
zoom,
but
we
also
stream
live
this
meeting
to
our
accounts
on
twitch
youtube
and
twitter,
like
multi-streaming
like
crazy
and
I'm
gonna
be
a
kind
of
moderator,
because
we
have
so
many
different
streams.
B
Absolutely
thanks
for
the
for
the
intro
man,
so
I'm
not
gonna.
I'm
not
gonna
like
be
very
pompous
here
about
the
announcement.
I
think,
if
all
of
you
already
went
to
the
website,
you
probably
have
seen
it
or
if
you're
subscribed
to
the
newsletter.
You're
you've
already
seen
it.
So
what
we're
happy
to
announce
today
is
that
we're
partnering
with
postman
and-
and
today
we
have
abhinav
ceo
of
pozman
here
as
well
and
and
kin
lane
so
so
yeah.
B
B
B
I
hope
for
many
years
right
is
that
so
postman
is
actually
giving
us
the
support
and
the
help
that
we
need
to
to
create
a
team
to
work
full-time
on
on
async
api.
Not
just
me
not
just
lucas,
and
not
just
jonas
now,
right
so,
which
is
kind
of
unannounced
yet
but
yeah.
It's
not
just
that,
but
we're
gonna
we're
gonna
be
growing.
The
team
like
we're
gonna,
be
hiring
like
crazy,
so
so
stay
stay
tuned
for
that,
so
we're
gonna
be
hiring
lots
of
engineers.
B
Designers,
we're
technical
writers,
we're
gonna,
be
hiring
a
lot
of
people.
What
for
right?
That's
the
the
question
right.
So
what
for
supposed
money
is
going
to
help
us
build
the
future
facing
kpi
or
make
it
making
it
a
reality?
And,
as
I
said,
this
is
not
just
a
regular
contribution
or
or
a
regular
sponsor.
Let's
say
right,
it's
more
than
that.
B
We,
the
three
of
us
here
in
the
call
right
now
so
jonas
lucas
and
I
we
joined
postman
pretty
recently
right,
so
we're
now
working
at
postman
but
full-time
dedicated
to
async
api
and
the
success
of
async
api
right.
So
a
little
bit
more
details
about
what's
coming,
what's
the
details
about
the
deal
and
about
the
the
the
agreement
here
is
that
posman
doesn't
doesn't
want
to
own
async
api
specifically,
so
this
was
this
cast
a
lot
of
times
like
how
do
we
frame
this?
B
How
what
what
are
the
words
that
we
should
be
using?
So
we
avoid
confusion
in
people
that
this
is
not
postman,
acquiring
a
syn
kpi.
So
don't
don't
get
scared.
This
sightseeing
kpi
is
still
free
and
will
remain
free,
free
as
in
freedom,
not
not
the
same
price
right
and-
and
this
is
lucas,
were
you
trolling
me
on
the
phone
yeah.
B
I
don't
know,
say,
for
instance,
linux
foundation,
cncf
apache
foundation,
something
like
this
right.
We're
now
talking
to
different
people
to
different
of
these
open
source
software
actors
and
we'll
see
where,
where
we
host
the
project
right,
it's
not
only
our
decision.
They
also
want
to
to
host
the
project.
So
so
they
have
something
they
have
something
to
say
right
and.
B
And
yeah,
so
that's
that's
pretty
much
that
that
part
again.
The
idea
here
is
to
make
to
create
a
team.
That's
gonna
be
dedicated
and
working
on
async
api,
full-time,
we're
gonna,
be
hiring
a
lot
of
engineers,
as
I
said
before,
and
and
other
roles
as
well
and
yeah.
I
would
love
to
I
I
was.
I
was
like
super
excited
to
share
this
with
you
man,
because
this
was
already
like
burning
me
from
inside.
Like
I
couldn't
I
couldn't
share
it.
B
I
I
I
I
Yeah
yeah,
so
we
kind
of
started
talking
then,
since
about
the
idea
of
you
know
specifications
so
you
know
like
that
is
very
close
to
you
know.
Postman
since
then
I
mean
kin
has
officially
joined
now,
but
he
was
you
know
in
an
official
unofficial
advisory
capacity
since
then.
So
you
know,
it's
great
to
you
know
be
working
with
leaders
in
the
api
space.
That's
what
I'm
excited
about.
C
Yeah
yeah
just
to
layer
on,
I
mean
fro
for
me
this
has
been
such
a
journey.
I
mean
you
know
abhinav,
and
I
first
started
talking
when
before
even
the
open
api
was
was
open,
api
back
when
it
was
still
swagger-
and
you
know
the
importance
of
of
stabilizing
and
putting
that
spec
into
the
the
linux
foundation
and
then
growing
it
and
seeing
what
it's
grown
into,
and
I
remember
when
frond
for
when
I
first
met
frond.
C
I
was
working
with
him
and
bruno
on
on
api
change
log
and
I
was
an
advisor
there
and
and
when,
when
I
saw
it
when
when,
when
he
proposed
and
put
async
api
out
there,
I
really
felt
like
it
was
the
early
days
of
of
swagger.
You
know,
and
I
felt
that
that
same
momentum,
I
felt
that
same
kind
of
community
buy-in
that
this
is
needed.
This
is
the
next
generation
of
what
we're
going
to
be
doing
for
apis
and
then
now
here
in
2020.
C
I
really
feel
like
I
see
the
complete
picture
coming
together
of
of
open
api
async
api
and
then
the
binding
kind
of
factor
of
json
schema.
You
know
when
it
comes
to
that
and
and
seeing
what
postman's
become
and
how
postmates
become
a
full
lifecycle
api
platform.
I
would
say
you
know
evolving
from
that
api
lifecycle
tool
to
actually
a
platform,
an
api
platform,
I
think,
being
able
to
manage
your
truth
with
an
open
api
with
an
async
api
and
model
and
manage
all
of
the
objects
across
it.
C
Using
json
schema
really
represents
the
future
of
of
of
an
api
platform,
but
I
think
for
us,
as
api
providers
like
what
we
need
our
toolbox
to,
do,
we
need
it
to
be.
You
know,
multi-protocol,
we
need
to
be
multi-format,
we
we
need
consistent,
tooling
and
services
across
the
api
lifecycle
to
document
manage
and
test,
and
that's
what
this
this
partnership
you
know
reflects
for
me.
B
So
yeah
I
mean
feel
free
to
jump
at
any
time.
If
you
have
questions
like
this
is
this
is
just
another
sick
meeting
for
us,
but
that's
why
we
wanted
you
to
to
join
on
on
on
zoom
right
and
not
just
stream,
it
stream
it
on
youtube
or
twitch
right.
So,
like
I'm,
I'm
assuming
that
you
have
lots
of
questions,
I'm
sure
so
yeah
feel
free
to.
K
J
Big
step,
when
you
have
this
kind
of
things,
yes,
I
mean
I
can.
I
can
hear
that
you're
proud.
So
I
think
it
does
it's
it's
very
nice.
So
you
said
that
you
said
you're
kind
of
cooking
this
for
a
while,
and
can
you
share
any
any
any
plans
roadmaps
on
on
this
journey?
Do
you
have
anything
already
in
in
pipeline
to
do
together,
or
you
know,
of
course,
there's
an
essence
api
roadmap,
but
is
it
does
it
changed
or
or
is
it
any
change
or,
for
example,
from
postman's
side?
J
I
B
B
So
she's
now
working
on
her
arm
companies
and
she's,
not
into
tech
anymore.
Luckily,
for
her
he
was
suffering
already
and
and
so
yeah.
So
it's
been
mostly
lucas
and
I
working
full-time
in
this
and
you
cool,
I
mean
you
could
see
that
we
couldn't
cope
with
everything
right
like
we
had
lots
of
stuff
to
do.
B
Luckily,
we
thought
we
have
him
and
now
so,
with
this
with
this
partnership,
we
will
be
able
to
to
actually
work
on,
let's
say
work
on
all
these
things
that
we
wanted
to
do
faster
right,
and
you
even
consider
some
things
that
we
we
weren't
considering
considering
before,
because
we
knew
it
was
too
much
and
we
were
discarding
them
because
of
this.
Now
we
can.
We
can
do
that
right.
B
So,
for
instance,
one
of
the
things
that
we
wanted
to
do
is
we
want
to
have
a
more
regular,
a
more
regular
calendar.
Let's
say
schedule
for
releasing
new
versions
of
the
spec
right
so
right
now
the
spec
has
been
stuck
on
version
two
on
purpose
right
on
purpose,
because
the
moment
you
change
something
in
the
spec,
it's
like
a
snowball
effect
right
like
it
goes
all
the
way
to
all
the
tooling
and
it's
like
no
way
no
way.
So,
let's,
let's
not
touch
the
the
spec.
B
B
So
a
good
user
experience
in
the
cli,
so
we've
been
hearing
people
feedback
for
a
long
time
and
people
were
mostly
complaining.
Let's
say
about
the
cli
user
experience
like
you
just
want
to
validate
anything
kpi
file
or
you
just
and
it's
not
it's
not
that
simple
as
it
is
right
now
and
it
will
be
or
you
want
to
do
something
as
basic
as
please
validate
this
json
object
against
this
async
api
definition
and
you
you
couldn't
as
well.
B
It
was
or
it
was
like
it
was
not
supported
by
us
or
developed
by
us,
and
there
were
some
contributions
from
the
community,
but
it
was
like
we're.
It
was
a
little
bit
weird
right,
like
these
basic
things
were
not
in
place
and
so
yeah.
So
these
things
are
gonna
evolve
for
sure
we
will
also
be
investing
into
into
a
async
api
studio,
which
is
what
we
used
to
call
as
in
kpi.
Have
this
time
a
little
bit
different.
So
it's
more!
B
It's
not
a
good
user
experience
right
and
also
some
investments
that
that
will
be
discovering
soon
like
on
investment
into
different
or
products
or
tools
that
we're
we're
thinking
about
and
developing,
and
that
we
think
that
can
help
the
community
a
lot
and
and
make
asynchronous
apis
more
mature
right.
So.
C
I
would
say
to
add
to
kind
of
layer
on
the
not
the
direct
postman
or
the
direct
async
api
roadmap.
For
me,
as
my
role
as
chief
evangelist
and
and
api
evangelist,
is
I'm
looking
at
five
and
ten
year
cycles,
and
I
you
know
I've
been
doing
this
a
decade
and
I
wanna
make
sure
that
things
are
in
place
so
that
both
the
postman
roadmap
and
the
async
roadmap
are
free
from
obstacles
and
there's
certain
nourishing
things
that
are
there.
C
You
know
down
the
road
and
for
for
postman
when
it
comes
to
you
know,
we
we're
graphql
open
api
soap.
You
know,
that's
that
represents
a
diverse
api
toolbox
to
me
and
async
represents.
You
know
that
laying
of
that
that
road
map
five
ten
years
out
is
how
we're
going
to
do
it
and
for
me
async
api,
the
roadmap.
C
You
know
really
thinking
about
the
growth
of
open,
api
and
and
kind
of
what
we're
doing
there,
but
as
I'm
talking
with
like
lauren
and
mike
rox
folks
and
thinking
about
what
is
the
api
life
cycle?
Look
like
you
know:
we've
got
documenting,
we've
got
mocking,
we've
got
testing,
we've
got
all
of
you
know.
All
of
these
api
lifecycle
stops
that
are
pretty
mature
and
well
defined,
but
then
we've
got
you
know
innovative
ideas
like
my
crocs
out
there
kind
of
laying
the
foundation
okay.
C
What
does
this
look
like
for
an
event
in
message
driven
world?
And
I
would
say:
that's:
that's
that's
the
roadmap
I'm
most
concerned
about
is.
I
want
to
make
sure
that
that
the
future
is
laid
and
we're
building
the
infrastructure.
We
need
down
the
road
for
to
make
sure
everyone's
got
the
specs
to
to
deliver
on
the
api
lifecycle.
But
then,
once
everyone's
you
know,
you
know
defining
the
specs.
We've
got
consistent,
tooling
and
services
that
help
deliver.
Those
stops
along
the
api
lifecycle
so
that
that
uber
level
roadmap.
I
I
I
think
there
are
a
lot
of
lessons
from
the
open
api
journey
that
I
think
you
know
we
are
seeing
at
a
quantitative
level
and
a
qualitative
level
playing
out.
You
know
among
practitioners
and
companies,
you
know
from
our
data.
We
saw
that
you
know
I
mean
open
api
too,
or
I
don't
know
whether
it's
swagger
or
open.
If
I
do,
I
should
always
mix
them
up
it's
it's
still.
You
know,
I
think
there
is
work
to
be
done
to
get
people
to
adopt.
You
know.
I
Even
you
know
that
specification
and
I
think
when
fran
and
I
got
started
talking
right
when
you
know
we
looked
at
like
our
shared
goal,
is
you
know
towards
making
async
api
successful?
You
know
it's
a
you
know
it
it's
a
decade.
Long
journey,
like
I
think
I
heard
from
you
know
I
think,
red
hat
ceo
a
while
ago
that
you
know
technology
takes
like
about
eight
years.
I
You
know
to
inflect,
you
know
to
reach
a
maturity
level
where
you
know
everybody
wants
to
adopt
it,
and
I
think
what
I
believe,
fran
representing
the
async
api
community
and
postman
kind
of
felt,
was
that
we
would
want
to
make
sure
that
you
know
the
async
api
community.
Has
the
resources
to
you
know,
focus
focus
on
on
the
core
goals
of
their
community
without
worrying
about
you
know,
other
things
that
typically
fall
in
the
way
you
know.
Like
I
mean
we
are
we're
all
you
know.
I
Believers
of
you
know
api
is
an
api
first,
but
reality
you
know
always
comes
in
the
way.
So
you
know
that
was,
I
think,
the
the
overall
meta
level
stuff
and
zoltan.
You
know
we
have
been
actually
users
of
you
know
technologies
like
websockets,
we've
tried
out,
you
know
graphql
internally,
like
you
know,
when
we
started
posts
when
there
was
this
big
question
of
you
know
that
there
are.
I
You
know,
I
mean
two
broad
categories
of
apis
right,
like
it's
the
pub
sub
model,
and
then
there
is
the
http
kind
of
model.
And,
interestingly,
you
know,
postman
itself
is
built
for
our.
You
know
we
of
course
use
all
kinds
of
apis,
but
we
very
heavily
also
use
asynchronous
apis.
You
know
so
this
problem
of
you
know
managing
them.
I
Testing
them
was
very
kind
of
close
to
us
and
our
own
engineers
had
kind
of
you
know
hacked
things
around
like
you
know,
postman's
own
tooling,
to
support
this,
and
we
always
had,
like
you
know
some
custom
hack
built
out,
which
said:
okay
postman
supports
web
sockets,
now
or
newman,
which
is
our
open
source
tool.
You
know
it
supports
asynchronous
apis,
so
we're
like
okay,
you
know
we're
kind
of
coming
close
to
this
problem
that
we
ourselves
are
facing,
and
then
the
community
feedback
was
also
very
you
know,
kind
of
intense.
I
You
know
how
can
we,
you
know
make
calls
to
asynchronous
apis,
because
the
model
you
know
is
very
different
and
you
know
we
are
working
now
on
making
sure
that
you
know
we
can
make
that
interaction
like
super
easy
and
also
then
connect
to
you
know
also
use
leverage,
the
technologies
that
the
community
has
adopted
at
large.
You
know,
that's
been
postman
stands
since
you
know
pretty
much
day
one
and
you
know
in
the
early
days.
I
I
You're
impacted
by
upstream
changes,
you
know
like,
so
we
we
kind
of
had
that
experience
there
and
what
we
felt
like
was.
You
know
community
standard
emerging
as
the
you
know,
de
facto
standard
you
know
which,
which
has
has
best
practices
and
where
it
would
be
great
for
the
community
to
be,
of
course
great
for
postman,
but
it's
it's
generally
great
for
the
community.
So
you
know
in
the
coming
year
you
know
there's
going
to
be
postman,
support
for
asynchronous
apis.
There's
going
to
be
support
for
the
async
api
specification.
I
I
All
of
that
will
continue
and
to
make
sure
that
you
know
I
mean
the
specification
gets
adopted
at
scale
like
there
is
a
journey
from
you
know,
defining
the
specification
to
having
it
be
adopted
at
scale
and-
and
I
think
we
want
to
basically
play
our
part
in
you
know
getting
there.
So
I'm
pretty
excited
about
all
this.
B
B
So
that's
the
the
message
that
I
will
send
from
here
right
now
is
to
other
companies
is
to
to
do
the
the
same
kind
of
effort
right
and
and
dedicate
at
least
one
person
of
your
team
to
work
on
on
amazing
kpi
full-time.
If
that's
something
that
is
important
for
your
company
of
course,
and
also
because
that
way
we
can
maintain
neutrality
on
on
the
sync
api
right.
I
Yeah
I
mean
and
fran
I
mean
I
think
I
would
say
I
think
we
talked
about
it
privately
as
well.
Like
I
don't
understand
the
notion
of
people
controlling
a
specification
like
that
is
just
like
a
recipe
for
disaster
for
any
community.
So
when
fran
told
me
like,
is
that
going
to
happen?
I'm,
like
I
mean
it's,
just
it's
not
computing
in
my
head
like.
Why
would
anybody
want
to
you
know
control?
I
A
specification
like
I
mean
today's
world,
you
know
is,
is
I'd,
say
maybe
dominated
it's
too
strong
the
world,
but
you
know
developers
drive
a
lot
of
technology
choices.
You
know
I
mean
every
company
has
to
create,
has
to
compete
for
their
mind,
share
and
for
their
love
and
attention
and
postman
has.
You
know
itself
grown
up
as
a
bottoms
of
product,
and
you
know
we
we
care
about
developers.
I
You
know
as
the
first
agenda
before
we
think
about
other
things,
so
I
felt,
like
I
mean
again
like
I
think
it's
the
community
driving
the
specification.
Actually,
you
know
means
that
the
specification
you
know
is
is
true,
and
you
know
it
can
be
adopted,
like
a
company,
a
company
specifying
things
for
the
entire
community
just
does
not
make
sense,
so
I
think
you
know
we
were
pretty.
I
think
we
came
to
alignment
pretty
quickly
on
that.
One.
C
Now
is
the
time
to
invest
more
in
in
open
api,
where
postman's
investing
a
lot
there
as
well,
not
to
the
same
level
as
the
async
api,
but
then
json
schema
as
well
is
is
critical
to
both
of
these
specs.
So
really
this.
For
me,
this
is
a
a
cor.
Async
is
a
cornerstone,
it
represents
the
future,
but
it's
it's
one
of
the
three
specs
right
now
that
are
super
critical
to
all
of
us.
C
Investing
in
and
making
making
work
now,
abhinav
touch
on
a
little
bit
on
the
open
source
piece
and-
and
I
know
this
is
near
and
dear
to
frond's
heart-
is
this
isn't
just
about
the
specs?
This
is
about
continued
investment
in
the
documentation,
the
testing,
the
converters,
the
parsers,
the
transformers.
All
of
that
I've
now
mentioned
all
the
parts
and
pieces
of
the
postman
lifecycle
that
are
open
source,
all
the
converters,
the
code,
generators
and
trying
to
figure
out
all
right.
C
C
B
Yeah,
I
agree,
and
and
thanks
for
mentioning
the
support
to
jason
schema
because
yeah
these
guys
really
need
support.
They
need
help
and
it's
jason
schema
is
a
it's
the
core
of
async
api.
I
will
say,
and
it's
the
core
of
open
api
as
well,
and
and
they
are
the
ones
who
are
suffering
from
invisibility.
The
must
right.
J
J
As
I
try
to
interpret
what
you
just
said,
definitely
should
be
a
booster
for
this
initiative.
Isn't
that
so
boosting
up
this
kind
of
things?
Another
question
do:
do
you
already
have
some
some
echoes
or
anything
from
from
this
preparation
from,
for
example,
other
other
asking
players
like
kafka
or
others?
Is
there
anything
on
that
side?
J
B
I
think
at
some
point
we'll
we'll
we
will
all
have
to
converge
into
at
some
point
right
like
into
a
the
same
goal.
Let's
say
I
think,
for
instance,
you
mentioned
confluent
because
of
kafka
right
and
kafka
becoming
a
huge
monster,
so
I
think
we
will
all
have
to
chat
at
some
point
and
converge
in
in
terms
of
goals
and-
and
I
think
in
my
in
my
head-
sorry
in
my
head-
the
way
I
see
it
is
in
the
future.
B
The
brokers
should
be
talking
specifications
right
so,
for
instance,
natively
natively
speaking
right,
like
oh
sorry,
like
kafka,
should
be
supporting
async,
api,
natively
and
probably
not
just
kafka
but
other
other
brokers.
Right,
I
know
solas,
for
instance,
is
it's
starting
to
to
grow
the
basin
kpi
support.
So
solas
is
it's
already
on
the
on
the
good
direction,
I
would
say-
and
it's
not
just
because
it's
18
kpis,
so
even
if
it's
just
another
spec
like
we
have
the
falls
at
cloud
events,
for
instance,
doing
some
also
also
some
good
work.
B
So,
if
that's
enough
for
you,
I
think
brokers
will
be
supporting
cloud
events
or
async
api
or
both
in
my
because,
my
in
my
opinion,
the
more
we
agree
into
a
specific
language
to
describe
the
information,
the
more
powerful
our
tools
will
become
right
and-
and
this
will
enable
not.
This
will
enable
even
new
lines
of
business,
not
just
not
just
fixing
or
or
getting
rid
of
some
pain
points,
but
also
opening
new,
like
I
said,
new
lines
of
business
new
opportunities
right.
J
A
B
B
Just
to
reinforce
what's
the
goal
of
async
api
right,
so
some
people
might
never
heard
about
the
gold
explicitly
but-
and
some
some
have
heard,
but
I
love
to
remind
it
that
our
goal
since
the
beginning
is
to
make
I
think
asynchronous
apis
or
even
driven
architectures
are
both
I
will
say,
as
successful
and
mature
as
rest
apis
right.
So
right
now
like
we
have
tons
of
tooling
and-
and
we
have
specs
as
well
like
open
api
for
rest
apis,
it's
very
easy
to
create
to
create
a
new
rest
api.
B
You
have
lots
of
tools,
services
to
manage
your
rest
api,
but
on
the
contrary,
in
terms
of
asynchronous
apis
or
even
driven
architectures,
we're
starting
to
see
now
some
some
light
right
like
we're,
starting
to
see
to
see
some
development
into
the
that
same
direction
right
so
so
yeah.
So
I
think,
let's
not
forget
about
it
like
this
is
the
actual
goal
of
all
of
this.
B
B
C
C
C
You
know
that
quote
the
parsers
the
generators,
the
core
tooling,
is
essential
to
making
this
work
and
it's
got
to
keep
up
with
the
spec,
and
it's
got
to
really
help
reduce
friction
for
folks
and
from
said
it
really
well
one
time
for
me
is
you
know:
async
api
is
just
a
config
file
for
most
people.
You
know
that's
how
they're
gonna
see
it
and
that's
how
I
see
open
api
most
of
the
time.
Not
everyone
loves,
loves,
handcrafting.
C
The
spec
like
like
I
do,
and
most
people
just
see
it
as
a
config
file,
so
that
that
that
tooling
is
critical
to
that
and
it's
critical
to
the
forward
motion
that
we
have.
So
I
think
that's
that's
one.
I'm
looking
forward
to
now
that
this
is
out.
Like
that's
kind
of
I
would
say,
json
schema
support
is
kind
of
the
next
big
thing
is:
how
do
we?
How
do
we
really
embrace
the
json
schema
community?
Get
them
the
support
they
need
both
from
the
async
side,
as
well
as
the
open
api
side.
C
But
then
I,
along
with
that,
is
all
right.
What's
the
tooling,
what's
the
state
of
tooling
in
the
situation
and
the
core
tooling,
the
the
parsers
generators
docs,
but
then,
what's
that
what's
each
of
those
rings
out,
you
know
the
testing,
the
mocking
and
and
the
other
parts
of
that,
and
what
do
the
service
providers
look
look
like,
and
I
really
think
that's
a
an
important
thing
for
us
to
look
at
is
what
is
the
commercial?
C
What
is
the
open
source
tooling
and
helping
really
foster
an
environment
and
invest
in
an
environment
that
everyone
can
compete,
but
everyone
can
can
also
work
together
around
the
spec
and
that's
kind
of
our
common
unifying
factor.
So
this
is
the
open
source
part
and
the
json
schema
part.
I
think
we've
got
a
lot
of
work
ahead
of
us
to
do,
but
you
know
this
is
the
the
kind
of
base
for
that.
J
J
Yes,
so
when
you
just
look
at
open
api
or
or
snkps,
you
just
put
it
that
way,
it's
just
a
config,
but
it
comes
comes
to
power
from
from
a
commercial
point
of
view,
for
example,
when
it
comes
to
yeah
having
a
more
effective
development
life
cycle
or
everything
is
that
when
you
get
the
tooling
with
it?
Yes
before
we
had
the
same
similar
things
before
and
before
and
before,
but
when,
when
the
whole
thing's
comes
into
balance,
then
then
comes
the
power.
J
So
I
think
I
think
we
yeah
you
just
put
that
so
when
we
realized
the
life
cycle
and
we
tuned
the.
For
example,
the
learnings
from
the
open
api
life
cycle
to
the
essence,
api
life
cycle
is
that
same
or
similar
or
different
or
what
are
the
differences?
And
then
you
can
put
the
stool
in
that
then
then
it's
it's
getting
the
commercialization.
J
I
think
I
think,
because
there's
also
hype
around
even
different
architectures
right
now
and
there's
a
lot
of
flaws
with
it
and
and
when
I
met
asking
api
first,
I'm
I'm
working
as
an
architect
with
big
corporations
and
enterprises,
and-
and
I
see
the
I
see
the
flow
as
we
did
with
saw-
and
we
did
also
with
the
early
adaptation
of
of
of
open
abr
swagger.
Yes,
but
if
you
can
if,
but
this
is
also
a
driver.
J
So
if
you
have
an
early
stage
like
right
now,
we
have
an
early
stage
that
can
actually
mitigate
or
kind
of
yeah
help
this
hype
to
not
to
make
that
too
much
errors.
So
that's
that's
the
most
important
things
and
then-
and
I
hope
that
I
hope
that
the
investment
and
all
these
things-
that's
why
I
was
I'm
listening
and
then
we
just
you
just
reaching
and
just
reiterating
right
now.
That's
the
roadmap,
where
this
balance
is
keeping
in
in
pace.
J
I
That's
what's
in
one
thing,
you
know,
I
would
add
from
our
experience
right
and
maybe
something
that
the
community
is
already
seeing.
So
you
know
basically
specifications
tools
and
people
kind
of
co-evolve
in
these
feedback
loop
cycles.
You
know
when
we
first
put
postman
out,
we
just
didn't
know
what
will
happen.
You
know.
I
Basically,
it
was
out
and
people
started
using
it
and
then
more
and
more
kind
of
things
started
happening,
and
the
interesting
thing
I
think
about
specifications
stress
you
know
kind
of
is
that,
of
course
you
need
the
tools
and
then
you
need
an
option
to
get
those
feedback
cycles
kind
of
going.
I
think
the
interesting
thing
at
this
point
in
time
is
going
to
be
like
a
specification
confers
a
lot
of
power.
You
know
and
and
the
the
challenge
right
is
like.
How
is
that
power
going
to
be
used?
I
You
know
so
when
we
look
at,
you
know,
designing
the
product
and
I'm
sure
that's
going
to
be
reflected
in
the
tools
that
the
community
builds
is
like
yeah.
You
know
we're
kind
of
doing
all
this
work
specifying
things
and
you
know
taking
in
that
input
and
the
time
and
energy
from
people
to
build
out
a
specification
is
important
because
it
has
all
of
these.
You
know
benefits,
but
those
benefits.
I
think
our
tooling
tools
are
typically
seen
as
an
accelerant
of
like
okay.
Whatever
the
specification
does,
let's
make
that
happen,
you
know.
I
Sometimes
we
have
seen
that
even
the
you
know
counter
like.
Let's,
let's
not
give
all
of
that
power,
you
know,
because
sometimes
you
know
a
very
powerful
tool
in
the
hands
of
a
misinformed
committee
or
a
person
can
do
more
harm.
You
know
in
that
case,
sometimes
it's
better
to
actually
not
have.
You
know,
like
you,
don't
want
your
tools,
and
you
know
these
things
to
become
dictators
right
at
some
point.
I
So
I
think
that's
an
interesting
observation
that
I've
had
in
the
evolution
of
you
know
like
api
companies
and
api
tools
and
companies
which
land
too
much
on.
You
know
we're
going
to
give
you
all
of
this
power,
and
you
know
give
you
all
of
this.
Like
magical
things,
you
know
eventually
developers
end
up
resisting
that
because
it
you
know
it
doesn't
align
with
like
their
their
goals.
I
think
kin-
and
I
have
talked
about
this
like
how
what's
the
right
balance
between
and
what
is
the
right
composition
of
tools.
I
B
Yeah,
actually,
the
way
the
way
I
see
it
is
in
my
in
my
head
is
hopefully
at
some
point.
Nobody
knows,
or
nobody
is
using
using
kpi
right.
Hopefully,
hopefully
we
reached
that
point
where
nobody
needs
a
spec
or
nobody
needs
to
write
that
spec
or
be
aware
that
they're
using
the
spec,
like
everything,
is
so
transparent
for
them
that
the
spec
is
there
behind
the
scenes,
but
you
don't
even
notice
it
right
same
same.
B
For
instance,
you
you
use
http
every
day
right
to
visit
the
website,
but-
and
you
might
type
http
colon
slash
blah
blah
blah,
but
tcp
is
behind
the
scenes
and
most
people
don't
know
right,
and
why
would
you
would
you
need
to
know
how
tcp
works?
You
don't
care
that
the
tooling,
in
this
case
the
browser,
it's
abstracting
this
for
you
right
and
everything
is
obstructed.
So
you
don't
need
to
care
about
it
or
whenever
you
want
to
compose
a
new
document,
a
pdf
document.
B
You
have
tools
to
edit
the
documents
to
create
new
ones,
blah
blah
to
manage
it
to
manipulate
it.
You
don't
have
to
go
and
and
write
in
pdf
format,
text
right
like
adding,
adding
all
the
layers
text
here
in
this
position
here
and
there.
No,
no,
that's
crazy.
No,
nobody
wants
to
do.
Nobody
wants
to
build
a
pdf
document
like
this
I
mean
I
mean
nobody.
There
will
be
people
for
sure,
but
but
my
point
is
that
to
make
it
really
powerful,
is
you
need
to
obstruct
these
things
out?
B
B
But
it's
like
this,
it's
behind
the
scenes.
You
don't
even
notice
right
how
we're
gonna
achieve
this.
I
have
no
idea
right.
I
have
I.
I
have
lots
of
ideas,
but
I
have
no
idea
how
we're
gonna
make
it
work
right,
because
it's
impossible,
it
doesn't
depend
on
a
single
person
or
company
right.
It
depends
on
the
whole
world.
So
this
this
is
closed
to
be
chaotic
right,
so
so
yeah
but
yeah.
In
my
opinion,
this
this
would
be
like
transparent
right
or
not
transparent,
actually
opaque.
C
J
Going
to
kill
him,
maybe
that's
not
the
right
sentence,
you
just
said,
but
it's
about
other
passion.
Isn't
that
I
mean
yeah.
You
know
what
I
know
what
you
mean.
I
didn't
turn
back
again
to
kim
it's
it's.
The
crucial
point
here
is
the
life
cycle
and
how
how
how
this
works
with
the
developer
activities
and
the
developer
activities
or
any
kind
of
activities,
how
you,
how
you
put
it
into
the
tooling
as
you
call
it?
J
C
It's
seamless
and
shared,
I
would
say
the
one
lesson
from
soa
is
like
you
know,
you
can't
just
dictate
what
the
life
cycles
can
be.
What
are
all
the
tools
are
going
to
be
and
have
the
governance?
This
has
to
be
a
community
driven,
and
that's
really
what
I
learned
fighting
all
of
the
soa
people
with
swagger
and
evolving.
That
is
they're
like
haven't
we
done
this
before
like
and
it
didn't
work.
You
know
it's
like
well
wait.
C
This
is
a
much
more
community
diverse,
fragmented,
yes,
but
it's
a
it's
a
share,
it's
more
of
a
shared
collective
vision
of
how
you
move
forward
the
life
cycle,
one
that
comes
and
goes.
You
know
the
some
tools
are
here
one
day
and
they're
dominating
and
the
next
day
they
fall
into
the
the
background,
because
they
they
weren't
actually
doing
what
they
should
do
and
and
achieving
that
seamless
vision
that
that
frown
was
just
talking
about.
So
I
really
see
that
as
being
the
future
is
it's
got
to
be
a
shared
collective
vision?
C
It's
got
to
be
a
mix
of
commercial
and
open
source
tools
and
with
that
the
the
specs
at
the
heart
that
really
drive
that,
but
that
momentum
of
the
api
factory
floor
that
that
gets
us
all
moving
forward
in
concert
is
made
up
of
many
little
parts
and
pieces
of
commercial
and
open
source
software,
but
all
unified
around
the
spec.
And
I
think
that's
our
common
language,
our
common
vocabulary.
Absolutely
thank.
F
A
G
C
Is
it
well,
I'm
gonna
speak
to
this,
because
this
is
this
is
near
and
dear
to
my
heart,
and
I
know
we're
all
in
alignment
and
front
and
I
and
honestly
like
we're
working
on
cleaning
up
and
learning
the
lessons
from
this
in
open
api
right
now.
So
there's
a
I
thoroughly
encourage
you
with
your
organization,
convinced
to
join
the
open
api
as
well
as
a
member
and
get
involved,
because
we're
there's
a
shift
in
the
landscape,
bringing
in
a
lot
and
more
new
voices
into
the
oai
to
kind
of
shift.
C
The
tone-
and
I
would
say,
move
the
open
api
from
a
kind
of
a
defensive
position,
because
when
we
put
it
into
the
linux
foundation
and
created
the
oai,
it
was
very
much
to
defend
the
spec
against
several
acquisition
or
or
suitors
that
were
wanting
to
acquire
it
and
lock
up
its
vision.
Kind
of
what
abhinav
said
and
you
know
is
unheard
of-
and
you
know-
and
I
would
say,
while
that
we
we
averted
that
there
was
still
enough
fragmentation
with
the
name
swagger.
What
is
the
tooling?
What
is
the
spec?
C
There
wasn't
enough
education
about
what
is
the
difference
between
swagger
and
open
api.
Like
I
said
earlier,
the
tooling
wasn't
there
the
core
tooling,
to
help
keep
pace
with
generating
and
converting
and
parsing,
and
so
I
learned
a
lot
through
all
of
that.
I
learned
a
lot.
I've
learned
a
lot
working
with
the
oai
over
the
last
five
years.
C
I'm
learning
a
lot
as
we
try
to
course
correct
this,
this
ship,
the
oai
and
in
the
linux
foundation,
and
so
I'm
hoping
to
take
all
of
those
lessons
and
work
with
fran
to
to
find
the
right
home
to
make
sure.
Not
only
do
we
put
it
in
the
right
place,
whether
it's
it's
linux,
whether
it's
apache,
whether
it's
cncf
you
know,
do
our
work
to
figure
out:
okay,
here's
the
right
home,
but
then
what
does
that
mean?
What
goes
in
there?
C
What's
you
know
the
core
tooling
being
part
of
it,
the
spec
being
part
of
it
and
then
quickly
going.
You
know,
as
we
talked
about
what
is
the
relationship
with
oai
and
json
schema
and
figuring
out
that
relationship
because
they're
all
interdependent
and
then
quickly
get
to
work
on
the
open
source
tools,
even
not
just
the
core
tooling,
but
the
life
cycle,
the
rest
of
it,
and
so
we've
learned
a
lot
and
there
was
some
some
bad
moves
made
in
putting
swagger
into
the
into
the
linux
foundation.
C
C
So
it's
the
airline
operators
trying
to
reinvent
themselves
and
they're
doing
it
with
by
creating
an
open
api
spec
for
the
travel
industry,
and
so
healthcare
is
doing
that
right
now,
we've
all
seen
the
banking,
so
there's
several
missteps
that
we
made
with
swagger
putting
it
into
the
open
api.
I
would
say
the
first
is:
the
name
was
the
biggest
confusing
part
is
why
it
changed
names,
but
I
think
how
you
structure
the
governance
organization,
the
relationship
to
the
core,
tooling,
the
relationship
to
the
the
wider,
not
just
the
core,
but
the
open
source,
tooling.
C
The
relationship
with
the
api
service
providers,
the
commercial
offerings,
the
oai,
unless
you're
a
member
really
doesn't
do,
engage
with
you
as
a
service
provider
in
the
space.
So
we're
looking
at
changing
a
lot
of
these
things
in
the
oai,
but
then
really
take
all
those
learnings
and
make
sure
that
that
we
do
this
as
as
wisely
as
possible.
What
we've
learned
when
it
comes
to
async
and
then
similarly
invest
in
json
schema
and
to
try
to
make
sure
that
that
community
has
what
it's,
what
it
means
as
well.
C
B
That's
why
we
we
decided
to
to
include
parsers
generator.
You
know
all
this
stuff,
all
this
core
tooling,
along
with
the
spec
right,
so
so,
whenever,
whenever
we
decide
to
work
on
the
on
the
spec,
we
also
decide
to
work
on
the
core
on
the
core
tooling,
because
we
thought
it
was
key
right
it.
We
know
that
there
are
other
companies
implementing
their
own
tooling
for
parsing
async
api
and
that's
fine,
for
instance,
mulesoft
is
is
doing
their
own
parser
and
it's
actually
it's
actually
a
really
good
partner.
B
B
B
It's
it's
really,
it's
really
hard
to
make
or
to
get
something
that
is
really
complete
right
and
I
think
honestly,
I
don't.
Some
people
see
some
business
there
as
well
like
okay,
so
we
create
the
the
the
async
api
parser
and
the
async
api
generator,
and-
and
this
will
be
the
best
one
that
you
can
choose-
we
place
a
commercial
offering
here
and
there
and
we
make
we
can
make.
We
can
make
money
right.
But
again,
the
goal
of
facing
kpi
is
not
to
make
money
with
this
right
is.
B
It's
nothing
compared
to
what
we
can
enable
by
by
opening,
let's
say
by
opening
the
core
tool
into
to
everyone
right
for
everyone
to
contribute
and
to
and
and
to
unify
it.
Somehow
right,
like
you
get
we
get
to
work
all
of
us
together
we
get
to
work
into
a
single
parser,
which
is
the
the
official
parser.
If
you
want.
This
is
the
official
generator.
B
It
doesn't
have
what
you
need.
Okay,
so
you
can
implement
that
feature,
but
you
don't
have
to
re-implement
the
whole
thing
from
scratch
for
just
for
yourself
right
and
collaborate
in
a
single
place.
If
you
want
to
create
your
own
parser,
that's
totally
fine
as
well
like
we're
not
saying
people
should
not
be
doing
that.
Actually,
at
some
point,
what
happened
to
us
is
that,
by
looking
at
what
others
were
doing,
we
were
incorporating
some
features
into
our
parser
as
well
right.
So
this
is
also
good.
B
I'm
not
saying
this
is
this
will
stop
right,
but
people
still
have
at
least
the
the
official
version
of
the
tooling
of
the
core
tooling,
to
use
it
and
to
and
to
build
their
businesses
from
this
right,
like
like
abele,
for
instance,
is
doing
so.
I
believe
ableist
business
is
not
for
sure
to
power,
citizen
kpi
documents
right,
it's
it's
to
offer
other
other
features,
other
value
to
their
customers
right,
parsing,
async,
api
documents
is
just
one
step
to
provide
this.
B
This
value
right
and
we
shouldn't
be
putting-
or
they
shouldn't
be,
putting
a
lot
of
time
and
effort
into
developing
that
piece.
This
would
be
just
something
that
they
get
for
for
free
right
like
or
almost
for
free.
That's
it
right
so
yeah.
So
I
think
that
that's
to
me
that's
a
lesson
that
we
should
learn
from
open
api
having
the
core
tooling,
together
with
the
spec
right.
It
shouldn't
be
separate,
so
important.
B
What's
the
governance
model,
I
don't
know
this
is
something
that
we'll
have
to
figure
out
once
we
go
to
a
foundation,
but
for
sure
we
want
to
have
these
things
together.
We
want
to
make
things
as
similar
as
and
as
I
don't
know
how
to
how
to
frame
this
in
english,
but
so
we
want
to
avoid
company
interests
to
for
from
blocking
the
development
of
facing
kpi
and
the
tooling
right.
So
this
this
will
be.
We
should
find
a
way
to
to
to
avoid
that.
Basically,.
C
Well-
and
I
think
that's
another
level
of
the
learnings-
is
it's
not
just
the
overt
you
think,
a
company
how
a
company
is
going
to
come
in
and
and
dominate
or
all
roads
lead
to
their
commercial
offerings
that
we've
seen
so
much
in
open
source.
There's,
there's
many
other
tactics
in
slowing
stopping
a
vote.
There's
the
inaction
can
sometimes
be
as
just
as
damaging
as
action
and
so
front,
and
I
have
spent
a
lot
of
time
thinking
about
this.
C
So,
there's
a
lot
of
ways
that
that
these
voices
can
drive
the
spec
and
and
the
key
part
is
that
we're
all
kind
of
in
motion
and
moving
at
the
same
speed
and
that's
really
difficult
to
do
at
a
community
level
so
that
that
governance
model
has
to
speak
to
that,
and
so
fran's
been
really
good
at
and
and
lucas
as
well,
and
the
transparency
of
their
model
like
the
money
behind
it,
how
they
do
what
they
do.
Everything
they're
they're
super
transparent
about,
and
I
think
that's
going
to
be.
C
You
know
transferred
into
the
governance
model
for
this,
and
so
we
just
got
a
lot
of
planning
to
do
a
lot
of
research
on
each
of
the
organizations
talking
to
other
groups
who
are
in
the
cncf
other
groups.
You
know
who
are
in
the
apache
foundation
and
gather
learnings,
like
we've
learned
from
the
open
api,
and
I've
already
had
a
few
conversations
with
other
linux
foundation
organizations
and
so
take
all
of
that
and
then
try
to
find.
C
C
B
A
For
me,
that's
the
most
important
so
that,
with
with
this
partnership
with
postman,
that
we
can
now
focus
on
those
important
things
going
to
a
foundation
and
working
on
the
open
governance
model.
Because
that's
this
thinking
about
open
collective,
how
much
money
left
how
much
money
we
have!
How
we're
running
do
we
still
have
at
least
one
month
or
not.