►
Description
Table of Contents:
00:00 - Hypothesis To Test: Ecosystem “Code Sharing Effects” Have Predictable Maturation Characteristics, Which Carry Potential to Culminate in a Marketplace Effect
01:47 - Leveraging The Mistakes and Victories of Others
04:21 - Maturing the Capability to Reuse Code
07:59 - Hypothesis
12:28 - Development EcoSystem Mapping
19:38 - Marketplaces Critical Role In Scalable Technology Partnership
22:19 - Questions That Emerge
24:38 - Resources
24:41 - Questions That Emerge
A
A
To
do
so,
so
I've
been
exposed
to
it
the
problem
multiple
times
trying
to
solve
for
specific
problems,
but
then
I've
also
been
exposed
to
it
from
the
aspect
of
of
building
systems,
and
then
I've
also
done
a
pluralsight
course
on
chocolatey
nougat
packaging,
in
which
case
we
tore
down
the
whole
concepts
behind
it.
As
a
beginning
way
of
getting
people
started
with
what
is
a
packaging
framework,
because
chocolate
is
bringing
something
that
was
fairly
new
to
the
windows
ecosystem
and
having
basically
yum
for
windows.
A
So
what
is
happening
out
there
via
multiple
samples,
not
just
one
sample
of
organically
derived
architecture,
so
these
models
that
have
developed
over
time
have
developed
in
the
marketplace
a
lot
of
times
through
hard
experience
and
sometimes
by
copying
each
other
due
to
success
so
kind
of
an
organic
ecosystem
of
does.
Does
an
organic
ecosystem
exhibit
a
model
in
a
mature
problem
domain,
so
in
the
case
the
one
we'll
be
talking
about
here
kind
of
the
idea
of
ci
extensibility.
A
A
People
who
are
coming
to
us
already
have
experience
with
and
potentially
implemented,
successful
models
of
what
they're
asking
us
about,
or
for
so
my
other
gut
feeling
is
that
early
adoptership
is
very
difficult
in
this
situation.
Getting
people
are
willing
to
engage
on
bringing
a
technology
to
table
stakes
functionality
when
it's
a
mature
problem
domain
can
be
a
real
problem.
A
So,
if
that's
true,
that
would
make
this
concept
of
looking
to
the
existing
models
more
important
or
more
relevant
than
if
say
we
were
building
a
brand
new
stage
of
devops,
no
one's
ever
thought
of
before,
and
it's
really
cool
and
it's
going
to
solve
a
lot
of
problems
that
haven't
been
solved
yet.
So
just
think
about
that,
as
we
go
through
here.
A
A
If
you
read
the
lean
startup
it
talks
about
how
lean
startup
accounting
should
not
be
applied
to
well-known
problems
that
the
regular
accounting
we
have
for
cost
management
should
be
applied
to
well-known
problems,
and
I
I
think,
by
extension,
we
should
be
careful
about
using
mvcs
to
discover
what
to
build
with
a
well-known
problem,
especially
if
it's
well
solved
in
the
marketplace
so
maturing
the
capability
to
reuse
code.
So
I
just
want
to
take
kind
of
a
historical
look
at
what
seems
to
happen
again
and
again
when
people
try
to
show
their
work.
A
The
first
step
seems
to
be
sharing
snippets.
So
hey
here's,
a
few
lines
of
code
that'll
help
you
out.
You
share
that
through
an
email
or
whatever
systems
you
have
available
to
you,
the
next
level
seems
to
be
templates,
so
then
individuals
take
it
upon
themselves
to
create
a
template
that
is
more
whole
and
potentially
even
working.
So
it's
a
it's
an
example
of
how
to
do
a
complete
task
or
a
complete
sub
thing
within
the
particular
development
technologies
or
languages,
and
so
this
adds
the
concepts
of
wholeness
and
potentially
known
working.
A
Although
it's
I'm
very
ardent
about
known
working
and
kept
working,
not
known
working
at
one
time,
whenever
sharing
this
kind
of
capability
and
a
lot
of
times,
that's
not
the
focus
of
the
marketplace,
then
sharing
components.
So
now
we
have
the
ability
to
actually
share
bits
of
functionality
that
are
runnable
and
this
starts
to
add
the
concepts
of
encapsulation.
A
So
you
can
share
a
piece
of
code
that
is
not
encapsulatable.
It
needs
a
whole
bunch
of
other
window
dressing
to
get
it
working,
but
when
you
start
sharing
components,
the
concept
is
that
they're
encapsulated
versioning
is
a
really
important
part
here,
because
of
the
differences
between
you
know
versions,
causing
a
lot
of
problems
across
the
entireness
entirety
of
all
of
us,
the
software
ecosystem.
A
Then
it
seems
like
we
start
to
go
towards
sharing
packaged
components
and
the
difference
between
components
and
package
components
is
that
it
can
be
very
difficult
to
configure
components
and
resolve
their
dependencies
and
get
them
on
a
system
in
a
way
that
we
know
they're
going
to
work.
So
the
packaging
solves
all
these
issues
and
makes
the
ability
to
share
even
more
frictionless
and
more
valuable,
because
now
we
can
take
dependencies
on
shared
and
packaged
components
if
we
want
to
because
we
can
just
use
them
directly,
either
in
development
or
in
production
products
projects.
A
This
whole
thing
about
shared
packaged
components
too.
On
the
development
side,
we
tend
to
think
of
it
as
sharing
components
into
a
development
stream,
and
then
they
become
a
part
of
the
final
result.
But
if
you
a
lot
of
my
experience,
has
been
on
the
operating
provisioning
operating
system,
provisioning
side
and
in
that
area
stuff
like
yum,
chocolaty
nougat.
A
Actually,
you
get
used
in
production
a
lot
more
because
you're
not
always
making
an
image
of
the
final
thing
like
you
might
make
a
container
or
an
amazon
ami
say,
but
you
might
not.
You
might
just
directly
use
the
packaging
in
production,
so
slight
differences,
sometimes
between
whether
we're
dealing
with
operating
system
or
developer
type
of
components,
then
sharing
packages
through
marketed
places.
So
you
might
have
the
ability
to
share
package
components,
but
there's
no
one
place
on
the
internet
where
you
go
to
see
kind
of
as
much
as
possible,
that's
available.
A
A
So
let's
talk
a
little
bit
about
the
hypothesis
and
kind
of
expand
it
out
a
little
bit,
so
the
hypothesis
is
development.
Ecosystem
adoption
is
significantly
accelerated
by
a
direct
reuse,
componentry
sharing
model
in
the
code
language.
This
is
not
the
actual
package
components.
This
is
the
fact
that
the
coding
language
itself
has
a
potentially
a
model
of
being
able
to
hook
up
code
in
different
ways
in
in
history.
We've
had
java
classes,
dotnet,
assemblies
or
j.net
classes,
and
we've
had
com
components
in
the
windows
side.
A
Before
that,
so
the
actual
technology
of
the
developer
side,
the
technology
has
the
ability
to
componentize
functionality.
That's
pretty
important.
That
generally
requires
managed
and
packaged
dependencies,
modeling
capabilities.
So
now,
when
we
do
start
to
move
into
the
dependency
framework
side
of
this,
we
need
to
have
the
capability
to
do
certain
things.
Essentially,
packaging,
managing
and
modeling,
and
then
also
another
thing
that
kicks
in
at
this
time
is
separate
versioning
from
the
previous
step.
So
before
in
packaging,
we've
tried
to
have
versioning,
that
is,
the
versioning
of
the
underlying
development.
A
Componentry
be
the
same
as
the
packaging
versioning
and,
of
course,
it's
a
best
practice.
If
you
can
do
that
to
keep
those
the
same.
It's
very
helpful.
However
many
cases
we've
had
to
slide
these
versions
to
be
different
in
order
to
fix
things.
For
instance,
the
most
common
I've
seen
is
when
you're
packaging,
when
you're
changing
the
logic
that
installs
stuff
for
a
package,
but
the
actual
code
that
it's
packaging
never
changed.
A
You
need
a
way
to
express
that
this
is
a
newer
version
of
the
package
that
won't
blow
up
on
your
system,
even
though
it's
delivering
the
exact
same
components
as
the
previous
one
that
is
named,
so
we're
going
to
see
as
we
go
through
some
examples
that
naming
or
branding
the
actual
model
for
the
package
dependencies
has
been
a
common
and,
I
think
very
useful
and
helpful
effect
in
the
marketplace.
Technology
is
overloaded
with
so
many
terms.
A
There's
no
way
to
express
that
we
can
actually
similar
to
autodevops
build
some
dependable
componentry,
but
we
don't
have
a
name
for
that,
and
so
it
continues
to
be
a
struggle
for
customers
to
understand
that
we
can
even
do
it
and
it
continues
to
be
a
struggle
to
express
that
we
can
do
it
upon
which
a
component
marketplace
can
be
built.
So
basically
the
idea
is
then,
once
we
have
this
framework,
we
can
potentially
build
a
component
marketplace
now.
A
Another
interesting
technical
requirement
of
0.5
is
the
ability
to
quickly
and
easily
source
this
across
networks,
so
you
can
have.
If
we
look
at
the
evolution
of
the
yum
packaging
model,
rpm
packaging
came
out
first
and
it
did
not
have
a
transit
mechanism
to
frictionlessly
deliver
packages
everywhere.
Well,
yum
was
added.
On
top
of
that,
in
order
to
accomplish
that
same
with
app
get
being
added
on
top
of
the
debian
package,
format.
Apologies
that
most
of
my
examples
are
from
the
system
side
of
the
house.
A
But
that's
that's
where
I've
had
my
career,
so
it's
important
to
see
that
there
is
even
more
technology
that
has
to
come
into
number
five
and
then
I'm
going
to
postulate
that.
Conversely,
this
effect
is
inhibited
to
the
degree
that
the
sum
of
the
above
are
not
matured
and
some
of
the
questions
that
we're
going
to
leave
open
at
the
end
are.
A
Is
there
order
to
these
things?
Do
they
have
to
be
do
they
have
to
exhibit
in
a
certain
order,
for
the
effect
to
happen
are
all
of
them
required
or
not,
but
I'm
gonna
hypothesize
that
that
at
least
some
of
these,
if
they're
not
matured
at
the
right
times
in
the
sequencing
of
building
something
like
this,
then
it's
going
to
have
an
undo
or
a
outsized
effect
on
inhibiting
the
market
effect.
A
A
One
of
the
things
that
we'll
want
to
take
a
look
at
too
is
that
not
all
of
the
individual
items
conform
precisely
to
a
model.
The
the
primary
issue
here
is
that
they
end
up
with
a
marketplace,
so
some
of
the
components
end
up
being
essential
to
certain
models
and
not
to
others
as
you'll
see
as
we
kind
of
walk
through
here.
So
first
of
all,
we
have
the
ecosystem
level
and
just
kind
of
some
commentary
on
the
maturity,
so
in
each
each.
A
The
first
column
here
is
instead
of
instances
it's
just
an
example
of
maturity,
so
with
an
ecosystem
level.
If
we
don't
have
anything
else,
we
can
at
least
have
copy
and
paste
templates
and
snippets,
so
the
lowest
level
of
maturity.
We're
able
to
share
things
with
most
every
language
and
framework,
then,
when
we
start
getting
to
the
reusable
production-worthy
components
a
lot
of
times
most
times.
This
has
something
within
the
language
or
framework
that
allows
us
to
create
componentry
in
the
framework
that
is
then
packageable
separately
and
deliverable
for
runtime
use.
A
So
sometimes
the
languages
need
the
capability
at
this
level
that
you
can
separate
some
files,
send
them
separately,
put
them
into
another
project
and
they
can
be
dynamically
linked
at
that
time.
So
that's
what
we
mean
by
that
directory
use
model
that
the
the
underlying
framework
has
some
sort
of
dynamic
that
allows
you
to
ship
things
separately,
but
they
get
to
work
together
when
they
hit
the
final
system,
then
sure
when
we
have
a
named
package
dependencies
modeling
capability.
A
So
this
is
an
example
kind
of
a
classic
example
where
it's
very
fit
to
pattern,
then
javascript
is
a
little
bit
different
underneath
it
has
node.js
modules
or
ecma
modules
that
allow
us
to
have
some
modularity
at
the
language
level.
Technically,
it
doesn't
have
classes
but
rather
objects.
So
it's
still
got
a
strong
modularity.
I
guess
architecture.
If
you
will
and
then
we
have
npm
packaging
to
wrap
those
in
and
of
course,
npmjs.com
is
the
kind
of
the
primary
marketplace
so
to
speak.
A
The
next
one
we
rip
off
nougat
packaging
for
a
completely
different
purpose.
So
here's
where
someone
says
you
know
what
this
framework
of
being
able
to
deliver
componentry
is
awesome,
and
I
want
to
use
it
for
something
completely
other.
So
in
this
case
the
ecosystem
is
all
kinds
of
installation
file
formats
for
windows
there's
actually
up
to.
A
It's
a
little
bit
different
here,
though,
because
you
don't
have
run
time
control
over
what
those
layers
are
going
to
be
so
really
a
docker
image
kind
of
knits
together
the
layers
and
it's
more
of
a
background
thing,
but
it
is
another
way
of
providing
a
fixed
component
tree.
That's
directly
usable
and
dependable,
being
able
to
depend
on
it,
and
dockerhub.com
is
the
marketplace
for
that.
So
this
is
kind
of
the
non-ci
use
cases
and
some
classic
ones
within
development.
Language
ecosystems
as
well.
A
Sometimes
folks
will
use
I've
heard
they'll
use
maven
packages.
I
think
it
is
in
order
to
generically
package
runtimes
that
aren't
made
aren't
java,
and
so
there
are
some
other
cases.
They're
they're,
not
as
they
haven't
established
their
own
market
like
chocolaty
necessarily,
but
there
are
other
ways
to
try
to
do
this
also,
notably
in
gitlab.
We
have
the
generic
package
feed
now
and
in
theory,
you
could
make
up
some
of
your
own
scenarios
if
you
had
something
unique
now.
A
One
thing
I
wanted
to
point
out
is
marketplaces
play
a
critical
role
in
scalable
technology
partnership
and
I'm
being
a
little
bit
selfish
here,
because
I
work
in
alliances,
and
so
part
of
my
role
is
to
support
our
technology
partnerships
that
happen
at
the
alliance's
level
and
so
marketplaces
function
to
share.
Like
all
solutions,
but
there's
a
special
class
of
solution
of
technology
integrations
so
that
we
can
link
our
system
to
other
systems
and
a
lot
of
I've
even
had
customers
come
in.
A
For
instance,
crossplane
who
made
the
managed
app
for
our
system
is
much
more
interested
in
doing
a
ci
extension,
because
it
can
they
can
link
the
systems
in
meaningful
ways.
Interestingly,
it
also
lets
technology
partners
develop
their
integrations
separate
from
us,
so
it's
not
going
in
the
core,
so
they
don't
have
to
spend
a
whole
lot
of
time,
interacting
and
waiting
on
much
longer
development
cycles
than
if
we
simply
guide
them
on
building
some
ci.
A
The
also
the
formalization
the
dependency
model
and
at
least
one
initial
seed
market
play
a
critical
role
in
scaling
integration
without
scaling
costs
and
head
counts,
so
sharing
paste
copy
paste
code
is
expensive
for
our
partners
and
for
us
when
it
comes
time
to
support
it.
It's
also
the
equivalent
of
forking
code,
so
having
this
kind
of
model
seems
to
be
essential
part
of
being
able
to
scale
this
up
without
having
a
lot
of
human
interaction
at
the
support
level.
The
documentation
level
also
integration,
reliability
expectations
are
disproportionately
important
for
technology
partnership.
A
So
let's
say
you
could
say:
well
you
know
what
we
don't
need
to
develop
a
dependency
model
or
make
sure
that
isolation
of
the
ci
is
possible
because
we
can
get
around
it
with
these
things.
It
would
still
be
very
important,
a
technology
partnership
that
these
integration
capabilities
are
provided,
because
it's
going
to
make
it
much
more
challenging
if
there's
not
a
solid
model
to
base
that
integration
on
we're
not
going
to
be
able
to
basically
share
governance
of
the
code.
A
It's
important
that
we
can
make
the
person
providing
the
code
or
the
organization
providing
the
code
as
responsible
as
possible
for
keeping
it
in
a
working
state.
So
running.
Automated
tests
on
their
side
are
on
our
side,
paying
attention
when
they
fail
also
updating
their
code
when
they
have
new
features
or
breaking
changes
so
that
their
glue
code
will
keep
working.
So
I
would
make
the
the
the
case
that
this
is
even
more
important
for
technology
partnership
to
really
scale
and,
of
course,
that
affects
ecosystem.
A
So
all
this
is
interesting,
but
there's
still
some
questions
that
emerge
to
think
about
to
talk
about
to
resolve
and
so
just
to
poke
through
those
what
other
major
characteristics
might
there
be.
So
this
is
just
in
my
experience.
What
characteristics
do
I
see
happening
again
and
again
and
again,
as
the
same
problem
is
approached
again
and
again
and
again,
which
of
the
sharing
model,
sharing
maturity.
Model
characteristics
that
were
presented
are
necessary
or
required
to
achieve
marketplace
effects,
so
are
they
all
necessary?
If
so,
which
ones
are
any
of
the
sharing
model?
A
So
if
you
think
about
going
and
buying
something
personally,
if
the,
if
it
comes
to
you
in
an
unexpected
situation,
I
don't
know
you're
you're
you're
in
a
context
where
you're
not
thinking
about
buying
anything
in
the
first
place,
then
you
aren't
as
open
to
it.
So
are
there
expectations
of
a
componentry
marketplace
that
we
need
to
adhere
to
for
rapid
adoption,
regardless
of
whether
they're
technically
required
or
not
one
of
the
things
is
recognition
of
trustability
characteristics?
So
you
know
you
go
to
a
big
box
store
with
a
big
brand
name.
A
You
trust
it
and
you
therefore
use
it
are
more
inclined
to
use
it
and
trust
it
and,
interestingly,
in
a
marketplace
whether
it's
ci
components
or
anything,
trustability
and
trust
are
really
important
characteristics.
So
we
have
to
be
aware
of
the
human
characteristics
that
might
dictate
a
given
way
of
modeling
this
out.
That
is
not
too
novel
away
from
what
they
would
expect
in
order
to
trust
it.
A
Are
there
any
sequencing
concerns
for
building
these
characteristics,
so
should
they
be
built
in
a
certain
way?
Is
there
certain
things
that
must
be
in
place
for
another
characteristic
to
exhibit?
If
we're
not
careful,
we
start
mvc'ing
all
over
the
place.
We
might
get
these
at
a
sequence
and
have
unnecessary
delays
in
getting
to
the
end
state.
That's
desired.
A
I
just
wanted
to
get
together
some
of
these
thoughts
of
repeating
patterns
that
I
seem
to
see
in
working
with
devops
and
packaging
again
and
again,
and
I
just
wanted
to
share
those
with
everyone
as
possible
considerations,
as
we
move
forward
with
ideas
about
how
ci
should
look
in
the
coming
year.
Thank
you.