►
From YouTube: Meltano Group Conversation (Public Livestream)
A
B
Some
would
say
that
I've
always
been
with
meltano,
so
I've
been.
You
know.
I've
been
at
gitlab
for
three
years
at
this
point
over
three
years.
At
this
point
and
when
I
joined
meltano
was
in
its
very
early
days,
it
was
called
the
bizops
project
and
the
data
team
and
the
multana
team
worked
very
closely.
B
B
So
I'm
super
excited
to
to
jump
over
to
to
bring
the
the
data
perspective,
because
I
helped
build
the
the
data
team
here,
get
lab
to
bring
that
perspective
and
kind
of
the
open
source
connections
as
well
to
the
team,
and
I'm
super
excited
about
like
what
we're
trying
to
build
and
the
direction
that
we're
heading
so
and
it's
kind
of
the
best
of
both
worlds.
For
me,
I
get
this.
You
know
we're
we're
within
git
lab.
B
A
Thanks
yeah,
obviously
we're
super
happy
to
have
taylor
on
board.
The
community
has
been
really
happy
as
well.
I
think
the
post
for
you
announced
you're
joining
in
the
slack
community,
got
close
to
40
emoji
reactions,
which
is
much
more
than
our
regular
releases.
Get
but
you're,
not
the
only
one
who
just
joined
aj.
Are
you
attending?
Would
you
like
to
yeah
perfect?
So
what
brought
you
to
montana
yeah.
A
C
C
Everyone
was
taking
some
existing
tap
from
somewhere
else,
cloning,
it
and
then
making
it
their
own
by
you
know,
re
rehashing
through
and
and
the
problem
with
that
is
that,
depending
on
where
you
grafted
in
you
may
or
may
not
have
support
for
certain
features
you
might
have
inherited
bugs
it
just
didn't
seem
like
the
right
way
for
people
to
develop.
So
in
conversation
with
dallas,
we
just
decided,
hey,
there's
got
to
be
a
better
way
and-
and
my
drive
was
how
do
I,
how
do
I
make
it?
C
So
people
have
less
code,
they
need
to
write
and
and
with
less
code.
If
you
can
do
more,
not
only
can
you
deliver
faster
and
have
less
to
maintain,
but
also
in
the
long
run
we
can
add
features
outside
of
your
code
base
that
you
can
just
naturally
inherit,
and
I
think
that
can
be
very
powerful
for
the
future
of
the
ecosystem.
C
We
had
two
or
three
organic
taps
built
and
I
got
confirmation
from
each
of
these
individuals
that
they
had
their
taps
working
in
a
matter
of
a
day
or
two
on
an
sdk.
That's
definitely
not
ready,
but
it
just
shows
that
that
we
have
something
really
really
powerful
here
and
there's
a
lot
of
interest
in
in
people
being
able
to
develop
on
this
sdk.
C
I
guess
one
other
thing
I'll
add
is
that
there
are
public
sources
and
they're,
also
private
sources,
one
individual
who
said
that
he's
developing
for
these
back-end
systems,
but
he
doesn't
want
to
build
the
whole
thing
and
end
so
he's
never
going
to
publish
this
tap
that
he
made,
because
it's
not
that
kind
of
a
source,
but
he
has
another
one.
That
was
a
public
source
and
he
so
he
actually
is
doing
on
both
sides.
C
B
Just
highlight
how
the
values
of
gitlab,
like
are
evident
in
this
little
project,
we're
showing
transparency.
You
know
we're
working
out
in
public
people
are
finding
this
stuff
and
small
iterations
are
going
to
help
us
kind
of
build
this
community
as
quick
as
possible,
because
we're
already
getting
feedback
even
before
it's.
You
know
officially
ready.
So
I
think
the
the
values
alignment
is
very
strong
with
multano
as
well.
A
Yeah
and
I'm
gonna
ask
a
question
about
that
to
you
aj,
because
the
fact
that
these
people
have
already
started
using
the
sdk
and
they're
actually
finding
success
with
it
means
it
might
be
more
ready
than
we're
giving
it.
You
know
we're
calling
it
right
now.
So
when
do
you
think
we
can
actually
officially
launch
that
v010
and
what
is
still
kind
of
blocking
us
from
doing
that,
because
I
know
there's
a
couple
of
things.
C
Yeah,
my
biggest
focus
is
just
to
reduce
the
amount
of
rework
somebody
does
if,
if
they
jump
onto
the
tap-
and
then
we
upgrade
it
later
so
so
I
I
do
think
we'll
we'll
hammer
that
out
in
the
next
in
the
next
two
weeks,
and
possibly
possibly
sooner
than
that,
but
certainly
by
end
of
month.
We
want
to
get
this
out
as
quickly
as
we
can
and
if
not
for
the
onboarding
process.
C
I
would
have
just
been
single-mindedly
focused
on
that,
but
I
I
am
onboarding
the
gitlab
and
we're
doing
some
really
good
vision.
Work
as
well.
That's
important
for
me
to
prioritize
so
but
yeah,
I
imagine
in
the
next
week
or
two
we
should
be
ready
to.
We
should
be
very
close,
and
certainly
by
end
of
months.
A
Well,
to
be
clear,
I'm
going
to
throw
the
question
to
taylor,
but
just
to
answer
a
little
bit
of
what
can
we
start
talking
to
customers
about
gitlab
is
not
officially
supporting
or
selling
multano,
so
the
expectation
on
the
customer
side
needs
to
be
really
clear
that
it's
just
an
open
source
project
that
we
are
interested
in
no
guarantees
beyond
that
but
taylor.
What
are
we
planning
to
do
over
the
next
six
months?.
B
So
the
sdk
is
a
big
part
of
the
effort,
so
that
people
have
an
easy
way
to
to
build
taps
and
kind
of
the
right
way
quote-unquote
to
the
spec
to
get
all
those
nice
features
we're
also
looking
at
the
singer
hub,
which
is
going
to
be
kind
of
a
pseudo-centralized
repository
and
listing
of
all
the
available
taps
and
targets,
and
we're
talking
right
now
about.
What's
the
the
validation
framework,
I'm
going
to
look
like
for
that.
B
So
folks
can
come
to
the
singer
hub,
see
different
variants
of
a
tap
and
target
and
have
an
understanding
of
whether
it's
validated
whether
it
works,
and
we
want
to
do
that
in
a
way
that
brings
in
the
community
and
it's
kind
of
decentralized
and
allows
anybody
to
contribute
to
that
and,
of
course,
just
kind
of
making
the
platform
even
better.
One
of
my
onboarding
tasks
is
to
spin
up
meltano
for
meltano,
so
we
have.
B
I've
got
a
separate
snowflake
instance
we're
starting
to
pull
in
starting
with
gitlab
data,
but
we've
got
you
know
different
data
sources
that
we
want
to
pull
in
and
so
in
the
course
of
doing
that,
I'm
finding
small
bugs
that
we're
gonna,
you
know
continue
to
patch
and
maintain,
but
but
the
initial
focus
really
is
on
building
community
driving
users
to
this
and
building
that
excitement.
For
this
you
know
data
focused
dev,
first
tool,
anything
I
missed
there.
Devo.
A
You
know
ways
of
doing
that
and
then,
like
taylor,
said
on
the
side
of
things
we're
doing
for
singer.
The
singer.
Sdk
is
a
big
effort
to
singer
hub
as
well
to
be
clear.
The
hub
itself
will
be
a
centralized
place
that
will
catalog
all
of
the
depths
and
targets
out
there
in
existence
that
are
currently
kind
of
scattered
around
git
repos.
A
But
the
actual
maintenance
of
these
steps
and
targets
will
remain
decentralized
because
we
see
them
as
individual
open
source
projects,
but
through
the
sdk
and
through
this
this
validation
framework
we're
working
on
there
will
be
a
standardized
set
of
test,
suites,
ci,
cd
pipelines,
etc.
That
can
run
in
all
of
these
projects
so
that
they
can
all
have
a
high
level
of
confidence
with
regards
to
you
know
the
quality
of
the
taps
and
the
extent
to
which
they
implement
the
singer
specification.
A
A
Does
that
answer
your
question
russell?
Yes,
very
much,
awesome
cool
next
question:
who
are
the
major
competitors
in
the
space?
What
makes
moltano
stand
out
in
this
space?
Another
question
from
russ:
well,
major
competitors
are
all
of
their
kind
of
legacy.
Established
data
integration,
el
tools-
you
know
talent,
matillion,
you
got
five
trend.
You
got
stitch
data
singer.
Of
course
itself
is
not
a
competitor,
but
it
is
a
an
effort
on
open
source
data.
Integration.
A
There
are
some
other
companies
playing
around
with
that
now,
but
singer
is
by
far
the
most
established
and
fastest
growing,
most
traction
having
open
source
data
connector
option
in
the
in
the
space
right
now
and
meltdown,
and
we
are
very
much
betting
on
the
community
there
great.
Thank
you
cool,
michael.
B
A
Yeah,
I
mean
one
of
the
things
that
that
I
was
honestly
a
little
bit
surprised
by
is
that
amazing
people
like
taylor
and
aj
got
so
excited
about
this
project
that
they
decided
to.
You
know
give
up
their
their
great.
You
know
jobs
to
come
over
to
this
project.
At
the
same
time,
I've
just
been
pleasantly
surprised
by
the
attraction
that
singer
has
continued
to
have,
even
though
some
of
the
kind
of
community
support
and
tooling
has
not
been
quite
where
we
think
it
should
be.
A
And
of
course
that's
what
we're
trying
to
change,
but
we
are
seeing
a
lot
of
people
coming
out
of
the
woodworks
working
at
data,
consulting
firms
that
have
adopted
singer
over
the
last
couple
years
to
as
a
standard
for
building
these
custom
connectors
for
sources
that
are
not
served
by
the
hosted
el
platforms
for
their
clients.
A
lot
of
them
started
using
singer
and
they
have
also
kind
of
identified.
A
This
need
to
have
a
better
tool
set
for
billing
and
maintaining
these
steps
for
running
them
in
production
and,
at
the
same
time,
I've
seen
that
a
lot
of
companies
building
data
products,
data
platforms
that
do
something
with
data,
often
related
to
specific
niches,
have
actually
started
using
singer
for
the
internal
data
integration
functionality
inside
those
platforms.
Because,
of
course
you
know
it's
great,
it's
the
standard.
A
It's
you
can
build
all
of
your
connectors
using
it
and
then
run
them
inside
your
platform
and
your
users
don't
need
to
know
what's
running
inside,
and
these
are
also
coming
over
to
montana
and
starting
to
use
it
as
that
engine,
so
that
they're
not
reinventing
the
wheel
for
for
running
those
and
what
else
yeah.
That's
the
first
couple,
things
that
come
to
mind,
taylor
and
aj
any
more
thoughts
you
want
to
add,
since
you've
also
been
involved
with
the
community
for
the
last
six
months.
B
But
it's
a
messaging
focus
on
we're,
going
to
focus
on
extract
and
load
and
we're
going
to
target
the
singer
community,
and
it
really
gets
people
excited
about
the
specific
thing
that
the
tool
can
do
well,
even
if
the
broader
vision
hasn't
really
changed
that
much,
but
it's
yeah.
So
I've
just
been
impressed
by
the
the
growth
of
this
project
with
just
one
person
dao
on
it.
For
you
know
almost
an
entire
year
there
is
excitement
in
the
community.
B
I'm
heavily
involved
in
the
dbt
community,
which
is
the
data
build
tool
which
manages
transformations
in
the
warehouse
and
one
of
the
common
questions.
Actually
is
people
are
getting
spun
up
with
with
it
and
they're
like
hey,
can?
Can
I
use
dbt
to
move
my
data
and
that's
not
something
that
they're
they're
focused
on
so
yeah?
B
You
know,
extract
and
load
is
kind
of
the
first
step
to
centralize
your
data
to
power,
an
analytics
function
within
an
organization
yeah,
just
yeah,
the
the
excitement
around
it
and
the
clear
need
and
the
fact
that,
like
open
doing
this
in
an
open
source
way
hasn't
been
done
before
we're
still
like
early
in
kind
of
this
whole
data
transformation.
So.
A
A
I
post
published
that
blog
post
on
may
13th
the
product
hadn't
changed
at
all,
like
the
the
actual
code
page
need
to
make
any
changes,
but
just
by
positioning
it
totally
differently.
Changing
up
the
whole
website,
focusing
on
the
cli
and
the
el
bits
more
than
the
ui
and
the
intent
aspect
immediately
made
it
take
off
the
singer.
A
We
would
have
done
if
we
had
been
focusing
on
el
already,
but
I
was
very
surprised
to
see
and
impressively
surprised,
of
course,
to
see
the
appetite
for
tooling
like
this,
that
existed
in
singer
and
the
fact
that
they
were
really
just
waiting
for
someone
to
start
taking
them
seriously
and
and
they
were
happy
to
to
engage
so.
The
community
has
just
been
really
really
awesome.
C
C
Part
sorry
yeah
for
dbt
for
transformations
but
yeah
for
for
the
el
part
and
everything
else,
there's
not
a
thorough
vision
of
how
do
you
build
a
devops
friendly
data
platform
and-
and
you
know,
gitlab
folks
are
probably
familiar
with
ci
cd
and
all
of
that
stuff.
A
lot
of
data
people
are
not
it's
new
and
scary
to
them.
So
what
I
see
is
when
people
try
it,
they
never
want
to
go
back
and
anyone
can
learn
it.
C
It's
just
kind
of
a
question
of
of
how
to
do
that,
and
you
know,
git
lab
being
focused
on
handbook
first
and
everything's
in
mr
is,
is
like
exactly
what
we're
trying
to
do
in
the
data
community
for
a
community.
That's,
what's
git,
why
do
I
need
git,
and-
and
so
I
think,
just
the
awareness,
the
community-
I
see
in
the
community
that
there's
an
appetite
for
this
thing-
that's
like
still
scary,
but
notably
important
yeah.
I
think
it's.
B
A
Yeah,
something
I
was
going
to
add
is
that
something
that
aj
just
made
me
think
of
is
that
I've
also
been
pleasantly
surprised
to
see
interest
from
kind
of
the
education
sector
or
the
sector
of
people
brand
new
to
data
science
needing
to
kind
of
learn
their
first
data
stack
and
the
fact
that,
of
course,
in
in
these
programs
data
science
programs,
they
are
more
likely
to
be
using
open
source
or
free
tools.
Instead
of
telling
all
of
their.
A
So
one
particular
community
member-
and
he
is
called
out
in
the
in
the
group.
Conversation
slides
as
well
is
andrew
stewart,
who
is
a
lecturer
at
johns
hopkins
university
in
their
interactive
data
science
course
and
I'll
have
to
check
in
with
him
what
the
status
and
this
is,
but
he
has
been
publishing
this,
this
blog
post
series
about
these
three
tools
I
just
mentioned,
and
he
mentioned
that
he
was
potentially
planning
to
make
that
part
of
the
curriculum
for
the
intro
to
data
science
course
at
johns
hopkins
university.
A
So
I
hope
I'm
not
jinxing
it
by
by
by
saying
this
now,
but
that
would
be
amazing-
and
this
is
really
cool-
to
see
that
yeah,
these
open
source,
tooling,
that
that
allow
you
to
kind
of
get
used
to
how
to
do
data
in
this
devops
way
of
thinking,
version
control,
ci,
cd,
that
really
resonates
and
it
is
becoming
how
new
people
new
to
data
are
starting
to
learn
it
they're
not
gonna.
Okay,
buy
these
five
tools
and
learn
their
uis.
A
E
B
Oh,
my
gosh
that
so
I
don't
know,
I
honestly
don't
know
if
I'm
the
right
person
for
this,
because
I'm
such
a
proponent
of
not
doing
data
science
and
like
true
you
know,
predictive
stuff
until
you've
got
your
house
in
order
with
good,
descriptive
analytics.
That
said,
I
think
having
that
that
artifact
of
that
asset
management,
view
kind
of
as
a
first
class
citizen
is
a
big
component
of
this,
and
so
there's
there's
a
whole
kind
of
workflow
orchestration
around
and
that's
all
code
of
what
are
you?
What
are
you
building?
B
How
are
you
training
your
model,
but
at
the
end
of
the
day
you
do
have
some
artifact,
whether
it's
like
some
pickled
model
or
something
that
comes
out
and
so
having
good
support
for,
like
an
artifact
repository,
I
think,
seems
to
make
sense.
But
I
would
need
to
spend
more
time
thinking
about
that
space
yeah
before
I
could
give
a
better
answer.
C
Yeah,
I
do
want
to
just
jump
in
on
one
thing,
so
I've
been
as
I've
worked
with
ml
teams.
I
I
do
hear
the
feedback
that
maybe
80
of
what
they're
doing
is
data
transformation
and
in
many
cases
the
transformations
are
done
in
with
tooling
that's,
maybe
subpar
and
with
sometimes
development
practices
that
are
not
ideal,
like
a
jupiter
notebook
that
just
grows
and
grows
and
grows
and
grows
and
grows.
But
you
don't
know
if
you
have
reproducibility
when
it
finally
works.
C
So
I
I
it's
not
a
solve,
but
I
think
that
that
meeting
in
the
middle
will
require
us
to
have
a
common
language
for
that
transformation.
Piece
are
ml
people
going
to
go
all
in
on
dbt,
I
don't
know,
are
the
tooling
for
on
the
ml
side,
just
going
to
get
better,
so
data
transformation
isn't
as
much
of
a
challenge
proportionately
in
the
ml
pos
up
problems,
and
I
I
think,
where
that
answer
comes
out,
will
help
us
determine
how
we
meet
in
the
middle.
That's
those
are
my
thoughts.
E
That's
super
interesting.
I
think
what
I
heard
earlier
as
well
is
like
hey
the
first
introduction
of
devops
to
data.
People
is
ddt.
Dbt
is
a
standard
all
the
rest
in
ml.
Ai
is
like
all
the
way
from
queue
flow
to
tensorflow
to
pi.
Something
like
it
has
everything.
So
maybe
dbt
is
our
ticket
in.
Maybe
maybe
we
should
focus
on
the
transform,
even
though
it
goes
under
a
monologue
spanner.
Is
that
what
you're
hinting
at.