►
From YouTube: Building a Successful Open Source Community as an End-user Company - Henrik Blixt & Kareena Hirani
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Building a Successful Open Source Community as an End-user Company - Henrik Blixt & Kareena Hirani, Intuit
Have you ever thought about open sourcing a project but don't know where, or how, to start? Maybe you have already dipped your toes, but want to know more about what the process entails?
Many open source projects are vendor backed with plenty of funding and backed by an army of marketing, program managers, solution architects and support, but if you’re not a vendor and lack all these resources, how do you grow your community and project?
The Argo project was initiated by Applatix, after acquiring the company Intuit has carried the torch and Argo is now deployed at hundreds of companies and has a large and diverse community. However, the path wasn’t always easy and a lot of efforts went into making Argo what it is today.
Come and listen to Kareena and Henrik as they tell the Argo journey story; the struggles, the learnings and the successes.
The stories told will be applicable to any other open source projects and whether you work for an end-user of vendor company.
B
Hi
everyone,
my
name,
is
karina
hirani.
I
am
a
software
engineer
at
intuit.
I
work
on
the
argo
rollouts
team,
which
is
responsible
for
progressive
delivery
of
applications
in
kubernetes.
I've
been
part
of
the
open
source
community
for
the
last
year
and
a
half.
I've
been
a
software
engineer
for
about
four
years
and
I'm
really
enjoying
my
experience
in
the
open
source
community.
A
Around
quickbooks
we
have
about
10
billion
dollars
in
revenue
from
our
over
60
million
customers
that
runs
on
on
our
platform
and
we've
taken
this
fintech
company
on
a
very
interesting
journey.
Over
the
last
few
years,
where
we
had
very,
we
were
a
very
traditional
company
running
in
data
centers,
a
lot
of
traditional
applications,
traditional
architecture
to
now,
lately
a
fully
cloud
native
running,
a
public
cloud
platform
using
cutting-edge
technologies.
A
A
And
then
we
have
argo
rollouts,
which
enable
progressive
delivery
with
advanced
deployment
strategies
for
application
rollouts
like
blue,
green
and
canary
strategies,
and
then
we
have
two
projects
that
are
on
more.
On
the
ml
side,
we
have
argo
workflows,
which
is
a
swiss
army
knife
of
a
workflow
engine
that
can
be
used
for
things
like
massive
job,
parallelization
and
automation,
and
it's
currently
used
with
throughout
our
user
base
and
within
intuit
for
ml
data
pipelines
and
various
infrastructure
automation.
A
And
then
we
have
argo
events,
which
is
an
event-driven
framework
to
help
you
trigger
actions
when
various
events
occur
in
external
event,
sources
very
commonly
used
together
with
workflows
to
trigger
a
workflow.
When,
when
something
happens,
and
just
a
proof
point
on
how
far
we
have
come
and
where
we
are
today,
with
our
argo
projects,
we
currently
have
over
18
000
stars,
which
is
almost
doubling
since
almost
a
doubling.
A
And
quickly
about
the
timeline,
how
these
four
projects
came
to
be
and
how
argo
came
to
be
all
together,
they
were
incubated
at
a
startup
called
atlantic's
a
little
bit
over
four
years
ago
and
as
part
of
the
transformation,
the
platform
transformation.
I
mainly
mentioned
earlier
when
that
started
into
it
was
acquired
by
by
sorry.
Athletics
was
acquired
by
intuit
to
help
through
this
transition.
A
Argo
workflows
was
currently
there
with
the
platix,
as
that
team
started,
getting
heads
down
and
building
this
new
platform
for
intuit
the
need
for
something
to
manage
application
and
and
the
delivery
application
was
was
born,
and
that's
where
argo
cd
came
out
a
little
bit
later
that
same
year,
we
had
one
of
our
users
blackrock.
That
would
be
using
workflows
for
a
long
time,
contribute
argo
events
and
that
you
know
made
a
a
trio
of
projects.
A
After
all,
the
city
was
put
in
production
into
it.
There
were
additional
requirements
and
learnings
that
led
to
the
you
know
to
the
understanding
and
development
of
argo
rollouts.
We
needed
something
that
could
do
progressive
delivery
and
these
advanced
deployment
strategies,
but
we
didn't
want
to
build
that
into
one
of
the
existing
projects
because
we
want
to
keep
them,
keep
them
separate
I'll
talk
more
about
it,
a
little
bit
and
keeping
the
modular
and
more
as
building
blocks.
A
So,
hence
you
know
argo
rollouts
came
out
of
came
out
of
that,
and
lately
we've
been
focusing
more
on.
You
know,
polishing
and
and
getting
argo
as
a
project
mature.
You
know
the
features
that
they
have.
The
products
are
there,
but
we
also
want
to
make
sure
that
the
project
itself
in
terms
of
governance
maturity
is
there
so,
like
I
said,
we've
incubated
with
cncf
we're
currently
working
towards
graduation
and
as
part
of
this
process,
we've
gone
through.
You
know
a
number
of
steps
to
to
standardize
our
governance,
membership
responsibilities
and
things
like
that.
B
So
some
benefits
of
open
source
that
we
believe
are
that
it
helps
build
better
software,
and
we
believe
that,
because
you
have
a
large
community
involved
with
your
project,
which
means
lots
of
different
peer
reviews,
a
big
variety
of
ideas
and
contributions
and
because
the
code
is
completely
open
to
the
public.
We
believe
this
demands
a
higher
standard
of
code
and
also
of
professionalism,
because
contributors
take
more
pride
in
they
were
in
their
work.
B
They
realize
that
everyone
can
see
everything
it
it's
a
point
of
pride
for
them,
and
another
great
thing
about
open
source
is
that
we
believe
it
attracts
and
retains
talent.
So
open
source
projects
are
known
for
being
new
and
exciting,
using
all
kinds
of
cutting-edge
technologies
and
there's
also
a
pipeline
from
being
an
open
source
contributor
to
possibly
getting
hired
by
the
company,
who
runs
the
open
source
project.
B
So
it's
a
very
fun
environment
and
we
find
that
talented
engineers
do
want
to
work
in
open
source
and
another
benefit.
That
we
believe
is
that
open
source
allows
companies
to
establish
a
technology
brand,
so
open
source
projects
cannot
subsist
on
marketing
magic
because
the
technology
is
completely
public
to
the
world.
B
So
when
you
have
a
project
and
you
are
deciding
whether
to
open
source
it
or
not,
there
are
a
few
questions
you
need
to
ask
yourself.
The
first
is
is
what
you're
doing
going
to
provide
value
to
the
broad
community?
So
are
you
solving
a
problem
that
many
other
people
have,
or
is
it
something
very
specific
to
your
company
and
your
situation?
B
B
Another
thing
to
consider
is
the
time
and
commitment.
Open
source
is
a
lot
of
work
to
maintain,
and
you
need
to
put
a
lot
of
time
and
effort
into
building
and
sustaining
a
community.
So
you
have
to
consider:
do
you
have
the
backing
time
and
resources
to
make
the
project
successful,
we'll
cover
in
later
slides
just
how
much
work
it
takes
to
maintain
an
open
source
project
and
what
you
need
to
do.
B
But
the
important
thing
to
know
is
that
you
know
if
you're,
an
individual
who
has
an
open
source
project,
it's
important
to
have
approval
and
backing
from
your
managers.
So
you
have
the
time
and
resources
to
work
on
it
full
time
and
if
you're
a
company
considering
having
an
open
source
project,
then
you
need
to
allocate
funding
to
hire
engineers
full-time
and
you
need
to
commit
to
providing
resources,
even
though
it
can
be
easier
to
get
funding
for
vendors
with
business
plans.
B
So
another
thing
to
consider
is:
do
you
have
an
actual
goal
or
plan
with
your
project
or
your
idea?
So
is
it
a
short-term
goal
like
a
kubernetes
migration,
or
is
it
a
longer-term
goal?
It's
also
important
to
consider,
you
know,
is
a
specific
problem
with
the
company,
or
is
it
a
problem
that
many
people
face
and
therefore
it
would
benefit
everyone
to
get
the
community
involved.
So
we
believe
that
with
short-term
projects
like
migration,
once
the
migration
is
over,
the
project
could
eventually
become
obsolete.
B
It's
important
to
invest
in
a
long-term
project,
so
something
like
argo.
For
example,
we
have
sub-projects
that
deal
with
continuous
deployment
and
progressive
delivery,
and
those
things
will
always
be
in
need,
so
it
will
never
really
become
obsolete
at
any
point.
So
the
last
thing
you
need
to
consider
is:
will
your
project
actually
benefit
from
community
engagement?
B
If
it
is
very
specific
to
your
company,
then
it
may
not
be
worth
open
sourcing
because
it
won't
benefit
very
much
from
community
interaction.
So
maybe
it's
better
to
keep
your
project
simple
and
not
worry
about
the
community's
variety
of
use
cases
and
keep
it
very
specific
to
your
specific
company
use
cases
instead,
in
that
case,.
B
So
what
makes
a
project
good
for
open
sourcing
one
is
that
it
solves
a
very
specific
problem
in
a
unique
way
and
what's
important
is
that
it
relieves
a
problem
that
is
unaddressed
with
no
current
solution
available,
so
that
will
benefit
the
broader
ecosystem.
That
means
that
your
project
is
not
competing
with
existing
solutions,
which
could
involve
a
lot
of
politics
and
unnecessarily
competitiveness,
and
the
community
can
rally
behind
you
instead
of
thinking
which
project
they
should
choose.
B
Another
important
factor
is
something
modularized
and
something
that
can
be
used
and
integrated
easily.
So
if
you
have
a
very
big
project
with
complex
use
cases
that
introduces
a
lot
of
dependencies
on
other
technologies
and
other
open
source
projects
which
make
it
tough
to
maintain.
So
if
it's
modular,
so
you
know
it's
important
that
if
it's
modularized,
then
components
of
your
project
can
be
easily
used
by
other
open
source
projects.
B
So
in
argo,
for
example,
we
intentionally
built
it
so
that
there
are
these
different
building
blocks
like
cd,
continuous
deployment,
progressive
delivery
workflows
for
orchestration,
because
they
are
easy
to
integrate
as
one
of
the
many
tools
that
people
use.
So
we
also
think
that
mature
internal
projects
are
very
good
projects
to
open
source,
because
you
know
it
works
in
production.
Your
company
is
already
using
it.
It
has
a
lot
of
active
internal
users,
there's
an
existing
rigor
in
releases,
patching
updating
so
for
argo,
cd
and
rollouts.
B
So,
from
a
maintainer's
point
of
view
here
are
some
benefits
of
being
part
of
the
open
source
community.
Being
part
of
the
community
can
be
great,
they
are
very
generous.
They
help
a
lot
with
bouncing
ideas
around.
They
provide
features,
they
provide
bug
fixes
and
they
are
very
passionate
about
being
involved
in
various
open
source
projects.
They
also
provide
all
kinds
of
fresh
ideas
and
use
cases
because
they
come
from
such
different
fields
that
it
helps
solidify
the
project's
utility
across
a
lot
of
different
types
of
uses.
B
B
Code
coverage
requirements
make
sure
they
create
issues
and
green
light
features
with
you
first
before
they
before
they
provide
a
pr
with
lots
of
code
that
you
are
not
able
to
approve
because
it
doesn't
fit
in
the
roadmap.
So
you
need
to
be
very
careful
about
making
it
clear
how
people
should
go
about
contributing,
and
one
issue
is
that
contributors
are
not
obligated
to
help
maintain
the
project
long
term.
A
lot
of
contributors
are
very
passionate,
very
great
to
have
involved
in
the
community,
but
they
are
not
financially
obligated.
B
It's
not
part
of
their
job,
to
continue
to
be
involved
in
the
project
and
if
they
contribute
a
feature
that
maybe
they
no
longer
maintain
when
they
have
a
different
job
or
their
life
circumstances
change,
then
that
can
create
a
problem
for
you,
as
the
maintainer
and
with
internal
development.
It's
structured,
it's
reliable
in
contrast
to
the
community,
which
does
not
necessarily
have
the
obligation
as
a
bunch
of
co-workers
who
work
at
the
same
company.
So
it's
always
a
little
bit
of
a
risk.
A
So
one
thing:
that's
really
important
in
open
source
project
and
and
karina
touched
on
that
earlier,
is
defining
what
your
goals
and
and
what
the
success
for
your
project
means
like.
What's
what's
the
end
goal
of
the
project
and
instead
of
just
saying
it's
just
going
to
be,
it
can
and
forever
continuing
project.
It's
really
important
to
set
up
a
goal.
So
you
can
say
you
know
we're
at
least
milestones
saying
you
know,
we've
reached
this
point
in
terms
of
maturity,
adoption
or
whatever
it
might
be.
A
It
might
be
a
goal
for
the
company
itself
using
this
as
part
of
the
tech
branding
that
we
said
earlier,
going
through
a
transformation
making
sure
that
you
build
awareness
in
the
community
and
use
that
to
attract
talent
and
then
just
build
a
better
reputation
for
your
company.
I
mean
there
might
be
a
goal
and
you
can
use
something
quantifiable
like
the
number
of
talent
you
attract,
for
example,
as
part
of
the
tech,
the
tech
brand
can
also
be
solving
a
specific
problem.
A
A
Why
you're
engaging
with
with
that
project
or
starting
a
new
new
project
can
also
be
something
if
you're
coming
more
from
the
vendor
side
and
and
using
and
looking
at
some
of
the
quantifiable
metrics
like
the
number
of
stars.
You
know
that
I
showed
that
I
showed
earlier
or
the
number
of
users
that
are
adopting
it,
adopting
it
in
production
and
using
that
as
a
means
to
to
gain
momentum
for
an
open
source
project
that
maybe
you
are
or
will
base
an
enterprise
offering
on
at
some
point,
or
it
could
also
be.
A
You
know
something
that
our
management
really
likes,
like
cost
savings
and
driving
internal
adoption
of
open
source
and
in
in
the
in
a
step
of
doing
that,
adoption
of
that
open
source
internally,
you
might
need
to
add
a
feature
here
or
there,
but
by
by
doing
that
investment
in
open
source,
you
can
take
a
project,
use
it
in
your
data
center
public
cloud
whatever
and
and
have
cost
savings.
You
know
to
justify
to
justify
that
that
investment,
but
then
again
you
have
you
have
a
goal.
You
have
something
measurable.
This
is
what
we're.
A
A
Having
quick
start
guides
easy
to
follow,
documentation
a
a
way
to
to
install
it
and
start
using
it
right
away,
and
if
you
say
you
might,
you
might
have
five
minutes
to
get
the
user
on
board
and
running
if
it
takes
longer
than
five
minutes
or
they
have
a
question,
then
it
goes
into
the
next.
The
next
bullet
here
about
user
community
support
if
they
fail
to
get
started
themselves
within
five
minutes.
A
A
A
You
can
work
with
those
other
open
source
projects
integrate
with
them
and
offer.
You
know
an
end
end-to-end
solution
by
still
using
those
building
blocks
and
that
let
the
users
seamlessly
integrate
these
open
source
projects,
and
it
also
puts
you
know,
helps
you
keep
that
rigor
of
building
it
modular
and
and
open
source,
and
all
this
together
will
help
you
get
to
those
tens
of
thousands
of
stars
or
or
user
adoption.
A
One
thing
I've
also
had
good
success
with
is
taking
advantage
of
the
open
source,
maturity
and
graduation
processes,
and
that
goes
no
matter
which
foundation
you
happen
to
to
have
your
open
source
project.
Part
of
I
mean
there
are
multiple
out
there.
Argo
that
you
know
we
have
the
most
experience
with
is
part
of
the
cloud
native
foundation.
A
They've
been
very
supportive
and
it
helped
us
a
lot
with
things
like
marketing,
where
we
as
an
end
user
and
other
individual
contributors,
might
not
have
you
know
the
marketing
muscle
to
to
market
and
brand
an
open
source
project.
You
know
vendors
are
a
little
bit
different.
They
usually
have
much
bigger
marketing
machines
that
they
can
utilize,
but
for
for
an
end
user
marketing,
something
that's
outside
of
our
core
core
business,
it's
a
little
bit
harder.
A
They
also
help
introduce
some
rigor
into
the
process
through
the
various
various
tags
and
working
groups
that
you
can
go
and
ask
for
help.
You
can
present
to
do
yearly
reviews
and
make
sure
that
your
your
releases
are
on.
Are
you
know,
following
a
release
scheme,
that
you
know
you're
doing
doing
regular
releases
and
you
have
just
regular
release
and
product
building
and
development
rigor,
which
is
really
important?
If
we
build,
you
know
a
project
that
people
will
trust.
A
These
foundations
have
also
been
around
for
a
long
time
and
they
have
some
really
good
best
practices
for
governance,
code
of
conduct
and
things
like
that
that
they
can
help
you.
They
have
skeleton
templates,
for
you
can
use
to
easily
adopt
them
and
make
sure
that
you
know
your
private
project
is
you
know,
according
to
best
practices
in
the
community
and
within
those
various
foundations,
and
make
sure
that
you
know
you
don't
run
into
an
issue
down
the
line
if
there's
a
disagreement
within
the
maintainers
and
then.
A
Lastly,
these
these
foundations
take
pride
in
the
maturity
and
graduation
processes,
so
once
you've
gone
through
the
process,
you
know
the
the
community
can
trust
that
whatever
has
gone
through.
This
process
has
been
been
vetted.
So
there
are
security
assessment
and
guidelines
and
procedures
that
they
will
help
you
with
and
go
through
to
make
sure
that
you
know
your
open
source
project
is
at
least
as
secure.
As
you
know,
proprietary
alternatives
or
options.
B
You
also
need
to
provide
lots
of
user
support,
which
means
answering
questions,
contributing
to
forums,
doing
timely
bug,
fixes
and
helping
users
on
board
to
your
technology.
Otherwise,
users
will
move
on
to
another
project
if
they
don't
feel
adequately
supported,
and
you
may
not
get
a
lot
of
engagement
at
first,
but
keep
trying
and
really
commit
and
also
leverage
related
communities
find
target
groups
in
the
same
domain
and
see
if
you
can
provide
integrations
for
those
projects,
attend
meetings
and
see.
B
If
you
can
present,
you
know,
if
you
have
common
problems,
then
you
can
work
to
resolve
them,
so
you
can
provide
utility
among
the
community
and
also
generate
some
good
feelings.
So
the
last
thing
is
that
working
in
open
source
is
very
rewarding,
even
though
it
is
tough
and
you
need
to
put
in
legwork.
It
feels
great
when
it
happens.
It's
amazing
to
meet
and
work
with
people
around
the
world,
and
it's
incredibly
satisfying
to
see
amazing
organizations
use
your
product
to
develop
new
things.
A
So,
what's
next
in
our
journey,
both
on
the
our
its
side,
as
well
as
with
the
argo
project,
so
we've
had
a
lot
of
success
with
argo.
We
have
a
lot
of
quantifiable
metrics.
In
terms
of
you
know,
the
successes
we've
had
in
terms
of
increasing
developer
productivity
cost
savings,
so
management
at
intuit
is
really
excited
about
expanding
and
increasing
the
commitment
to
open
source.
A
We're
also
looking
at
doing
more
cross
project
and
vendor
collaboration
and
integrations
here
over
the
next
year,
or
so
we
have
a
number
of
vendors
that
we're
already
working
with
within
the
community.
There
are
more
vendors
who
are
looking
at
building
solutions,
products
on
top
of
or
with
with
the
argo
project.
So
we're
really
excited
about.
You
know
having
more
alternatives
for
the
community
when
they
want
to
choose
an
a
commercial
offering
on
this
and
we're
also
looking
at
using
those
argo
building
blocks
and
integrating
them
with
more
and
other
open
source
projects.
A
So,
lastly,
we
just
want
to
say
thank
you
to
all
the
amazing
users
and
companies
are
part
of
our
community.
It's
been
awesome
to
work
with
everyone.
We've
had
a
lot
of
good
feedback
and
experiences
working
with
all
these
companies.
It's
been
a
lot
of
beer,
sweat
and
tears,
but
we've
had
a
really
good
ride
so
far,
looking
forward
to
getting
to
that
graduation
and
go
beyond
that.
So
thanks
to
everyone
from
these
companies,
if
you
are
using
argo,
thank
you
so
much
if
you're,
not
we'll
change
that
shortly.