►
Description
Regardless of experience or expertise, many developers seem intimidated or hesitant to start working on open source projects. You might be a first-time contributor to open source, or a first-time contributor to a larger project, or perhaps you are a first-time maintainer or community manager. Remote work and asynchronous communication don’t make this any easier. However, the steps you take to be a successful open source contributor is much like onboarding to a new job. Tim Lai, software engineer at SmartBear and maintainer of open source projects, SwaggerUI, SwaggerEditor, and SwaggerClient, discusses specific strategies that have proven successful to 1) alleviate developer angst, 2) produce meaningful pull requests that match your expertise, and 3) create a roadmap to becoming a frequent open source contributor.
A
A
A
A
A
A
A
So
I
can
share
a
story
about
me.
When
I
joined
smart
bear.
I
had
to
learn
about
the
various
swagger
tools
for
build
on
release
processes,
as
well
as
the
open
api
specification.
I
was
also
joining
an
entirely
distributed
team,
although
that
was
something
I
was
very
comfortable
with
and
used
to
working
with.
A
A
A
A
But
there's
a
lot
more
than
what
I
consider
core
features.
For
example,
we
have
expanded
tool
sets
because
once
we
have
an
application,
we
need
to
be
able
to
bundle,
build
and
distribute
the
application,
and
ideally
we
also
have
continuous
integration
and
deployment
as
part
of
the
rule
release
workflow.
A
So
I
have
to
be
a
react
expert
or
I
have
to
be
an
express
expert
or
I
have
to
be
an
expert
with
open
api,
and
the
fact
of
the
matter
is
that
it
really
depends
on
the
project
and
the
project
needs
of
how
quote
unquote
expert.
You
really
need
to
be
in
this
case
of
swagger
ui,
depending
on
what
you're
working
on
it
might
be
very
valuable
to
be
an
open
api.
A
So
with
community
management,
if
you
have
custom
something
like
customization
features
in
your
application,
you
know,
and
if
you
have
documentation
for
it,
it
might
not
be
quickly
found
by
some
users,
so
people
might
be
asking
and
creating
tickets
asking.
How
do
I
do
xyz
things
to
which
you
can
contribute
by
saying,
hey?
You
can
go
to
this
particular
area
of
the
application
to
do
whatever
you're
trying
to
do
so.
You,
as
a
power
user,
can
share
your
knowledge
and
help
with
the
community.
A
A
A
So,
to
recap
about
impactful
contributions:
there
are
a
lot
of
different
areas
to
contribute
and
it
really
depends
on
the
project
and,
if
you
think
about
it
from
a
software
engineering
perspective,
this
slide
pretty
much
covers
anything
that
might
be
needed
now.
There's
always
more
always
some
specific
expertise
needed
to
make
something
better
and
more
efficient.
But
that's
where
you
come
in,
because
you
have
a
lot
of
expertise
to.
A
A
A
Now
this
pull
request
also
needs
to
be
effective
right,
so
things
that
go
into
an
effective
pull
request
include.
Follow
the
project
style
guide
include
the
supporting
tests
that
you
are
adding
as
a
feature
or
fixing
providing
documentation
to
recreate
its
effectiveness
and
then
ideally
include
before
after
screen
shots.
A
A
So
an
example
of
this
is
that
you
might
make
a
change
to
render
some
data
more
accurately,
and
you
provide
a
test
to
demonstrate
that
the
code
change
works,
but
during
testing
a
reviewer
might
discover
a
related
problem
that
may
or
may
not
have
been
caused
by
a
code
change
regardless.
The
project
itself
might
be
missing,
related
functional
tests
that
you
are
not
aware
of.
A
A
The
last
topic
about
pull
requests
is
around
awareness
of
impact
to
upstream
and
downstream
projects.
Now
I
think
it
is
unrealistic
that
you
should
be
expected
to
know
every
combination
or
permutation
of
how
everyone
else
might
be
implementing
the
application,
but
I
think
a
good
analogy
here
would
be
working
with
teams
in
your
job.
A
A
A
A
Some
tasks
are
also
can
be
related
to
each
other
and
some
have
dependencies
on
others
right.
So,
if
you
start
with
plumbing,
you
might
not
be
able
to
complete
the
plenty
of
work,
because
maybe
you
put
in
the
pipes
first
and
you
have
to
wait
for
your
cabinet
guy
person
to
build
your
sinks
before
you
install
like
the
faucets
right.
A
So
when
you
jump
into
open
source
project,
it's
very
similar.
You
want
to
accomplish
something
like
building
a
house.
It
could
be
adding
a
new
feature
to
your
favorite
application,
or
it
could
be
fixing
a
set
of
problems
that
causes
your
users
issues,
or
it
could
be
just
some
technology
that
you're
really
interested
in
learning
more
about
start
with
a
small
brick,
a
story,
a
single
story
and,
as
you
complete
more
and
more
stories,
you'll
find
that
you're
making
progress
on
epics.
A
So,
just
like
there's
different
types
and
sizes
of
houses,
there
are
different
approaches
to
jumping
into
a
project.
In
the
case
of
swagger
ui.
I
can
share
a
couple
of
stories.
The
first
one
is
my
story
about
onboarding
with
smart
bear,
so
I
was
less
focused
on
learning
about
the
open
api
specification
right
away.
A
A
A
A
A
A
Alternatively,
or
in
addition
to
the
another
hypothetical
example
would
be,
it
might
lead
to
a
job
opportunity,
either
with
the
project
owners
or
by
another
contributor
who
has
noticed
my
work
and
could
use
my
subject
matter,
expertise
in
any
case,
the
good
thing
is
that
there
isn't
any
expectation
that
I
need
to
stay
and
maintain
my
work
forever
right,
because
I've
already
done
a
good
job,
making
effective
contributions
right.
I
made
it
concise,
clear,
provided
tests
for
other
people
to
build
on,
and
I
can
still
work
on
other
features
or
projects
that
interest
me.
A
A
A
So
some
clothing,
some
closing
thoughts
in
open
source.
Everything
is
transparent
for
the
world
to
see
so
be
kind
and
be
great
to
work
with,
because
it's
a
community
that
makes
it
open
source
great,
so
the
better
we
collaborate,
the
better
the
tool
application
product
it
becomes
and
then
from
a
direction
or
growth
perspective.
It's
helpful
to
understand
what
is
important
so
that
you
have
a
goal
that
you
can
work
towards
and
maximize
your
impact
to
the
project
or
the
team,
and
finally,
technology
moves
fast.