►
From YouTube: Innersource: open source collaboration patterns beyond public FOSS projects - GitHub Satellite 2019
Description
Presented by Isabel Drost-Fromm, Open Source Strategist, Europace AG
Europace AG, a Berlin-based FinTech company, has been piloting innersource efforts for over two years. During that time, they've followed and contributed to innersourcecommons.org, a global, cross-organization initiative to further innersource practices that “apply the lessons of open source to all software engineering, using collaboration and transparency to increase quality, speed, and developer joy”.
This session will take your team on a journey from innersource as a vague idea to an organization that embraces open source collaboration techniques with developers who contribute to open source projects themselves.
About GitHub Satellite 2019
A community connected by code
Explore our interconnected community—and how collaboration turns ideas into innovations.
Join us in November at San Francisco's Palace of Fine Arts for GitHub Universe - https://githubuniverse.com/
A
A
What
I'm
going
to
tell
you
today
is
our
story
of
the
past
two
years.
The
lessons
that
we've
learned
and
the
principles
that
we've
discovered
so
I
happen
to
be
open,
so
strategist
at
our
pacer
game,
but
I
am
also
a
member
of
SIA
patches
of
her
foundation
a
couple
years
ago.
Actually,
ten
years
ago,
I
wanted
to
have
a
few
friends
travel
to
Berlin.
For
my
birthday,
I
wanted
to
have
their
employers
pay
for
the
trip.
How
do
you
do
that?
A
You
create
a
conference
on
also
in
search,
scalability,
no
sequel
and
analytics,
which
was
Berlin
buzzwords
I
did
that
together
we
see
online
out
who
is
here
today
and
Simon.
Will
narrow
next
edition
will
be
mid-june
here
in
Berlin
I
also
created
a
conference
called
Faust
backstage,
which
essentially
brings
together
people
from
the
Linux
Foundation
Apache
Software
Foundation,
Eclipse
Foundation,
as
well
as
individuals
to
discuss
all
things.
Open-Source
economics
open
source
legal
and
opens
us
governance.
A
So
I've
been
mentioning
our
company
and
we
can
name
a
couple
times.
We
are
active
in
the
financial
space
connecting
banks
with
distributors,
essentially
building
a
platform
where
you
can
go
to
a
shop
and
tell
them
that
you
want
a
mortgage
and
they
will
use
our
platform
in
order
to
compute
the
best
offer
for
you
now.
This
sounds
like
a
FinTech,
except
that
we
are
at
20
years
old
and
well-established
and
profitable.
It
sounds
extremely
boring
and
hierarchical,
except
that
we
are
very
h.
A
L
and
c
goal
in
our
management
structure
is
to
move
decision-making
towards
where
they
acknowledge
actually
is,
and
this
is
where
inner
source
really
comes
into
play.
Your
pace
itself
is
a
170
people.
Company
belongs
to
a
larger,
holding
called
hippo
port,
which
it
has
like
one
and
a
half
thousand
employees.
A
So
now
that
you
know
where
I'm
coming
from
what
I
would
like
to
learn
is:
what's
your
company
size?
How
many
people
here
in
the
room
are
working
for?
A
company
was
like
ten
people,
startup
ish,
okay,
maybe
like
10
percent?
What
about
hundred
to
three?
What
about
cooperations
Wilson
service
into
ten
thousand
people?
A
A
70%,
maybe
what
about
UX
1
2
3
not
set
money?
How
many
product
are
with
owners?
Do
we
have
in
the
room
none
one?
Many
operations,
people,
1,
2,
3,
4,
5,
6?
Ok,
how
many
of
you
knows
a
feeling
of
wait
a
minute?
This
looks
broken
in
our
deployment,
but
Jim's
no
longer
here
we
have
no
clue
how
to
fix
it.
Does
that
sound
familiar
to
anyone?
A
A
So
the
reason
why
you
want
to
look
into
inner
sisters
is,
if
you
come
from
background,
you
probably
have
heard
about
putting
more
emphasis
on
non-formal
negotiations.
If
you
have
a
little
team,
that's
taking
this
to
the
extreme.
You
may
have
ended
up
with
a
team
that
doesn't
do
any
documentation
as
well
and
also,
as
here
comes
two
balances
and
recurrent
roses,
and
we
will
see
later
how
that
works.
You
may
also
want
to
look
into
innocence
if
you
want
to
turn
customers
into
part
of
your
own
team,
helping
you
contributing
back.
A
I've
asked
you
before
whether
you
have
remote
people
in
your
companies,
because
in
Ursus
helps
you
with
flexibility
and
was
becoming
more
remotely
remote
friendly.
Of
course,
it
also
helps
to
give
more
autonomy
autonomy
to
navigate
to
those
working
down
in
the
trenches,
so
at
Europeans
residing
was
a
few
teams
setting
up
a
tribe,
that's
centered
around
the
topic
of
in
Ursus.
A
After
a
couple
after
some
time,
what
became
clear
was
that
there
are
some
common
principles
that
would
help
us
establish
in
Ursus
in
our
company,
one
of
the
scum
one
of
those
principles
was
being
open,
transparent
and
findable.
Essentially
that
means
that
you
have
to
put
all
your
code
in
a
place
where
everyone
in
your
company
can
at
least
read
it,
and
not
only
your
code,
but
also
documentation,
etc.
A
Moles
that
translates
to
put
everything
on
github
or
github
Enterprise
and
you're
done
right,
except
that's
not
quite
how
it
works.
What
have
you
seen
happen
is
you've
got
team,
a
which
has
a
component
or
micro
service.
You've
got
team
P
which
wants
to
reuse
this
micro
service,
but
kimby
thinks
it's
not
quite
there.
Yet
they
need
another
feature.
So
what
they
do
is
to
implement
that
feature
say,
send
a
pull
request:
progress
doesn't
get
it
get
any
attention.
A
This
kind
of
fertile
starts
bid
to
be
to
bubble
up
towards
management,
which
then
chat
to
each
other.
Create
creating
more
friction,
lesson
learned.
Oh
my
gosh
I
know
so
it's
doesn't
work.
So
what
didn't?
What
what?
What
went
wrong
here?
One
things
that
went
wrong,
maybe
is
the
progress,
requests,
didn't
get
the
attention
because
it's
on
the
receiving
end
of
the
of
the
requests.
There
was
no
priority
on
that
particular
feature.
There
was
no
communication
before
that.
A
Whether
this
feature
was
wanted
or
whether
it's
some
things
that
fits
with
the
architecture
so
something's,
that's
still
true
and
that's
even
true
an
open
source,
static
conversation
or
a
start.
Whether
there
was
a
ticket,
I've
made
a
little
experiment,
just
anecdotal
evidence
not
stick
statistically
relevant,
but
for
the
largest
open
source
projects
it
I
checked
roughly
50%
of
the
sobbing
rejected.
A
A
A
A
There
we
are
at
sea
advice,
well
you've
written
over
verbal
advice.
The
goal
here
is
to
be
able
to
collaborate
as
asynchronous
when
synchronous
communicate.
Communication
gets
hard
even
for
those
in
the
audience
that
don't
have
any
remote
people
as
soon
as
you
have
team
members
who
work
on
slightly
different
schedules.
As
soon
a
few
s
meetings
come
into
play,
it
starts
suddenly
getting
more
and
more
tricky
to
find
time
for
pairing
sessions.
A
A
A
However,
all
of
the
decision
making
process
should
still
happen
in
a
written
form
such
as
the
team
members
who
are
not,
as
in
part
of
that
meeting,
can
participate
at
Apache.
Our
rule
is
that
every
decision
has
to
happen
on
the
mailing
list
and
every
decision
has
to
like
every
important
decision
has
to
be
open
for
72
hours.
Do
we
have
the
same
rule
in
our
company?
Clearly
not
we
are
pretty
much
co-located,
but
at
least
in
the
same
time
zone
so
depending
on
Europe
setting.
You
will
have
to
figure
that
out
so
the
gist.
A
A
What
happens
if
you
do,
that
is
that
you
create
a
project
memory,
essentially
a
kind
of
passive
documentation.
What
I
mean
mister
passive
documentation
is
not
a
pile
of
documents.
What
I
mean
is
something
that
is
an
archive
set
is
searchable,
so
it
has
stable
URLs
over
time
so
that
you
can
go
there,
drill
down
to
your
conversation,
link
it
and
send
it
to
someone
else,
and
that
link
is
still
valid.
Ten
years
from
now.
A
A
Why
do
you
want
that?
Clearly,
you
want
to
remember
what
you
did.
You
want
to
remember
why
you
did
something
even
years
from
now,
so
some
things
that
we
have
observed
is
something
was
implemented.
You
see
it's
implemented
now,
but
you
start
wondering:
is
that
a
feature
or
can
I
delete?
It
is
that
customers
still
around
is
that
use
case
still
around,
and
you
only
know
that
if
you've
trekked,
why
you've
implemented
something?
A
Now,
if
you
move
towards
a
setting
where
more
things
are
being
written
down
and
archived
forever,
what
do
you
need
to
establish
is
a
culture
where
mistakes
are
okay,
what
I
mean
was
a
culture
where
mistakes
are
okay.
Do
you
remember
how
back
at
school
you
were
sitting
in
the
classroom.
Writing
a
test
teacher
standing
right
at
your
back
step.
A
That
doesn't
sound
very
comfortable.
Does
it,
but
that's
exactly
what
it
feels
like
in
the
beginning,
if
you
roll
out-
and
you
want
to
share
work
in
progress,
github
has
this
nice
feature
of
marking
pull
requests
as
still
being
in
progress?
Something's,
that's
not
supposed
to
be
merged
back!
That's
a
nice
way
in
order
to
show
to
share
early
progress
to
get
early
feedback
from
your
collaborators
and
to
avoid
running
into
the
wrong
direction.
A
However,
you
need
to
be
comfortable
and
you
need
to
have
colleagues
who
appreciate
that
what
you
will
have
to
figure
out
as
well
as
how
much
configuration
you
want
to
do,
is
to
avoid
things
going
wrong
over
how
much
convention
you
want
to
have
at
a
patchy.
We
had
a
talk
on
good
community
practices.
One
of
them
was
to
have
little
configuration
and
more
social
strings
attached.
A
So
three
community
convention
people
know
when
to
merge
for
requests.
People
know
how
to
do
things.
If
you
have
teams
that
are
not
experienced,
this
kind
of
work
you
likely
want
to
at
first
at
least
opt
for
more
configuration
like
lockdown
fortress
being
locked
down
per
request
from
being
merged
if
they
haven't
received
a
review
already,
for
instance,
something
else
for
making
it
okay
to
make
mistakes
is
to
automate
feedback,
something
like
style
violations.
Testing
violation
sets
all
some
things
that
a
bot
can
tell
you
without
overloading
maintainer
x'.
To
do
all
of
these
reviews.
A
With
that,
then
you
can
move
to
your
model
value
value
contributions
over
feature
requests
taken
to
the
extremes.
This
means
integrating
your
customers
into
your
development
projects,
set
something
that
we've
done
at
our
pace
where
our
platform
is
being
developed
as
an
over
pace
but
used
by
other
subsidiaries
of
you
purport,
and
some
of
these
subsidiaries
decided
to
help
us
will
see
implementation
and
see
refinement
of
the
platform
so
essentially
taking
see,
pulls
the
customer
in
early
one
step
further.
A
As
soon
as
you
receive
contributions,
you
wanna
reward
them,
typically
with
praise
as
publicly
and
as
early
as
often
one
pattern
that
we
have
even
in
the
inner
source.
Commons
is
to
praise
participants
and
to
give
qualified
thank-yous.
What
do
you
mean
basic
qualify.
Thank
you
I,
don't
say
thanks
things.
I
say
thank
you
for
X,
because
it
helped
me
do
why
this
helps
this
makes
it
more
credible.
It
also
helps
the
contributor
understand
which
kinds
of
contributions
of
our
common
needed.
However,
you
also
can
say
thank
you
with
influence.
A
You
can
pull
your
contributors
in
as
new
trusted
commuters.
What
the
heck
is
extra
commuter.
The
goal
of
committee
trusted
committee
is
someone
who
mentors
enables
and
invites
new
contributors.
It's
someone
who
is
responsible
and
accountable
so
setting
the
house
rules.
Remember
the
contributions
m-day
from
earlier,
so
you're,
someone
who
can
help,
who
hid
themselves
communicates
openly
and
transparently.
A
What's
important
about
this
role
is
sets,
this
role
is
filled,
wollen
Terry,
so
it's
the
way
it
works
in
our
case
is
the
invitation
is
sent
privately
to
the
prison
in
question.
They
respond
privately
was
as
they
okay
being
a
trusted
committer,
and
only
then
it's
announced
publicly
and
widely
that
they
are
welcomed
as
a
new
trusted
committer.
A
So
how
do
you
start
your
innocence
initiative
seriously?
A
project
out
there
called
enosis
commenced
our
arc.
We've
got
one
friend
over
here,
I,
maybe
you're
gonna
stand.
Thank
you,
I,
don't
know.
If
there's
anyone
else
in
the
audience
and
Walsall
sinners.
Those
comments
not
yet
okay.
I
know
that
then
at
least
the
niece
is
somewhere
here
at
the
github
satellite.
So
what
this
is
is
essentially
a
group
of
people
rolling
out
in
a
search
within
their
organizations
what
they
did
was
to
collect
patterns.
A
Collaboration
patterns
that
you
can
use
in
your
organization
located
as
Volvo's
to
videotape
a
Learning
Path,
so
that
your
organization
can
better
understand
how
to
roll
out
inner
source
and
what
it
actually
means
what
they
have,
as
well
as
a
couple
of
books
on
what
a
gnosis
is
on
success
stories
of
different
companies,
but,
most
importantly,
it's
a
community
that
is
open
for
you
to
join
services,
like
teams
that
you
can
join
right
now,
the
select
team
runs
and
Jeri
Chatham
House
Rules.
What
does
that
mean?
A
You
can
take
all
of
the
wisdom
and
almost
as
lessons
learned
from
the
innocence
comments
and
shares
emotes,
everyone
else
provided
you're
dropping
the
names
of
the
people
who
share
those
stories
with
you.
Why
are
you
supposed
to
drop
some
names?
Well,
if
company
acts
as
sharing
that
something
went
wrong,
say
likely,
don't
want
to
have
say
a
trademark
associated
verses
failure
story,
but
as
I
still
can
learn
from
it.
A
So
how
do
you
get
started
so
why
we
start
gets
got
started
at
your
pace
was
with
experiments?
What
do
you
mean
with
experiments?
Those
are
real
projects,
but
they
are
small
said
you
have
a
business
impact,
but
they
are
small
enough
to
not
pull
the
entire
company
down
with
tricks.
A
lesson
learned
from
these
experiments
collected
summon
retrospectives
and
shared
those
lessons
learned
with
the
entire
company.
Well,
actually,
we
shared
them
with
the
entire
world
by
putting
them
on
our
tech
block,
so
you
yourself
can
read
them
as
well.
A
A
A
Three
is
that,
with
written
communication,
you
will
end
up
at
a
project
manner
memory,
essentially
a
passive
form
of
documentation
again
this
kind
of
documentation.
This
is
not
like
your
entire
specification
of
your
software
stack.
It's
nothing
formal
and
it's
definitely
not
the
end
of
the
documentation
story.
It's
your
baseline.
A
What
happens
at
Apache,
for
instance,
is
that
a
lot
of
cells
commit
conversations
tend
to
be
linked
down
to
from
the
formal
documentation.
So
you
don't
have
to
rewrite
it.
Yours
already
have
it,
but
if
you
imagine
going
back
20
years
in
history
of
like
300
projects
discussing
on
a
daily
basis,
finding
that
one
important
communication
chains
gonna
be
like
searching
for
a
needle
in
the
haystack,
so
you
want
something
more
formal
on
top.
A
What
you
need
is
a
culture
where
mistakes
are
okay,
and
very
you
will
end
up
with,
is
a
cultural,
rare
contributions
of
being
valued
over
future
risks
such
as
people
offering
to
help
enabling
people
to
help
themselves
and
those
people
helping
themselves.
You
will
end
up
in
a
environment
where
contributions
are
provided
by
praise
and
by
influence,
and
was
that
I'm
happy
to
take
questions.
A
B
A
One
one
point
that's
important
here:
retina
verbal
doesn't
implies
that
you
have
to
open
an
issue.
It
could
be
as
simple
as
talk
to
the
public
slack
channel
so
that
everyone
else
sees
it
as
well.
This
is
one
way
of
lowering
the
barrier.
There
are
the
things
that
we
observed.
It
says
that
as
soon
as
teams
are
even
distributed
across
two
levels,
in
the
same
building,
there's
a
communication
barrier
between
these
teams.
It
could
pretty
much
as
well
could
be
removed,
so
it
sometimes
it
even
then
it's
easier
to
write
on
slack.
A
If
you
go
beyond
a
certain
team
size
or
if
you
go
beyond
a
certain
company
size,
it
starts
getting
hard
finding
people
around
the
corner
and
talking
to
them
directly
because
they
may
be
in
the
meeting.
Save
may
be
sick
or
on
vacation.
So
at
some
point
it's
easier
to
do
it
in
a
written
way.
The
other
thing
is
that,
through
this
community
tribes
that
we
created
we're
living
by
example,
we
were
living
the
change
that
we
wanted
to
see.
So
people
saw
the
advantage
of
it.
A
Monix
was
very
simple
example:
we've
got
these
monthly
meetings
after
each
meeting.
It
I
sit
down
and
write
tiny
meeting
minutes.
Not
so
tiny
may
I
take
this
meeting
minutes,
I,
post,
seven
slacking
on
and
on
github.
After
doing
this,
for
a
couple
of
times,
this
became
like
a
role
model
way
of
running
meetings
which,
as
a
team's
aspire
to
because
what's
a
realizes,
you
can
participate
in
that
meeting
without
actually
being
zarin's
like
one
hour
there,
but
you
can
skim,
read
it
and
you
can
drill
it
down.
If
there's
something
interesting
to
you.
Okay,.
B
A
Of
course,
the
other
thing
is
you
need
to
understand
why
you
want
to
do.
Is
that
so
you
explain
to
people
why
you
want
to
value
written
over
verbal.
In
our
case,
what
helped
it
was
to
do
like
workshops
where
we
looked
at
the
reasons
why
we
want
to
look
into
users
and
one
of
the
pain
points
that
the
team
said
was
safe,
been
developing
software
for
years,
and
they
didn't
remember
why
certain
changes
were
made
and
that's
where
they
themselves
understood.
Okay,
some
things
have
to
be
written
down
for
us
to
remember
them.
C
Hi,
thank
you
for
the
song.
What
do
you
find
is
the
20%
of
the
work
that
does
the
most
effect
to
put
it
in
context,
I
work
in
enterprise
and
everything
is
heavily
load
siloed,
so
all
of
this
would
be
will
be
great
to
implement,
but
it's
almost
impossible.
Well,
what
is
the
best
way
to
get
the
advantages?
Let's
start
to
get
the
advantages
from.
A
What
I've
seen
in
our
company
and
from
what
I've
heard
about
success
stories
and
other
companies?
What
you
really
want
to
do
is
to
try
to
find
one
team
that
buys
into
this
try
to
run
an
experiment
that
shows
that
this
is
valuable
and
from
their
scale
out,
don't
try
to
convert
all
of
your
company
at
once,
but
like
try
to
find
one
trial
company
like
one
trial
team.
Sorry
for
that
team,
try
to
identify
what
their
pain
points
were.
A
What
we
did
at
our
case
was
not
roll
all
of
that
out
at
once
and
Hadassah
like
from
one
day
to
the
other,
but
it
was
a
continuous
process.
So
we
were
talking
to
the
teams.
We
were
listening
to
their
challenges
and
for
each
of
these,
those
challenges
that
they
came
up
to
me.
I
was
like
hey,
wait,
a
minute,
there's
a
solution
over
there.
It's
called
you
have
to
communicate
more
openly
or
you
have
to
value
written
advice
more
or
just
recently.
We
had
the
issue
of
wait.
A
A
minute
I
want
to
drill
down
into
github
notifications
after
the
fact
like
I
have
joined
today,
but
I
wanna
see
the
notification
from
yesterday.
Well,
there's
an
easy
fix,
direct
all
of
those
to
a
channel
where
everyone
can
access.
My
done
so
try
to
take
one
team,
try
to
fix
their
challenges
and
then
talk
about
how
good
that
is
to
the
rest
of
the
company.
Okay,.
A
Any
further
questions
last
chance,
3
2
1,
well
that
I
would
like
to
say
thank
you.
First
of
all
to
all
of
you
listening
second
of
all,
T
innocence,
Commons
for
providing
hints
and
being
helpful,
also
choose,
in
my
personal
case,
to
the
Apache
Software
Foundation,
which
is
the
basis
of
a
lot
of
these
lessons
learned,
but
also
like
to
the
guys
representing
the
company.
Can
you
just
stand
up
turn
around
you?
New
set
vs.
was
coming.