►
From YouTube: The Maintainers: Dennis Doomen and FluentAssertions
Description
In this series, I'll be interviewing Open Source Maintainers and talk about what open source means to them and why they do it. This episode:
Dennis Doomen of FluentAssertions
Dennis is a veteran architect in the . NET space with a special interest in writing clean code, Domain Driven Design, Event Sourcing and everything agile. He specializes in designing enterprise solutions based on the . ... Like when to apply Event Sourcing and at what architectural level.
- Twitter: @ddoomen
- GitHub: https://github.com/dennisdoomen
- Blog: https://www.continuousimprover.com
- FlientAssertions: https://fluentassertions.com
A
A
A
So
the
first
project
that
I
was
involved
with
is,
I
think,
if
I'm
not
mistaken,
is
my
own
project,
because
I
was
looking
for
like
me
and
a
colleague,
martin
opdam.
We
worked
on
this
and
then
at
some
point
I
felt
like
hey.
This
is
actually
pretty
cool.
There's
nothing
available
right
now
on
the
internet
and
we
thought
like
let's
try
to
make
it
open
source
or
you
know,
just
publish
the
source
code
in
some
form
which
started
with
codeplex.
A
Obviously,
so
when
we
put
it
on
koplex,
we
were
hoping
to
get
a
lot
of
contributions
because
we
thought
like
okay,
maybe
you
know
maybe
at
some
point
it
will
get
some
traction
and
then
people
can
contribute
to
it,
because
that's
the
whole
point,
but
I
think
it
was
still
based
on
the
team
foundation.
Server
source
control
system
and
even
ourselves
for
ourselves
was
very
difficult
to
to
to
develop
the
project
you
had
to
create
patch
files.
A
If
I'm
not
mistaken
it's
a
long
time
ago,
and
it
was
very
horrible
to
work
with
because
just
try
to
I
mean
just
the
two
of
us
trying
to
create
the
right
patch
files
was
painful,
let
alone
other
people
trying
to
contribute
in
that
way.
It
didn't
really
work.
So
in
general,
what
will
happen?
Is
people
would
file
an
issue
or
request
a
request
that
we
would
do
the
work
because
yeah
we
would
push
directly
well,
I'm
using
the
word
push
now
it's
it's
weird,
because
that
didn't
even
exist
at
that
time.
A
We
all
used
to
get
now,
but
at
that
time
yeah
we
would
directly
commit.
I
think
it's
the
term
in
tfs
that
you
had
to
use
the
changes
directly,
so
it
didn't
really
go.
Well
I
mean
people
were
downloading
it
and
then
at
some
point
we
pushed
it
to
nougat
that
make
a
difference.
Then
we
started
to
see
a
couple
of
downloads
like
10
20,
maybe
100
after
a
couple
of
months.
A
A
I
also
have
lots
of
interest.
I
mean
I
fluently
search
is
not
the
only
open
source
project.
I
have
a
couple
of
other
ones
which
I'm
not
that
active
with,
but
I
also
have
the
intention
of
the
blog
regularly
about
my
experiences.
It
is
difficult.
It's
not
every
evening
that
I'm
really
looking
forward
to
sit
behind
my
machine
again,
because
you
know
everybody
knows
it
in
the
go
fit
time
frames.
You
already
spend
way
more
time
behind
your
screen.
A
Every
meeting
is
a
screen
screen
time
so
an
evening,
sometimes
I'm
tired,
but
in
general
yeah
I
still
try
to
contribute
we're
really
actively
working
on
fluid
version
6
and
there's
a
lot
of
refactoring
that
I
do.
I
use
my
project
also
for
workshops.
I
give
more
workshops
about
maintainable
code
and
quite
often
I
use
the
the
code
itself
as
an
example
while
demonstrating
and
talking
about
maintainability,
I
just
go
over
like
hey.
Wait,
wait
a
second,
that's
actually
a
technical
debt.
A
So
one
of
the
questions
I
sometimes
hear
is
like
what
was
the
trigger
to
to
contribute
to
open
source.
Honestly,
I
don't
have
a
clue.
I
don't
remember
it
was
just
fun.
I
remember
that
there
was
this
very
lively
group
of
people
on
open
source,
but
just
that
the
fact
that
there
was
something
that
I
liked-
and
I
saw
value
in,
could
could
help
other
people
to
to
use,
and
I
mean
I
use
open
source
a
lot
myself,
but
there
was
not
never
really
really
any
deep.
A
I
don't
know
deep
sense
of
not
nothing
behind
that
we
just
yeah.
I
thought
like,
let's
put
it
there,
maybe
somebody
else
would
like
it.
You
know,
and
then
in
the
beginning
you
start
to
see
the
downloads
and
it
becomes
like
hey.
This
is
cool.
We
actually
got
like
100
downloads
now,
so
somebody
is
using
it,
you
know,
and
then
it
becomes
thousands
and
at
some
point
you
reach
hundreds
of
thousands
and
then
you
know
you
reach
the
point
where
other
people
actually
building
extensions
on
top
of
your
own
library,
which
is
like
whoa.
A
Why
would
you
do
that?
I
mean
it's
just
a
simple
library
and
then
people
from
microsoft
reach
out
and
say
yeah.
We
also
use
it
in
the
net
sdk
like
what.
Why
would
you
do
that?
You
know
and
then
blog
posts
are
being
written
and
then
somebody
you
know
tweets
about
a
pluralsight
training.
They
did
about
your
library,
like
dude
man,
it's
just
a
simple
assertion:
library
who
cares,
but
apparently
it's
getting
traction
now.
A
So
one
of
the
reasons
that
why
I
created
fluent
assertions
because
I
care
about
unit
testing,
in
fact
I
care
about
maintainable
code
and
code
is
maintainable
when
it's
easy
to
read.
You
know
you
have
this
statement
about.
Oh
people
read
actually
you
code
nine
times
or
ten
times
more
than
you
write
code.
A
So
then,
what
you
do
you
optimize
for
for
reading,
and
I
I
think
I
remember
that
I
was
triggered
by
a
couple
of
articles
that
jeremy
miller
wrote,
I
think
in
2006
or
seven
like
jeremy's,
first
law
of
tdd,
second
law
of
tdd
and
at
the
same
time
I
was
reading
a
book
by
jimmy
nielsen
about
the
domain
driven
design
and
that-
and
that
is
when
I
started
like
hey.
This
is
really
awesome.
A
Then
I
started
thinking
about
okay,
but
now
I
want
to
make
my
assertions
also
really
readable
and
self-explanatory,
and
if
it
fails,
I
want
to
have
a
clear
explanation.
Of
course
we
had
extension
methods
and
dot
net
and,
of
course,
there's
a
fancy
new
tool.
I
remember
that
I
was
looking
for
a
more
fluent
api.
I
like
the
whole
idea
of
a
fluent
api,
and
I
still
do
that.
A
I
still
do
presentations
about
you
know
doing
test
driven
development
without
shooting
yourself
in
the
food,
and
it's
almost
always
about
finding
the
right
scope
of
a
test,
but
also
to
make
sure
that
your
tests
are
readable.
You
know
that
the
the
cause
and
effect
the
intent-
you
know
the
functional,
be
the
behavior
that
you're
actually
trying
to
validate
and
having
good
unit
tests
or
good
readable
assertions
is
part
of
that
part.
A
One
of
the
things
I
often
tell
my
clients,
if
they
work
on
something
which
they
think
is
not
absolutely
core
business
and
it
could
be
useful
for
other
people.
I
quite
often
encourage
them
to
put
it,
make
it
open
source.
Put
it
on
get
up
or
something
like
that,
and
they
always
ask
me
like:
what's
the
benefit
of
it,
and
I
said
like
okay,
but
you
might
actually
get
contributions,
but
it's
also
an
incentive
for
the
developers
in
your
company
to
deliver
something
that
they're
proud
of.
So
for
me,
it
definitely
is
the
case.
A
I
use
the
the
code
that
I
write
for
fluent
assertions
is
not
just
at
least
from
my
opinion,
in
my
opinion,
good
code,
because
I
want
the
library
to
be
good,
but
I
also
use
it
as
examples.
You
know
when
I
present
about
maintainable
code,
or
I
talk
about
tdd
or
topics
like
that.
I
use
fluent
decisions
itself.
A
If
somebody
creates
a
pull
request
that
usually
already
takes
them
quite
a
lot
of
work
to
add
it.
If
it's
a
simple
thing,
it's
usually
not
that
problem,
there's
a
couple
of
things
we
need
to
consider.
We
want
that
code
to
be
on
the
same
level
as
all
the
other
code.
We
want
it
to
be
covered
correctly
by
unit
tests.
We
want
to
make
sure
that
the
documentation
is
also
updated
because
otherwise
it's
behind.
A
We
also
want
to
release
nodes,
which
we
also
restore
in
source
control,
to
be
updated,
so
that
that's
already
quite
a
burden
for
a
lot
of
people
and
then-
and
usually,
if
we
ask
them
like
okay,
are
you
willing
to
update
release,
notes
and
maybe
update
at
an
example,
they're
fine
with
that?
But
if
it
becomes
a
discussion
about
consistency
or
breaking
changes
or
something
that
we
don't
feel
fits
in
the
library,
then
it
becomes
painful.
Quite
often
people
say
you
know.
I
understand
this
bit
of
an
edge
case.
A
I
understand
if
you
don't
want
to
continue,
don't
want
to
accept
it.
I
can
create
my
own
extensions
or
I
can
even
build
my
own
contribution
library,
but
some
sometimes
people
like
you
know,
really
join
the
slack
channel
and
start
like
extremely
complicated
apostles
to
explain
why
they
need
to
do
that.
You
know
as
an
example,
we
recently
had
somebody
complaining
about
the
fact
that
we
were
doing
blocking
or
dealing
with
asynchronous
code
by
actually
waiting
on
that
by
creating
our
own
synchronization
context,
really
complicated
stuff,
and
they
didn't
agree
with
it.
A
They
thought
it
was
fundamentally
wrong.
This
person
was
right
in
a
sense,
but
it
would
be
very
risky,
be
we
because
we
ran
into
deadlocks
in
the
past.
We
were
really
afraid
to
change
that.
That
is
a
difficult
discussion,
because
this
person
was
adamant
about
changing
it.
We
accepted
the
change
and
agreed
to
do
a
kind
of
an
alpha
version
to
get
some
feedback
because
he's
right-
and
I
don't
want
to
you-
don't
want
to
discourage
people.
Sometimes
you
have
to.
That
is
the
responsibility
I
mean.
Sometimes
it's
real.
It's
like
a
real
project.
A
Sometimes
you
have
to
disappoint
your
users
or
clients,
because
you
don't
want
to
deliver
something
because
it
doesn't
fit
in
your
philosophy
or
your
direction
or
your
roadmap
same
thing
with
an
open
source
project.
It
is
a
project
with
all
the
responsibilities
and
all
the
yeah,
the
things
you
have
to
think.