►
Description
Saul and Emil discuss the lessons learned in the past 20 years they've spent working on open source real-time communication
A
Well,
hello,
everyone
saul
here
from
the
gt
project.
Today
we
have
a
special
one
for
you,
it's
jitsi's
20-year
anniversary,
and
today
I
have
with
me
emily
buff.
The
original
founder
of
the
project
welcome
emil.
A
I
surely
hope
so
today
we
have
we'd
like
to
share
three
stories
with
you:
three
things
we've
learned
and
how
they
have
accompanied
us
along
this
journey.
We're
going
to
talk
about
our
relationship
with
open
source,
our
relationship
with
open
standards
and
our
relationship
with
money
amongst
across
all
the
of
the
lifetime
of
jitsi
and.
B
Yeah
and
and
and
I'm
sorry
to
jump
in,
I
I
think
the
reason
why
we
want
to
do
that
is
because
you
know
our
we
live
short
lives
like
we
don't
have
time
to
learn
everything
by
ourselves
and
we
think
we
have
learned
some
things
during
these
past
20
years,
as
we
were
working
on
jitsi
and
we'd
love
to
share
that
you
know.
Hopefully,
people
would
find
that
useful
in
their
own
journeys
and
they
would
have
an
easier
time
of
it.
That
way.
A
Indeed,
so,
first,
just
let's
try
to
rewind
time
and
think
in
wide
world
gtc
was
sort
of
came
into
existence
was
2002
2003
we
didn't
really
have.
We
had
no
youtube,
no
facebook,
no
gmail.
A
You
know
the
standard
resolution
was
1024x768,
so
no
hd
sort
of
fancy
things
for
many
people
and
it
was
a
world
where
the
instant
messaging
choices
were
pretty
pretty
limited.
You
got
like
msn,
I'm,
I
think,
and
I'm
not
sure
exactly.
Skype
was
around
the
corner
or
already
there,
and
there
was
definitely
a
lot
happening
in
the
open
source.
Open
standards
world
as
well.
Irc
was
their
jabber
at
the
time
later
xmpp,
and
this
was
how
the
universe
was
at
that
time
and
at
that
point
a
young
mill
working
on
his
phd
story.
B
Yeah,
so
you
know.
B
I
think
the
primary
reason
it
happened
was
a
passion
and
interest
and
and
the
desire
to
just
go
and
walk
a
journey
that
has
to
probably
precede
everything.
I
I
I
think
you
you've
had
that
yearning
yourself.
You
were
the
author
of
an
open
source
project
yourself.
You
just
felt
like
I
don't
see
of
all
the
paths
available
to
me.
I
don't
see
one
that
actually
fits.
What
I
want
to
do,
I
just
want
to
go.
You
know,
trace
my
own
route
and
see
where
it
takes
us.
B
B
One
thing
that
we
should
also
mention
is
that
computing
power
was
very
far
away
from
where
it
is
today
and
it
was
specifically
quite
insufficient
for
the
way
in
order
to
handle
any.
You
know
the
the
amount
of
video
volume
that
we
need
in
order
to
have
a
decent
conversation.
B
It
was
you
know,
just
generic
cpus
were
not
capable
of
doing
that
they
weren't
even
capable
of
properly
doing
audio.
It
was
the
same
even
in
earlier
times,
with
the
same
with
the
actual
internet
network,
international
circuitry
that
was
available
for
us
to
transport
audio,
although
by
the
2000s,
the
internet
was
about
good
enough
to
do
decent
audio.
B
So
so,
let's
look
at
the
situation
where
we
found
ourselves
one
one
of
the
things
that
we
both
shared
is
that
we
were
very
early
attracted
to
open
standards,
and
it's
interesting.
You
know
why.
Why
would
we
land
there?
Why
is
this?
Why
would
this
appear
as
the
obvious
starting
position
for
both
of
us?
B
I
believe
the
answer
has
to
do
with
that
limited
cpu,
and
what
what
it
meant
was
that
you
know
a
lot
of
the
real-time
communications
issues
had
to
be
solved
by
dedicated
product
specifically
audio
and
video
processing
had
to
be
done
in
dedicated
circuitry.
You
had
to
build
cards
that
were
able
to
process
audio
and
video,
which.
B
B
The
internet
wasn't
powerful
enough
for
the
video
routing
technologies
that
we
have
and
they
could
then
therefore
only
do
video
service
that
was
that
was
they
had
to
focus.
B
There
was
so
much
work
to
do
there
and
there's
a
limit
to
how
much
work
we
can
take
on
ourselves
that
you,
you
know
you
gotta,
you
gotta
make
choices
at
a
certain
point,
so
you
end
up
with
these
dedicated
phone
builders
and
dedicated
server
builders
and
then,
finally,
there
wasn't
a
lot
of
pre-existing
work
on
the
topic
that
just
you
couldn't
really
stand
on
the
shoulder
of
diet
of
giants,
because
these
giants
hadn't
lived
yet.
So
you
couldn't
incorporate
a
bunch
of
libraries
in
into
what
you
were
building.
B
They
didn't
exist
so
again
we're
in
this
situation,
where
everyone
had
to
focus
on
their
one
thing.
If
this
was
going
to
work,
we
had
to
pick
our
roles
well,
and
so,
if
that
is
going
to
be
the
case,
though,
then
we
have
to
make
sure
that
we
all
agree
on
how
we're
going
to
talk
to
each
other,
and
this
is
why
I
believe
in
real-time
communication
20
years
ago,
standards
were
paramount,
because
that
was
the
only
way
the
thing
could
work
now
some
companies
might
have
been
able
to
get
away.
B
Without
that
you
know
companies,
I'm
talking
like
the
really
big
players
of
the
time
there
was
cisco
back.
Then
there
was
avaya
and
a
few
others,
and
you
know
they
they
had
full
solutions.
It's
you
know
it
wasn't
sufficient
because
some
of
their
customers,
you
know
they
wanted
to
facilitate
acquisition
of
new
customers,
which
meant
that
if
they
had
someone
working
with
partial
avaya
stuff,
they
they
could
come
in
and
sell
them
cisco
for
the
other
part
of
their
network
and
start
there
and
hope
to
win
them
over
completely
with
time.
B
So,
even
for
the
big
players,
standardization
was
kind
of
important,
but
for
the
small
players
it
was
a
matter
of
life
and
death.
It
was
a
matter
of
survival,
so
for
people
like
us,
adopting
open
standards
was
really
the
only
way
to
be,
and
if
there
were
no
open
standards,
that
meant
we
couldn't
be
in
there
in
that
space.
I
think
this
is
one
of
the
interesting
this
led
to
one
of
the
interesting
connotations
of
open
standards.
Back
then,
open
standards
became
synonymous
with
this.
B
They
they,
it
kind
of
they
kind
of
acquired
this
moral
ring
to
them.
Open
standards
meant
good
proprietary
protocols
started,
meaning
evil
kind
of
which,
which
I
think
is,
is
interesting.
I
don't
believe
that
that's
the
situation
that
we're
in
today.
What
do
you
think
about.
A
Definitely
not,
but,
but
I
think
I
think,
you're
right
in
in
the
past
so
at
the
time,
for
example,
what
we,
what
is
kind
of
the
the
lingua
francais
voib
today,
which
is
sip
this
the
second
version
actually
was,
was
been
written.
I
believe
it's
from
2002
or
just
one.
So
at
that
point
it
was
all
kind
of
in
the
air
and
cisco
had
skinny
or
http
protocol
and
whatnot,
and
it
ended
up.
You
know
they
end
up,
abandoning
it
and
going
for
the
open
standards.
But
I
remember.
A
I
remember
way
back
when
it
was
you
either
use
the
standard
thing
or
there
was
this
other
thing,
but
then
you
could
only
use
these
devices
and
then
the
others
you
had
to
like
scrap
them
or
something
so
there
was
indeed
some
some
cost,
also
associated
with
it.
Like
from
my
personal
perspective,
I
think
I
landed
there
kind
of
by
accident.
A
I
just
didn't
know
any
better.
I
think
I
like
what
are
the
rules
and
then
it's
like.
Oh
this
book
is
the
rules
all
right.
Then,
let's
see
where
it
takes
us
and.
B
It
was
the
only
way
you
could
play
you
could
play
the
game
yeah
and
then
the
other
situa,
the
other.
The
the
other
place
where
we
kind
of
made
ended
up
the
same
in
the
same
location
was.
That
was
what
was
our
relationship
to
open
source.
Now
I
I'm
the
the
situation
there
is
is
a
little
bit
different
you
could.
It
was
possible
for
you
to
write
proprietary
right,
but
then
it's
not
like
the
cpus.
Don't
support
that
like
it
was
the
case
with
video.
B
You
could
write
things
yourselves,
but
then
it
meant
going
down.
You
know
a
path
that
is
much
more
lonely
it
it.
It
meant
that!
Well,
if
it's
going
to
be
proprietary,
what
am
I
going
to
do
with
it?
How
am
I
going
to
find
users
to
it?
I'll
probably
have
to
sell
it.
If
I'm
going
to
have
to
sell
it,
then
it
has
to
hold
a
certain.
B
You
know
satisfy
a
certain
number
of
constraints,
which
really
means
I
need
money
and
a
team
which
means
that
I'm
probably
going
to
have
to
go
and
build
a
company.
There
were
a
lot
of
steps
because
the
way
that
you
used
to
make
money
back
then
and
do
proprietary
things
was
you
sell
copies
of
the
of
your
software
and
and
the
code
that
you
give
out
essentially
is
is
the
product
open
source?
B
I
think
what
we
what
we
both
got,
attracted
by
you,
you
tell
us
for
for
yourself,
but
personally,
what
attracted
me
was
the
low
barrier
of
entry?
You
you
just
go
in
and
you
start
and
then,
if
someone
wants
to
work
with
you,
they
just
come
in
and
start
they
just
send
you
the
code.
There
was
like
the
maximum
amount
of
friction
removed
from
collaboration,
so
that
was
amazing.
B
Now
I
don't
know
entirely
why
but
open
source
2
had
a
very
moral
ring
to
it
and-
and
it
was
similar
if
you're
doing
open
source
for
many
people,
you're
being
good.
If
you're
not
doing
open
source,
you
are
sinning.
Somehow
you
know,
and
there
were
different
levels
of
sin.
You
know
people
would
tell
you
that
it's
okay
to
use
an
occasional
proprietary
program,
that's
fine
as
long
as
you're,
creating
something
in
open
source
and
then
certain
people
will
tell
you
no
everything
has
to
be
open
source.
B
It's
starting
from
you
know
not
only
the
stuff
that
you
write,
but
also
the
the
the
apps
that
you
use
in
the
operating
system
that
you
use.
So
we
we
had
this
entire.
B
You
know
apparently,
of
of
of
adoption
of
the
concept,
but
the
concept
was
there
open
source,
good
closed
source,
evil
just
to
more
or
less.
A
Does
it
does
resonate
a
lot,
even
though
I
I
started
from
a
different
angle,
like
I
think
so?
Of
course,
waypoint
went
a
lot
younger
and
I
kind
of
like
to
be
a
bit
of
a
contrarian,
I
think,
and
the
norm
back
then
like
unlike
right.
Now,
where
you,
you
would
kind
of,
have
to
justify
yourself
for
doing
something
proprietary.
It
seems
these
days.
Everything
is
open
source
but
way
back
when
it
wasn't
so
doing
open
source
was
the
contrarian
part.
Let's
say
so.
A
I
I
like
that
that
attitude,
that
kind
of
like
was
the
rebels
that
worked
in
open
source
and
the
you
know
the
more
bigger
established
evil
players
were
were
doing.
The
regular
of
sort,
software
development.
B
That
is,
that
is
true
and
there's
something,
and
you
know
something
inherent
to
youth,
that
you
know
the
attitude
comes
with
youth,
you're
kind
of
given
this
world
that
is
already
pre-established,
and
it
has
a
bunch
of
rules
in
it,
as,
as
you
alluded
to,
and
some
rules
you
can
choose
to
follow,
because
they
make
sense
to
you
and-
and
some
rules
just
appear
like
this
huge
hindrance
that
you
don't
want
to
go
through
and
open
source
was.
There
was
a
lot
of
that
for
me
as
well.
B
I
remember
when
I
was
doing
my
at
the
time
when
I
decided
that
I
wanted
to
be
an
open
source
was
a
time
when
I
was
doing
a
an
internship
in
a
very
big
company
at
the
time,
and-
and
I
was
doing
that
internship
and
I
was
looking
at
what
I
was
doing,
which
was
which
was
an
interesting
project,
but
it
was
nowhere
near
finding
itself
in
the
hands
of
users,
and
I
don't
think
it
ever
did.
B
B
You
know
in
this
cubicle
that
I'm
in
in
order
for
this
to
happen-
and
I
was
realizing
it'll-
probably
mean
at
least
10
years
today-
it's
faster
actually
for
various
reasons,
but
back
then
it
meant
at
least
10
years
of
you
know,
quote
unquote,
making
coffee
and
and
or
the
equivalent
of
making
coffee
just
doing
boring
tedious
tasks.
B
Before
I
potentially
find
myself
in
a
situation
where
I'm
able
to
impact
my
destiny,
that
was
really
unappealing
and
then
at
the
same
time
there
was
this
possibility
of
just
going
and
doing
whatever
you
want
to
do
now.
If
you
were
going
to
do
whatever
you
were
going
to
do,
you
do
have
to
answer
one
question:
what
are
you
going
to
eat
in
the
meantime
and
we
were
young
back
then
we
didn't
have
a
lot
of
responsibilities.
B
It's
we
didn't,
have
children
to
worry
about,
and
family
tables
to
put
bread
on,
so
we
had
less
of
of
of
a
problem
in
that
regard,
but
there
was
a
problem
nonetheless,
which
takes
us
to
our.
You
know
final
axis
that
we
will
be
pursuing
here,
our
relationship
to
money.
So
for
me
that
relationship
started
with
you
know.
I
was
just
a
student
I
did
started.
B
I
was
actually
still
in
my
masters
when
I
started
jitsi,
so
my
parents
were
still
helping.
I
had
a
you
know
some
sort
of
a
a
little
bit
of
money
coming
through
in
the
form
of
a
scholarship
and
then
when
I
did
enter
my
phd
there
was
a
contract.
B
It
was
contract
funded,
so
some
amount
of
money
enough
to
keep
me
in
life
was
was
coming
in
and
I
was
able
to
do
that,
although
it
became
more
complicated
when
we
started
to
grow
so
as
jitsi
was
born,
which
was
2003,
it
was
called
zip
communicator
back.
Then.
I
clearly
remembered
this
moment
when
I
came
back
from
from
christmas
vacation
once
and
I
did
a
cvs
update
because
back
then
there
was
no
gear
cvs.
B
If
I'm
the
only
one
that's
working
on
it,
so
you
know
because
back
then,
even
when
there
were
contributions,
they
were
just
occasional
and
still
it
was
me
that
had
to
do
the
work
of
actually
exactly
so.
It
became
very
important
to
me
at
that
point
that
well
there
has
to
be
a
team
of
people
working
on
this.
If
this
entire
effort
is
is
to
mean
anything,
and
the
interesting
thing
is
that
you
know
it
wasn't
exactly
clear
to
me
what
it
was
supposed
to
mean.
It
wasn't
exactly.
B
I
didn't
have
a
you
know,
a
very
clear,
exact,
precise
vision
of
where
the
product
had
to
land.
I
just
knew
that
I
wanted
it
to
be
something
meaningful,
and
I
kind
of
expected
that
hey
we'll
figure
that
out
along
the
way
as
we
go,
which
is
kind
of
different
from
the
startup
vision
right,
because
the
startup
vision
is,
you
are
expected
to
provide
an
answer
to
exactly
how
you're
going
to
change
the
world.
Now,
I'm
not
throwing
stones
at
any
of
those
of
these
approaches.
B
I
think
sometimes
people
do
have
a
vision
and
it
is
easy.
It
is
good
to
support
such
visions,
but
I
don't
think
that
that
is
the
only
way
we
can
and
even
we
do
arrive
at
solutions.
I
I'm
also
a
big
fan
of
the
idea
that
incrementally
building
and
just
looking
around
you
and
and
seeing
what's
necessary,
paying
attention
to
the
problems
that
people
have
and
just
ever
always
adapt
and
and
try
to
to
provide
better
solutions
to
people's
problems.
B
So
I
I
subconsciously,
I
think,
that's
where
my
mind
was
heading,
but
so
again
that
meant
that
we
had
to
we.
We
had
to
form
a
team
of
people
who
were
working
on
this
now.
This
started
with
jana
was
the
first
person
to
join
that
team.
So
she
she
too
was
an
engineer
at
the
university
of
strasbourg
and
she
too
started
contributing
some
of
her
time
to
this,
and
then
we
really
had
to
find
money
in
order
to
allow
for
more
people
to
be
full
time
on
it.
B
So
our
initial
approach
to
money
was
through
public
funding
and
public
funding
meant
funding
from
university.
There
were
these
local
funds
in
strasbourg
in
france
that
were
helping
early
startups
and
we
went
and
applied,
and-
and
we
had
a
couple
of
grants
that
helped
us
that
helped
that
helped
us
get
started.
So
this
is
it.
This
is
our
situation
at
the
beginning
of
the
project.
We
were
fiercely
pro-open
standards,
we're
fiercely
pro-open
source
and
we
rely
on
public
funding
as
a
means
to
start.
B
The
start
was
was
was
filled
with
ideas.
I
don't
know
that
that's
even.
A
Well,
yeah,
absolutely
I
mean
if
you
look,
if
you
look
at
how
the
world
is
today,
you
would
argue
that
what
you
did
was
a
boring,
bootstrapped,
a
business
right.
You
started
scratching
this
itch
and
slowly
just
no
super
grand
vision
just
going
for
the
next
step
and
then
the
next
step,
and
then
the
next
step
is
well.
I
need
someone
to
do
some
ui,
so
I'll
hire
someone
well,
we
need
to
pay
them.
So
let's
find
some
money
there
and
sort
of
like
that
or
organically
growing.
B
That's,
that's!
That's
exactly
it
so
now,
even
though
we
we
had
a
little
bit
of
money
to
get
started,
it
wasn't
enough
to
keep
us
going
for
forever,
so
we
had
to
start
finding
real
customers.
B
Now
I
really
love
how
things
turned
out
for
us,
because
what
we
ended
up
doing
as
a
business
model
was
something
that
people
often
do
in
the
open
source
world.
We
were
providing
engineering
services
around
the
gt
project,
so
you
come
in.
You
see
that
it
does
90
of
what
you
want
it
to
do
and
you
want
it
to
be
tweaked
in
a
certain
way.
You
want
extra
configuration
options
or
new
features
in
order
for
it
to
to
suit
your
needs
and
by
you.
B
In
this
case
I
mean
usually
some
voice
service
provider,
someone
selling
you
know,
telephony
solutions
to
people
or
messaging
solutions
to
people,
and
they
want
to
have
their
own
client
in
order
to
best
deliver
the
user
experience
that
suits
them,
and
we
feel-
and-
and
you
know,
starting
with
an
open
source
project-
that's
almost
there
and
then
tweaking
it.
A
certain
way
is
a
good
way
to
solve
your
problem.
B
It
definitely
was
back,
then,
I
think
ever
since
the
work
has
moved
to
a
more
efficient
way
and
we're
going
to
talk
about
that
in
a
second.
But
that
was
the
way
that
it
was
supposed
to
be
done
back
then.
Today,
people
do
that
with
apis,
essentially
changing
the
apis
on
top
of
each
other
and
all
that
sort
of
stuff.
So
that's
what
we
were
giving
customers
what
customers
were
giving
us
and-
and
I
think
this
is
where
my
relationship
to
money
started
changing.
B
So
there
was
this
ring
to
money
in
the
open
source
world
in
our
communities
that
you
know
the
suspiciousness
of
money.
Everyone
was
acknowledging
hey.
We
need
to
put
bread
on
the
table,
but
at
the
same
time
you
know
too
much.
Money
was
always
viewed
suspiciously
as
something
that
would
corrupt
you,
that
that
is
not
illegitimate.
You
know
focusing
on
every
single.
B
B
Well,
I'm
just
going
to
focus
on
getting
as
much
money
as
I
can
and
I'm
going
to
worry
about
everything
else
later
and
then
later
you
realize
that
oh
I've
actually
put
myself
on
paths
where
it's
even
impossible
to
to
not
to
get
out
of.
However,
the
positive
side
of
of
working
with
actual
real
customer
money
was
that
that
really
changed
the
accent
of
what
we
were
doing.
B
So,
to
give
you
an
example,
the
way
that
public
funding
works
is
that
you
know
you
have
some
institution
somewhere
that
allocates
a
certain
amount
of
money
for
a
certain
topic
that
resonates
with
them.
Now
why
that
resonates
with
them
is
is
different,
but
it
usually
some
sort
of
political
reasons.
You
know
it's,
these
people
were
usually
elected
and
their
voters
expect
them
to
kind
of
direct
channel
money
into
specific
topics.
You
know,
and
it
might
be
communication
it
might
be
environment
or
whatever.
B
Now
what
this
doesn't
really
address,
especially
in
our
case,
is
that
you
know
it
kind
of
says
we
want
work
to
be
put
in
that
way
in
that
direction.
B
I
mean
this
person
gets
up
every
day
and
tries
to
do
a
task
and
that
task
takes
them
10
hours,
it
should
start
taking
them
10
minutes,
because
other
people
are
waiting
and
and
it's
we
just
need
these
things
to
happen
faster
or
all
these
sort
of
things
that
focus.
You
know
that
that
difference
in
focus
was
was
very
palpable
between
public
funding
and
and
and
contracts
that
you
get
from
customers.
B
B
So
there
was
a
lot
of
I
I
don't
want
to
minimize
it,
but
it
wasn't
again.
Let
me
put
it
this
way:
we've
had
customers
who
come
to
us
and
they
ask
us
to
solve
a
problem
and
you
know
send
let's
say,
handle
voicemail
a
certain
way
or
something
like
that
and
and
then
we
start
working
on
it,
and
then
we
realize
that
it's
not
going
to
work
that
way
and
that
customers
weren't
needing
exactly
that.
B
So
we're
going
to
change
mid
course
and
go
and
solve
it
a
different
way,
and
maybe
we
started
with
dtmf
control,
but
it
actually
had
to
be
with
voice
commands
or
with
specific
buttons,
and
it
keeps
changing,
and
at
the
end
of
the
day,
that's
what
matters
did
we
make
the
situation
better?
For
someone
who
is
a
customer
of
our
customer
in
in
funding
that
that
is
a
bad
thing
when
you're
doing
public
funding
what
is
perceived
as
good
as
you
did,
what
you
said
you
would
do
and
it
didn't.
B
It
doesn't
really
matter
what
you
learned
along
the
way.
If
you
just
said
well,
we
actually
decided
to
do
a
completely
different
thing,
that
that
is
a
very
bad
thing
in
public
funding,
which
is
completely
understandable.
We
don't
want
you
to
take
everyone's
money
and
run
away
with
it
and
not
do
what
you
said
he
would
do,
but
but
it
does
create
this
tension.
It's
like
look.
I
thought
this
was
going
to
be
the
right
thing
to
do
and,
as
I
started
doing
it,
I
realized
that
it
wasn't.
B
A
A
little
story
in
the
in
the
in
the
topic
of
public
funding,
as
well
with
a
segway
into
open
standards,
actually
yeah
remember.
I
was
in
germany
and
we
had
received
some
some
public
money
for
a
project
that
was
around.
You
know
real-time
communication,
stuff
and,
and
we
had
a
little
presentation
to
sort
of
show.
A
Indeed,
like
a
report,
we've
been
working
on
these
technologies,
blah
blah
blah,
but
the
night
before
the
iphone
4
launched-
and
there
is
this
famous
slide
with
where
steve
jobs
is
doing
this,
and
here
it
shows
the
technologies
that
facetime
has.
It
was
like
sdp,
h264,
ac,
codex
rtp,
and
then
we
just
replaced
our
presentation
with
that's
like
what
have
you
been
working
on
this
thing?
All
of
them,
except
you
know,
connected
with
open
standards
instead
of
in
facetime,
and
that
was
all
they
needed
to
hear
right
right,
all
right,
great
great
job,
moving.
B
On
yeah-
and
you
know,
it
makes
sense
for
them
to
do
that,
because
you
know
people
in
these
institutions.
They
want
to
make
sure
that
we,
you
know,
we
abide
by
certain
moral
rules
and
whatnot,
but
again
what
you
lose
completely
is
the
place
where
the
rubber
hits
the
road
and,
at
the
end
of
the
day,
does
that
make
anyone's
life
somewhat
easier.
That
connection
is
lost
in
in
public
funding.
I'm
not
saying
this
with
denigration
for
public
funding.
B
I
do
think
it
is
completely
required
for
many
things,
but
over
reliance
on
on
on
that
is
can
be
bad.
Just
as
over
reliance
on
on
on
vc
money
can
lock
people
into
these
burnout.
Startup
efforts,
you
know
truth
is
truth-
is
out
there.
The
truth
is
out
there
in
in
the
middle,
so
there
we
are.
That
was
our.
I
think
our
first
transition
just
realizing
that,
at
the
end
of
the
day,
money
wasn't
simply
a
tool
that
can
corrupt,
which
it
can't,
but
it
was
also
a
tool
to
confirm
value.
B
You
know
I
like
how
the
evolutionary
psychologists
or
biologists
refer
to
to
these
things
called
zahavian
signals,
and
these
are
essentially
the
difference.
Imagine
the
difference
between
me
telling
you
that
something
is
important
to
me.
This
is
important
to
me
or
me,
telling
you
that
something
important
is
important
to
me
and
proven
it
in
a
very
costly
way
to
me,
which
of
the
two
has
a
higher
likelihood
of
being
an
honest
signal.
Obviously
the
one
that
was
costly
to
me
is
is
is
like.
I
wouldn't
engage
in
it.
B
If
I
didn't
really
mean
it,
so
all
sorts
of
animals
do
that
in
their
it's
part
of
sexual
selection,
and
I
think
it
also
matters
in
in
interactions
between
companies.
B
It's
you
know
where,
when
you're
dealing
with
with
public
funding
you're,
always
in
the
sphere
of
saying
what
you,
what
is
it,
what
is
supposed
to
be
important
for
you,
but
it's
not
always
clear
that
you
really
mean
it
and
there's
a
lot
of
abuse
of
public
fund
for
for
that
reason
where,
on
the
other
hand,
if
you're
putting
your
money
where
your
mouth
is,
then
that
at
least
you
know
has
the
advan
the
merit
of
being
completely
honest.
B
A
Yeah,
I
mean
absolutely
now
fast
forward
in
a
few
years.
Suddenly
there
was
a
pivot
in
the
industry.
I
guess
where
we
shifted
away
from
having
everything
done
in
the
like
a
lot
of
done
in
the
client
side.
So
in
this
you
know
a
piece
of
software.
We
run
in
our
computers
to
the
browser,
because
webrtc
happened
and
around
that
time,
as
well
as
it's
made
another
transition
in
how
the
project
was
run.
B
There
was
indeed
a
big
shift
and
it
was
a
tremendous
shift,
and
this
this
takes
us
to.
I
think,
one
of
the
the
main
lessons
that
we've
learned
from
these
three
stories,
and
let
me
let
me
take
you
a
little
bit
back
gt
started
as
a
sip
soft
phone.
It
was
built
for
audio
video
calls.
It
then
morphed
into
a
messenger
that
almost
didn't
even
have
its
its
audio
video
functionality,
but
we
kind
of
moved
into
this
combined
meta,
messenger
concept.
B
We
completely
almost
completely
wrote
everything,
then
our
focus
to
sip
audio
video
came
back,
so
we
we
reintegrated
the
code
that
we
had
in
the
beginning.
It
was
still
mostly
sip.
Then
we
went-
and
you
know,
focused
on
supporting
audio
video
for
jabber,
because
we
felt
that
that
was
the
a
good
way
to
provide
a
fully
functional
communicator.
We
started
thinking
more
at
that
point
by
the
way,
not
not
about
playing
a
role
defined
by
standards,
but
really
solving
people's
issues.
B
So
we
started
you
know,
thinking
about
xmpp
hey.
This
is
a
good
way
to
actually
provide
the
the
proper
audio
video
communicator
to
to
people.
Then
we
thought
well,
just
the
communicator
isn't
enough,
and
and
people
need
things
like
conferencing
functionality
and
they
cannot
always
rely
on
their
server.
That's
one
of
the
problems
with
standardization
that
you
can
be
talking
to
all
sorts
of
different
servers,
different
components
that
have
different
functionality
and
you
have
to
handle
these
differences.
B
The
way
we
thought
we
would
handle
the
need
for
conferencing
and
it
not
being
available
in
every
for
for
every
person
was
well
we're
just
going
to
implement
conferencing
in
the
client
and
we
started
by
implementing
audio
conferencing
and
we
started
by
making
that
more
interactive.
Then
we
thought
oh
well.
Audio
conferencing
is
not
enough.
Let's
make
sure
that
we
also
add
video
again.
B
So
the
client
became
this
conferencing
server
for
audio
and
video,
which
is
one
of
the
reasons
why
we
immediately
went
to
video
routing
rather
than
video
mixing,
because
you
can't
mix
on
a
on
a
client's
computer,
but
he
could
route,
video
and,
and
that
looked
that
looked
pretty
good.
Then
we
thought
wow
actually
clients,
even
though
they're
capable
of
routing
video
are
not
necessarily
your
connections.
Internet
connections
that
are
capable
of
writing.
B
Video,
and
even
if
they
are,
you
cannot
have
one
user,
carry
all
the
responsibility
of
the
entire
conference
because
they
might
just
want
to
leave
the
call
at
some
point.
So
we
thought,
let's
just
take
all
that
functionality
and
put
it
in
the
server
and
that's
how
gt
video
bridge
was
born.
It
was
code
from
jitsi.
Some
of
the
lines
of
code
were
from
the
very
first
jitsi,
but
now
it
became
this.
This
server
product
then
came
the
shift
that
you
were
talking
about
webrtc
and
which
was
such
a
tremendous
change
in
our
industry.
B
But
what
what?
What
it
allowed
us
to
do
is
to
completely
get
rid
of
the
client-side
code
that
was
written
in
in
java,
which
had
its
own
challenges
and
to
replace
it
with
javascript.
So
we,
the
jitsi
core,
continued
to
live
in
the
server,
but
now
it
had
this
complete
new
front
end
and
now
here's
a
very
interesting
piece
when
we
did
that
it
was
the
first
step
of
our
new
building,
in
which
we
were
no
longer
one
player
playing
a
specific
role
in
the
entire
communication
solution.
B
We
were
now
the
entire
communication
solution,
and
this
is
a
change
that
happened
thanks
to
webrtc.
So
let's
talk
a
little
bit
about
that
webrtc
most
people
know
the
story
was
essentially
a
group
of
technologies
that
google
acquired
over
time
and
then
open
sourced
and
it
made
available
to
everyone.
Now.
I
think
that
the
way
that
this
really
changed
the
industry
was
that
remember
how
we
talked
about
everyone
played
their
standard,
defined
role
and
that's
how
we're
all
able
to
collaborate.
B
B
So
we
could
just
do
these
things
on
generic
hardware,
but
also
you
now
have
these
giants
that
have
that
have
given
us
access
to
things
like
webrtc,
so
we
can
incorporate
them
and
and
and
really
build
holistic
solutions,
as
opposed
to
being
cornered
in
in
a
single
role.
I
think
that
was
really
the
main.
The
main
change
of
the
industry,
because,
because
having
the
standards
means
that
you
kind
of
put
yourself
in
this
corner,
where
you
you,
you
not
only
you're
playing
a
specific
role,
that's
not
the
only
problem
with
standards.
B
The
second
problem,
which
is
potentially
even
bigger
with
standards,
is
that
you're
all
playing
a
specific
game.
You
know
you
are
doing
a
telephone
networking
solution.
That
kind
of
does
the
same
things
as
a
telephone
network.
You
know
it's
you
you,
it
did.
Sip
wasn't
built
for
notaries
to
sign
doc,
to
notarize
documents.
For
you
over
a
webpage.
It
wasn't
built
for
people
to
play
dungeons
and
dragons
together.
It
wasn't.
B
You
could
use
it
for
these
things,
but
that's
not
why
it
was
invented
and
with
this
new
approach,
where
look
we're
going
to,
let
you
define
the
game
that
you
want
to
play
and
we're
going
to
give
you
all
the
building
blocks
so
that
you
could
build
it
so
that
you
can
define
whatever
game
you
need.
This
is
what
webrtc
did
for
telecommunications
and
it's
actually
what
the
web
did
for
everything
right.
That's
you
can
you
can
find
similar
trends
in
absolutely
every
every
business
and
in
every
industry.
A
I
think
one
of
the
more
important
things
from
that
from
the
kind
of
technical
perspective
was
that
it
is
really
really
hard
to
have
a
good
media
engine
built
from
scratch.
Yeah
and
webrtc
gave
it
to
us.
It
had
like
state
of
the
art
or
canceling,
and
we
didn't
even
have
to
work
for
it.
I
just
got
in
the
browser
and
with
the
new
update
it
just
gets
better
and
building
on
top
of
it.
It
really,
for
instance,
it
did
level
the
playing
field.
A
So
you
could
everybody
was
building
on
top
of
this,
and
there
was
no
oh,
that
zip
client
is
proprietary,
but
it
has
access
to
that
proprietary,
echo
counselor,
that's
so
good.
Now,
here's
everybody's
playing
by
the
same
by
those
same
rules
and
it's
a
great
building
block.
So
I
remember
when
we
we
just
stopped
worrying
about
that
that
media
partner
is
like
so
now
it
all
just
works.
B
So
now
we
can
all
focus
on
actually
solving
user
problems
and
not
simply
technological
problems,
so
so
so
this
was.
B
This
was
quite
quite
the
experience
for
us
as
well,
and
then
around
that
time
we
also
got
acquired
as
jt
by
atlassian.
It
was
in
2015,
which
I
think
coincides
with
really
the
time
when
companies
moved
to
the
cloud
amazon
started
existing
around
2008,
but
but
really
the
cloud.
The
massive
migration
to
cloud
was
somewhere
in
the
mid
2015s,
where
every
company
just
figured
out.
No,
that's
that's
how
we
got
to
be
now.
B
This
is
this
leads
us
to
our
learnings
about
open
source,
because
I
think
that
massively
changed
the
game
about
open
source
with
the
cloud
game
came
a
certain
amount
of
flexibility.
Now
right
you
you,
I
don't
need
you
to
pay
me
money.
B
If
I'm
writing,
if
I'm
writing
software,
I
don't
need
you
to
pay
me
money
that
would
kind
of
pay
for
the
entire
development
of
the
product
that
I'm
giving
you
right
because
remember
we're
talking
about
binaries,
I'm
giving
you
the
thing,
and
I
want
you
to
give
me
the
money
that
pays
for
this
entire
thing
or
or
at
least
the
compound
earnings
pay
for
this
entire
thing.
That's
no
longer
necessary
because
I
don't
need
to
install
a
bunch
of
servers.
B
Now
I
can
go
in
on
demand,
get
things
from
the
cloud
when
I
need
them,
which
means
that
I'm
more
flexible,
which
means
that
I
can
give
you
more
flexibility,
which
is
why
a
lot
of
the
the
you
know
move
started
happening
to
to
subscriptions.
B
So
you
know
you
want
to
be
a
customer
this
month
and
not
the
next
one.
No
problem.
A
B
Can
do
that
now,
this
move,
and
this
incorporated
flexibility
now
now
changed
the
the
the
relationship
to
the
actual
code
that
the
companies
had
to
the
actual
code.
B
Remember
how
companies
like
microsoft,
had
this
very
hostile
relationship
to
open
source
and
google
back
in
the
day
were
you
know
very
unique
for
for
fostering
open
source,
probably
because
they
kind
of
were
already
living
the
first
days
of
the
cloud
when
you
are
in
the
cloud,
the
money
is
no
longer
being
given
for
the
code
it
is
now
being
given
for
the
service,
which
means
that
the
obsession
of
who
gets
their
hands
on
the
product
and
and
the
code
became
it
disappeared,
and
I've
seen
this
a
lot
with
with
companies.
B
The
more
a
company
has
been
dealing
with
selling
licenses
in
the
past,
the
more
it
has
it.
It
had
a
hard
time
of
embracing
open
source,
any
companies
that
is
cloud
native
realizes
completely
that
keeping
your
code
private
is
just
an
expense
that
takes
effort,
and
it
doesn't
really
give
you
anything
it.
That's
no
longer
a
thing,
that's
worth
protecting
that
much
it.
In
fact,
it's
much
better
for
you
to
just
not
spend
the
cost
on
keeping
it
secure
and
put
it
out
there
and
potentially
get
a
feedback.
B
B
B
We've
always
made
sure
that
jitsi
in
itself
is
a
solution
to
a
problem,
not
just
a
piece
of
another
bigger
thing,
which
is
what
many
companies
do
now
you
know
some
companies
would
only
open
source
their
api
to
a
proprietary
system,
the
incentive
for
someone
to
come,
and
collaborate
with
that
is
much
lower
because
they
don't
have
the
system
that
this
fronts
you
know
they
might
be
a
developer
that
uses
it.
B
They
might
throw
in
some
sort
of
a
trivial
bug
fix,
but
they're
not
going
to
come
in
and
add
functionality
around
that
yeah.
If
you
want
someone
to
do
that,
they
have
to
feel
that
they're
adding
functionality
to
their
own
thing
as
well.
Right,
so
that's,
I
think,
a
main
difference
like
the
main
requirement
for
open
source
project
just
for
a
successful
product.
It
has
to
solve
people
problems
if
you
want
people
to
put
their
time
and
effort
in
it,.
B
So
that
changed
with
with
open
source
was,
was
you
know
pretty
pretty
key
when
I
think
about
this?
I
think
that
another
key
element
of
of
this
entire
thing
is
that
of
the
way
that
open
source
changed
was.
I
think
people
sometimes
don't
give
enough
credit
other
than
the
hardcore
open
source
idealists.
I
think
people
in
the
proprietary
world
and
the
today's
business
world
don't
give
enough
credit
to
people
like
richard
stallman
for
what
for
what
they
did
and
how
much
they
helped,
including
business.
B
Now,
one
of
the
key
contributions
that
richard
stallman
did,
I
think,
was
that
when
he
insisted
that
you
know
every
project
ships
out
with
a
specific
license,
you
know
most
people
focused
on
the
fact
that
you
know
he
was
promoting
the
new
licenses,
but
but
but
what
they
didn't
really
realize
is
that,
with
that
came
the
notion
that
everything
has
to
have
a
license.
Even
if
it's
not
the
new
one,
everything
has
to
have
a
license,
and
I
think
we
I
I.
B
I
really
believe
that
people
like
richard
stallman
and
the
ones
that
that
established
that
notion,
even
though
he
meant
it
for
a
specific
one
again,
what
ended
up
happening
is
that
they,
everything
like
licenses,
are
kind
of
expected
and
found
in
most
projects,
especially.
A
The
projects
that
matter
they're
critical,
you
know
a
couple
of
years
ago.
There
was
this
thing
with
the
react
license
that
it
was
a
huge
turn
off
for
the
community
and
they
ended
up
having
to
change
it.
So
for
many
people
it
like
a
good
license
is
critical.
B
And
the
reason
it's
critical
is
because
remember
one
of
the
main
points
of
open
source
is
that
it
facilitates
collaboration.
B
I
used
to
participate
in
in
european
commission
projects
and,
and
they
were
universities
and
private
companies,
big
and
small,
participating
in
and
the
way
that
these
things
got
decided
there.
You
know
a
consortium
would
be
formed
and
people
would
start
negotiating.
But
what
is
it
that
exactly
that
they'll
do
and
what
terms
would
it
be
available
to
which
partners
and
those
discussions
were
taking
months
before
a
single
line
of
code
was
written?
B
And
at
that
point
that
was
when
I
had
my
moment,
and
I
realized
that
the
fact
that
you
don't
have
to
deal
with
that
in
open
source
that
going
in
you
already
know
what
the
terms
are
going
to
be
is
is
so
precious
it
is.
It
is
absolutely
necessary.
B
It
actually
having
some
turns
matters
way
more
than
having
any
terms,
because
if
you
don't
have
any
terms
now
now
we
have
you've
opened
room
for
argument,
and
then
people
start
getting
on
the
details
and
it
actually
turns
out
that
doesn't
really
matter
because
you
choose
as
long
as
your
licenses
are
within
of
well-known
licenses.
Yeah,
it's
people
actually
don't
really
get
hung
up
on
the
details.
So
I
think
that
was
a
major
realization
about
open
source
as
well.
B
So
I
think
that
pretty
much
is
our
journey
and
if
I
have
to
going
to.
B
And
I
I
don't
think
I'm
good
at
those
I
mean
neither
and-
and
I
I
I
think,
there's
obviously
plenty
of
exciting
stuff
that
will
be
happening.
What
what
I
could
say
is
that
I
believe
the
trend
where
we
work
together
by
stepping
on
each
other's
shoulders,
rather
than
on
on
forming
these
consortiums,
whether
it's
through
standardization
or
through
european
projects,
or
something
like
that,
I
think,
building
on
layers-
is
going
to
be
an
approach
that
that
matters
that
works
a
lot
more
better.
B
That's
why
we,
when
jitsi,
for
example,
decided
that
jitsi
the
open
source
project
is
not
only
going
to
be
a
cl,
a
solution
for
having
video
conversations,
but
it's
also
first
going
to
be
an
embeddable
component
that
can
be
part
of
other
solutions
and
and
that's
what
our
business
is
about.
But
it's
also
what
the
open
source
project
is
about.
Now,
it's
an
embeddable
component
that
others
can
can
step
on.
B
So
I
think
that
this
enables
tremendous
innovation
and
you
you
liked
this
this
way
of
putting
it
the
other
day
that
we're
now
in
a
position
where
jitsi
can
be
the
perfect
solution
for
your
second.
Most
important
feature
like
you
can
focus,
you
know
you
can
just
the
way
that
we
take
the
media
engine
from
webrtc
and
then
we
focus
on
exactly
the
details
of
the
video
conferencing.
B
I
think
what
this
has
enabled
is
an
incredibly
fast
pace
of
innovation,
we're
all
aware
of
of
the
new
technologies
that
are
coming
out
with
regard
to
machine
learning
and
artificial
intelligence.
B
A
Absolutely
I'd
say
that
like
without
actually
planning
for
it,
as
you
said,
there
was
no
grand
vision,
the
one
thing-
and
this
is
actually
how
your
path
and
my
path
kind
of
went
parallel
is
we
worked
on
things
to
communicate
with
others
and
that
I
don't
know
why.
But
that
fills
me
with
joy
sort
of,
and
I
I
like
a
lot
this
path
in
the
end,
the
only
constant
it
doesn't
matter.
You
build
a
desktop
client.
Then
you
build
a
server.
A
Then
you
do
a
website
for
it,
because
that's
where
the,
where
the
path
takes
you,
but
in
the
end
it's
about
making
a
tool
to
communicate
people.
So
we
don't
know
what's
going
to
happen,
5
10
20
years
from
now,
but
it's
probably
going
to
revolve
around
communicating
people,
at
least
of
that,
I'm
pretty
sure.
B
That
I
I
completely
agree
with
you.
I
I
think
that
communication
is
is
key
to
our
progress
as
a
society.
I
think
I'm
actually
very
happy
that
more
and
more
communication
is
happening,
even
though
some
people
perceive
that
as
polarization
what
I
actually
believe
that
no
it's
just
that
more
people
are
being
able
to
voice
their
opinions
and
and
ultimately,
that's
good,
even
if
sometimes
the
friction
might
appear
too
hot.
B
A
Yeah
now,
let's
hope
that
these
three
stories,
these
three
lessons,
these
three
things
that
we
learned
across
this
journey
will
help
others
in
their
own
journeys.
That's
the
that's
the
best.