►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Open Source and Standards Collaboration - Craig Northway, Qualcomm Technologies Inc
Recently there is a significant interest and need for Standards Defining Organizations (SDOs) to also participate in Open Source projects. Companies need to manage their standards and open source engagements in a coordinated manner. This has caused Industry Standards Program Offices (ISPO) and Open Source Program Offices (OSPO) to interact more frequently. Qualcomm has a rich history in SDOs and more recently is a strong developer and contributor in mobile and connectivity related Open Source projects. In this presentation we will review what we have learnt from joint engagements and collaboration between SDOs and OS. We'll discuss typical standards and open source organizations and processes and address questions such as: What can your ISPO learn from your OSPO? What can your OSPO learn from your ISPO? And how can these 2 organizations collaborate within your company?
https://sched.co/NrtD
A
Good
morning,
everyone
thank
you
for
your
attendance
here
this
morning,
how
a
standards,
an
opensource,
similar
in
different
wider
standards
of
what
to
collaborate
with
open
source
and
how
should
that
collaborate
with
open
source?
What
can
open
source
learn
from
standards
organizations?
And
finally,
what
does
this
mean
to
you
in
the
audience
today
today,
I'm
going
to
shed
some
light
on
industry
trends
on
around
how
open
source
and
standards
organizations
are
learn
to
collaborate
and
taking
on
the
best
parts
of
each
process
to
advance
the
entire
technology
industry
and
the
state
of
the
art?
A
Qualcomm
has
a
rich
history
in
standards,
organizations
and,
more
recently,
as
a
strong
developer
contributor
and
participant
in
open
source
projects
supporting
the
mobile
and
connectivity
ecosystems.
So
we
are
Nikoli
qualified
to
lead
an
industry
change
around
how
we
participate
cohesively
in
standards
and
open
source.
A
Firstly,
a
little
bit
of
background
on
Qualcomm
COCOMs,
a
company
based
in
stand
in
San
Diego
in
California
and
now
inventions
are
the
foundational
technologies
that
I
was
built
upon.
We
helped
to
invent
new
industries
and
applications
that
have
global
impact
where
the
brain
behind
your
smartphone
and
we're
leading
the
industry
to
5g
you'll
find
our
products
in
not
just
in
cell
phones
but
in
the
automotive
sector.
In
the
data
center
in-home
Wi-Fi
products,
IOT
personal
computing
and
security.
A
C
A
And
very
similar
vernacular
very
similar
ways
in
which
you
interact,
but
there
are
a
couple
of
differences,
so
this
quote
from
Rob
Langley,
a
kernel,
developer,
I
think
helps
me
to
sort
of
sum
up
what
open-source
software
means
it's
commodity
software
as
level
thank
anyone
can
participate
typically,
when
open
source
software
is
an
efficiency
where
companies
or
organizations
share
one
implementation
or
a
significant
shared
code.
So
in
this,
in
the
open
source
model,
often
companies
compete
around
the
implementation
instead
of
with
their
implementations
and
there's
a
bunch
of
different
businesses
that
fit
in
this
model.
A
A
You
know,
standards
driven
ecosystem.
You
typically
compete
on
the
implementation.
You
don't
work
on
a
you,
don't
build
a
standard
for
something
that
you
could
easily
implement
today
or
that's
already
implemented
today.
The
areas
in
which
we
invest
in
standards
often
require
some
some
long-term
R&D
investment.
Things
like
new
wireless
standards,
so
open
source
and
standards
are
different.
The
complementary
models.
A
A
Standards
organizations
are
seen
as
as
slow-moving
by
the
industry.
They've
seen
it
slow
to
take
on
implementation
feedback.
A
lot
of
standards
organizations
came
from
sort
of
a
hardware
development
background.
The
pace
seems
slow,
but
they
are
deliberate
and
thorough
in
their
development
process,
whereas
open
source
is
lived
by
the
industry
fast
and
agile,
there's
often
a
high
bar
to
participate
in
standards.
A
A
Github
is
sort
of
the
standard.
Well,
I
shouldn't
use
the
word
standard
again,
but
sort
of
the
standard
way
in
which
we
interact
in
the
open-source
community.
When
you
see
a
github
page,
everyone
knows
how
to
interact
with
that
project.
You
know
how
to
raise
an
issue.
You
know
how
to
submit
a
pull
request.
You
know
how
to
engage
with
that
project
and
you
can
see
real
anyone
can
see
real
time
what's
happening
and
it's
projects,
even
though
it's
not
hosted
on
github.
A
The
things
is
hosted
on
other
services
like
good
lab
or
things
projects
that
might
be
running
a
Garrard
instance,
or
something
like
that.
There's
still,
this
consistent
workflow
of
your
request
to
take
patches
and
the
review
of
those
patches
and
so
forth.
So
on,
where
standards
organizations
all
have
a
different
interface,
so
not
to
pick
on
I
Triple
E.
But
if
you
come
to
this
I
Triple
E.
D
A
Immediately
know
how
to
interact
with
this
organization:
it's
not
always
obvious
how
to
join
and
participate
and
there's
no
consistent
model
across
the
organizations
when
I
did
go
to
this
page
I
tried
to
work
out
how
a
random
person
would
know
how
to
interact
with
the
I
Triple,
E
and
I,
eventually
navigated,
my
way
down
to
a
forum
where
you
could
submit
request
for
membership.
But
you
know
every
standards
organization
has
its
own
set
of
rules
and
policies
and
processes
around
this.
So
it's
very
complicated.
It's
a
high
bar
to
join
and
participate.
A
A
One
of
the
problems
that
I
pointed
out
earlier
was
that
standards
have
traditionally
been
slow
about
implementation
experience
being
rolled
back
into
the
standard
software
moves
too
fast
for
this
open
source
software
in
particular.
We
need
to
get
the
best
of
both
worlds
and
enable
fast-paced
feedback
and
the
Drude
development
of
standards.
A
We
think
that
producing
some
open-source
product
will
allow
feedback
into
the
standards
process
and
improve
the
architecture
and
improve
the
speed
of
developments.
Speed
of
the
development
process
standards
organizations,
don't
necessarily
need
to
create
full
implementations
or
reference
implementations,
but
they
need
to
learn
about
open
source
collaboration
methods
to
be
able
to
do
software
and
make
standards
development
quicker.
A
Some
standards
organizations
are
already
starting
to
use
the
tools
available
to
the
open
source
software
community.
So
we
have
standards,
organizations
using
github,
free
issue,
tracking
document,
editing
internally
and
publicizing.
Sometimes
I
have
two
examples.
Here
we
have
OMA
Open
Mobile
Alliance
that
have
a
lot
of
public
content
on
this
particular
site,
but
there's
a
large
private
organization.
They
have
open
source
licensing
models
compatible
with
their
traditional
IPR
policies
and
they're.
Also
looking
at
how
to
enable
collaboration
where
royalty-free
model
is
appropriate
or
required.
We
also
have
IETF
is
an
example.
A
They
do
a
lot
of
collaboration
more
publicly
directly
on
their
specifications.
You
can
go
and
see
them
editing
some
of
these
specifications
in
public,
embracing
these
open-source
ways
of
working
or
collaborating
both
these
organizations
are
embracing
open-source
ways
of
working
or
collaborating
in
different
matters
to
accelerate
their
standards.
Development
IETF
is
also
running
hackathons.
It's
very
you
know,
familiar
concept
to
the
open-source
community
and
if
you
look
at
the
goal
here,
it
repeats
some
of
the
things
that
I've
been
been
saying
throughout
this
presentation.
A
So
now,
let's
turn
you
flipped
the
coin
here.
Can
open-source
improve
collaboration
with
lessons
from
standards,
development
processes,
I
think
the
answer
is
yes
and
I.
Think
it's
already
happening
about.
A
year
ago
the
CNC
F
released
a
service
white
paper.
The
CNC
F
I
think
everyone
here
should
know
what
the
CNC
F
is
when
I
gave
this
presentation
about
a
year
ago.
I
had
to
spell
that
out.
Well
clearly,
it
is
an
open-source
project,
part
of
the
Linux
Foundation,
but
they
were
also
building
a
standard.
A
This
serverless
white
paper
is
effectively
a
service,
computing
event,
format
and
API.
Now,
why
are
they
doing
this
mostly
to
event
avoid
vendor
lock-in?
Even
in
the
cloud
technology
space
which
is
dominated
by
open
source
projects
open
source
software,
they
still
have
a
potential
problem
of
vendor
lock-in
if
services
are
not
easily
interchangeable,
there's
a
real
possibility
of
this
occurring.
A
So
how
many
times
have
you
written
glue
code
to
stick
together
various
pieces
of
open-source
code?
Have
you
ever
tried
to
replace
one
JavaScript
library
you're
using
with
another
standard
interfaces,
are
important
even
in
the
open-source
community,
I
actually
picked
Lego
as
an
analogy
of
something
I
thought
was
a
good
standard
interface,
but
then
I
thought
about
it
a
bit
more
and
it
turns
out
it's
really
a
proprietary
vendor.
A
Looking
with
Lego,
so
I
was
looking
around
for
a
better
example
of
how
standards
enable
us
to
you
know,
maintain
in
droplet,
EB,
opera,
interoperability
and
backwards
compatibility,
and
so
I
came
back
to
the
telephone
or
communication
systems
where
we
have
a
great
story
of
interoperability.
Over
many
many
years
we
have
a
broad
ecosystem,
participating
in
governance
and
a
coordinated
approach
and
your
old
rotary
dial
telephone.
A
If
you
have
the
right,
if
you
you
might
have
to
call
up
your
your
service
provider
and
get
them
to
you
know,
rename
all
the
pots
standard
on
your
particular
line,
but
chances
are,
you
can
probably
get
your
rotary
dial
telephone
to
still
call.
You
know
the
cell
phone
that
your
friend
has
there
was
released
yesterday.
This
is
industry,
and
this
interoperability
and
backwards
compatibility
is
relying
on
standards.
A
If
you
compare
that
to
the
internal
interoperability,
we
see
in
open-source,
sometimes
even
between
projects
that
work
in
the
same
ecosystem
or
even
different
versions
of
a
fast-moving
open-source
project.
You'll
see
that
the
standards
have
some
value
in
enabling
this
long-term
interoperability
and
backwards
compatibility.
A
Mind
Kevin
mentioned
numerous
standards
Construction
this
article
that
are
being
implemented
in
open
source
communities
through
forums
such
as
the
Linux
Foundation
that
provide
long-term
guidance
from
end-users,
not
just
the
developers
active
in
the
project
in
his
article
he
explained
how,
by
the
time,
an
enterprise
can
integrate
test
and
roll
out
a
project
potentially
you're
out
of
date
and
left
behind
by
the
by
the
latest
version
of
the
project.
I
was
discussing
this
with
some
standards.
A
A
Another
potential
issue
in
open-source
projects
that
standards
like
governance
structures
can
help
avoid.
Is
fragmentation,
fragmentation
results
from
multiple
projects
each
deliver
part
of
an
overall
solution
that
can't
be
used
together,
frustrating
at
any
progress
and
interfering
with
high-level
innovation.
A
Steering
the
the
roadmap
of
a
set
of
related
project
by
a
broad
stakeholder
group
not
having
not
just
having
each
project
driven
by
a
couple
of
key
maintainer
Zoar
committees
in
isolation,
helps
to
solve
this
problem,
so
I
think
we've
seen
open-source
foundations
take
on
this
role
of
providing
this
high-level
guidance
through
technical
steering
committees
and
the
like
to
avoid
fragmentation.
So
I
think
this
is
an
example
of
open
the
open
source,
community
learning
and
evolving
based
on
standards
practices.
A
Another
thing
that
standards
organizations
have
had
for
a
long
time
is
clear:
contributing
and
participation
rules,
clear
rules
for
membership
and
how
you
should
participate.
They
have
good
processes
around
disagreement
and
coming
to
conclusion
with
sent
consensus
which
helps
to
get
diverse
participation
from
all
members.
A
For
instance,
I
probably
had
an
ethics
committee
since
the
1970s
an
open
source.
We've
only
really
started
to
focus
on
this
sort
of
behavioral
concerns
and
interactions
between
the
people
in
the
last
few
years.
I
think
we're
doing
a
great
job
and
moving
forward
in
spreading
codes
of
conduct,
and
things
like
that.
The
contributor,
confident
but
standards
organized
have
been
doing
this
for
some
time.
A
But
what
about
IP
policy
so
one
concern
that
people
might
have
with
standards
and
open-source
interacting
is
how
does
the
IP
policy
work
as
we
know
from
standards
over
the
years,
some
projects
thrive
under
royalty-free
frameworks,
whereas
some
projects
thrive
under
under
Fran
frameworks?
That's
fair,
reasonable
and
non-discriminatory
frameworks.
A
So,
typically,
when
you
have
something
videos,
you
know
closer
to
the
near
term,
that
can
be
more
immediately
realized
in
product
development.
These
sort
of
projects
tend
to
fare
well
under
royalty-free
frameworks,
things
that
involve
a
larger
investment
in
R&D
higher
risk,
advancing
the
state
of
the
art
and
the
science
that
might
fail
tend
to
throw
better
under
Fran
terms,
there's
not
necessarily
a
universal
key
for
both
worlds.
Our
worldly
free
is
not
necessarily
going
to
work
in
all
situations.
A
So
one
problem
with
standards
and
one
problem
with
open-source
projects
under
royalty-free
terms
and
using
them
as
standards,
is
that
these
royalty-free
open-source
licenses
may
not
always
make
clear
what
standards
essential.
They
might
only
apply
royalty-free
terms
to
a
specific
implementation
and
they
may
not
grant
rights
to
all
contributions
from
everyone
another.
You
can
have
standards,
an
open
source
collaboration
purely
under
a
royalty-free
open-source
license.
You
probably
need
an
IP
policy
or
agreement
for
the
standard
as
well.
A
That
clearly
stipulates
the
terms
for
any
implementations
and
all
of
the
essential
IP
many
existing
standards,
development
organizations
have
friend
or
disclosure
only
IP
policies,
and
these
have
worked
very
well
in
some
situations.
If
we
consider
two
aspects
of
licensing
copyright
and
patents,
if
we
can
enable
these
organizations
to
work
with
an
open
source
based
copyright
license
and
a
Frane
patent
policy
by
making
the
source
code
licensed
copyright
only
and
potentially
adding
an
explicit
pointer
to
the
IP
policy
to
cover
patent
commitments,
we
think
we
can
make
open-source
and
standards
work
together.
A
So
I've
talked
about
why
standards
organizations
want
to
participate
in
open-source
what
standards
organizations
can
learn
from
the
open
source
community
and
what
the
open
source
community
can
potentially
learn
from
standards
organizations.
Now?
What
can
we
do?
What
can
the
people
in
this
room
the
people
from
the
open
source,
community,
the
people
from
open
source
program
officers
or
the
people
from
industry
standards
activities
do
to
make
this
a
reality?
A
So
if
you
have
an
industry,
standards,
office
or
you're,
working
with
an
SDO
or
part
of
an
SDR
there's
a
couple
things
I
think
you
need
to
learn
about
open
source
that
you
can
learn
from
open
source
program
officers.
The
first
one
is
open
source
compliance
and
the
effective
non-compliance
in
standards.
Organization
structures.
With
these.
A
Membership
policies
and
IP
policies
is
can
be
very
important
to
ensure
compliance
all
around
another
important
thing
that
the
participants
in
industry
standards
and
the
standards
organizations
need
to
learn
about
these
open
source
development
practices.
They
need
to
learn
about
how
the
open
source
community
does
community
does
CI
and
testing.
They
need
to
learn
about
how
the
open
source
community
in
chores-
you
know
parity
with
the
broad
community
and
tool
availability
for
everyone,
and
they
need
to
go
know
about
how
open
source
offices
and
open
source
projects
deal
with
security
vulnerabilities.
A
They
also
need
to
learn
about
open
source
community
best
practices.
Things
like
how
the
community
does
issues
involve
tracking
how
we
do
documentation
the
importance
of
chat
in
the
community,
what
a
fair
and
in
review
and
response
process
years
in
for
an
open-source
project,
and
they
need
to
learn
about
monitoring
and
metrics
for
project
health.
A
Software
developers
often
typically
just
go
chasing
the
next
exciting
project.
Rather
than
going
back
to
update
documentation
to
match
implementation
changes,
standards
processes
tend
to
work
around
more
formalized
release
and
review
processes.
They
tend
to
produce
high
quality
work
products
prior
to
public
release
after
a
private
or
semi-private
collaboration,
and
then
generally
include
good
documentation.
Some
open
source
projects
could
stand
to
benefit
from
the
increased
rigor
in
releases
of
their
code
and
documentation.
A
Open
source
project
need
to
learn
about
governance
and
antitrust
compliance.
If
they're
going
to
be
involved
in
staunton
standards,
organizations,
good
and
impartial
governance
helps
avoid
the
creation
of
overlapping,
non
diverse
and
confusing
projects
and
open
source
projects.
As
I
said
before,
that,
don't
connect
to
form
larger
architectures
can
also
create
fragmentation.
A
A
They
have
process
around
disagreement
and
coming
to
conclusions
with
consensus.
They
also
tend
to
have
strong
antitrust
laws,
helping
participants
to
abide
by
competition
law.
The
other
thing
that
I
mentioned
is
interoperability
and
backwards
compatibility.
This
is
a
key
thing
that
I
think
open-source
can
learn
from
standards
if
they
dil
collaborate
together
further.
A
A
A
So
we've
collaborated
with
the
standards
organization
to
include
some
additional
material
into
our
open
source
training
because,
like
with
open
source,
the
most
effective
way
to
avoid
issues
is
generally
proactive,
education
and
awareness.
So
our
messaging
is
evolving
that
our
training
will
also
include
guidance
about
these
sort
of
dual
process.
Engagements,
where
a
project
might
be
both
open
source
will
be
both
an
open
source
project
and
a
specification.
A
So
we
also
collaborate
on
compliance.
We
leverage
our
open
source
compliance
process
and
there's
some
escalations.
We
have
around
that
our
contribution
process.
We
leverage
that
to
also
ensure
that
we
capture
information
about
standards,
implementations
or
standards
participation,
and
we
also
collaborate
a
lot
on
outreach.
So
we
have
events
like
our
qualcomm
open-source
summit,
where
we
invite
open
source,
influential
people
in
the
open
source
community
to
come
and
present
to
the
company.
A
So
we
collaborate
on
you're
covering
a
broad
range
of
topics
there
that
blows
into
standards
and
also
inviting
the
standards
team
to
such
events,
we've
aligned
our
review
processes
and
we
agree
on
clear
handoff
points
between
the
different
parties.
So
a
quote
from
one
of
my
colleagues
in
his
way
of
knowing
when
it's
open
source
and
when
it's
a
standards
organization,
he
said
that
standards
organizations
ask
you
to
join
and
open
source
projects.
Ask
you
to
contribute.
A
So
we
have
a
nice
clear
delineation
in
our
process,
where
we
handoff
from
say
an
open
source
review
into
a
standards
review
or
vice-versa.
So,
depending
on
the
questions
that
we
ask
as
part
of
the,
we
also
regularly
host
strategy.
Member
meetings
between
key
members
of
our
standards,
industry
group
in
our
open
source
team,
we
discuss
open
source
in
various
industry
bodies
and
we
track
the
status
and
progress
of
those
groups
towards
a
workable
model.
A
A
Think
standards
and
open
source
will
continue
to
blend
further
over
time,
we'll
start
to
see
more
hybrid
organizations
or
coordinated
organizations,
then
mix
the
structures
of
open
source
and
standards
will
see
more
standards
like
construction,
open
source
projects
to
provide
better
governance
and
improved
collaboration
for
more
parties
will
see
standards.
Development
start
to
utilize
the
methods
for
collaboration
used
by
the
open
source
community
such
as
github.
A
While
this
is
happening,
though,
we
want
to
preserve
the
value
of
standards
and
shura
means
to
competing
implementations
and
incentives
for
long
term
R&D
investment
as
standards
adopt
practices
from
open
source
and
develop
open
source
to
ensure
fast-paced
implementation
feedback.
I
think
that
everyone
in
the
industry
needs
to
consider
a
coordinated
approach
to
both
their
standards
and
open
source
activities.
D
C
I
directly
asked
about
the
process
in
the
company.
Do
you
have
any
best
practice,
sir,
for
the
review
process,
because
if
we
create
a
strict
process
to
contribute
to
open
source
project,
it
takes
a
long
time
to
contribute
yeah
but
I'd
like
to
reduce
this
costs.
So
if
you
have
any
Rock
example,
either
have
to
know
yeah.
A
So
in
some
cases
it's
very
challenging
to
reduce
that
time.
So
I,
don't
think
you
can
reduce
that
time
for
every
case.
So
if
you
have
to-
or
your
lawyers
want
to
do
something
like
a
patent
search
for
a
particular
contribution,
then
that
might
take
a
long
time
so
I.
The
most
success
we've
had
is
by
having
sort
of
exceptions
to
the
long
process,
so
working
out
what
you
can
easily
approve
quickly.
So
the
easiest
one
is
like
bug
fixes
test
code
documentation.
A
You
can
have
a
fairly
abbreviated
process
for
those
sort
of
contributions
because
they
typically
not
have
concern
to
your
illegal,
not
as
much
concern
to
your
legal
department.
So
we
have
a
documented
policy
around
those
particular
exemptions.
So
if
you
fall
into
that
category,
it's
very
quick
and
then
by
classifying
what
classifying
upfront
which
areas
are
of
IP
concern,
so
you
sort
of
know
which
technologies
you
need
more
review
in
advance
and
that
way
you
can
quickly.
A
Make
a
give
a
faster
review
to
project
if
it
doesn't
fall
into
those
IP
areas,
and
we
actually
have
a
couple
different
grades
of
process
right.
So
there's,
basically
three
so
the
lowest
here
where
you
can
get
a
very
relatively
well.
First
is
the
bug
fixes
test
code
documentation
then
there's
the
lowest
tier
of
IP
concern,
which
is
very
quick
and
doesn't
require
escalation
to
like
a
review
board,
and
then
the
two
levels
require
escalation
up
to
a
review
board
and
potentially
things
like
your
patent
searches
and
lots
of
lawyers.
E
B
A
A
You
have
organizations
like
the
Linux
Foundation
there's
this.
A
new
joint
development
foundation
has
recently
come
under
the
Linux
Foundation
and
that's
a
way
to
standardize
based
on
an
open-source
project
and
so
I
think
that's
in
the
short-term.
That's
how
open-source
foundations
will
move
into
the
standardized
it
patient
process
by
standardizing
around
their
open
source
projects,
whereas
on
the
SDO
side,
I
think
we'll
start
to
see
stos
that
produce
open
source
code
that
accompanies
their
standard
implementation.
I,
don't
think,
we've
seen
a
organization
that
does
both
standards
first
and
open
source
first,
yet.