►
From YouTube: Securing Critical Projects WG (September 10, 2020)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
Problem:
okay:
back
in
2014,
the
core
infrastructure
initiative
was
kicked
off
to
identify
critical
projects
and
try
to
help
them
out
in
some
way.
I
was
asked
to
do
a
quick
run,
and
so
I
had
done
an
early
survey
which
we
called
the
cii
census,
one
for
lack
for,
because
there
was
perception
that
speed
was
important.
A
We
focused
on
linux
distro
packages,
but
obviously
that
leaves
out
a
huge
number
of
packages
that
are
downloaded
and
installed
via
language
level,
package
managers
and
so
more
recently,
harvard
was
asked
to
take
a
look,
and
we
actually
did
do
some
early
research
into
how
to
use
dependency
data
to
try
to
identify
important
language
level
packages.
A
Linux
foundation
then
asked
harvard
to
go
ahead
and
drill
down
that
further,
harvard
basically
took
two
things:
they
did
use
dependency
data,
but
they
also
went
out
and
contacted
sca
vendors
and
through
a
lot
of
effort,
to
try
to
get
that
data
which
was
painful
and
hard.
They
came
up
with
some
interesting
results,
so
the
the
key
people
that
are
gonna,
be
speaking
today
are
frank,
nagle,
say,
hi,
frank,
hello
and
jenny,
hoffman
you're
there
hey
there.
A
We
go
okay,
so
please
take
it
away.
Well,
actually,
I'm
sorry
kim
first
step
at
titty
woods,
I'm
sorry!
I
just
started
getting.
I
got
into
the
role,
but
this
is
your
meeting.
So
do
you
want
us
to
just
go
into
that.
D
Great,
so
yes,
so
thanks
so
much
david
gave
a
good
background
there
and
today
I'll
give
a
an
overview
of
kind
of
where
we
are
and
where
we're
planning
on
heading
and
and
I'll
have
I'll
throw
a
deck
up
here.
But
this
is
mostly
just
to
kind
of
make
sure
we
don't.
D
You
know,
don't
miss
anything
and
so
obviously
feel
free
to
jump
in
and
ask
any
questions
along
the
way,
because
we
consider
this
more
of
a
conversation
than
just
kind
of
a
straight
up
presentation.
So
my
name's
frank
nagle,
I'm
a
professor
at
harvard
business
school.
My
background
is
actually
in
cyber
security.
D
I
worked
in
the
industry
for
about
a
decade
before
going
back
into
the
academic
world,
and
now
I
study
crowdsourcing
in
particular,
open
source
software
and
how
companies
interact
with
these
types
of
communities.
Also,
as
david
mentioned,
is
jenny
hoffman,
who
is
I'll
savor
the
trouble
of
taking
herself
off
mute,
but
she
works
at
the
laboratory
for
innovation
science
at
harvard,
which
is
a
group.
D
That's
essentially
a
research
laboratory
that
studies,
a
variety
of
topics,
but
one
of
them
in
particular,
is
crowds
and
communities,
and
so
she-
and
I
have
been
working
closely
on
this
for
the
last
as
david
pointed
out
about
a
year
and
a
half
or
so,
and
we'll
kind
of
go
through,
and
jenny
obviously
feel
free
to
jump
in
if
I
misspeak
or
or
misstate
anything
so
so
yeah.
D
So
as
david
mentioned,
the
early
kind
of
projects
that
the
the
first
version
of
this
was
the
census
1.0,
which
they,
you
know,
kind
of,
took
and
started
looking
at
kind
of
the
most
critical
packages
and
and
how
packages
are
used
throughout
the
the
linux
environment
and
the
goal
of
the
census
or
one
of
the
goals
in
census.
2
was
to
take
a
broader
picture
of
of
open
source
and
and
be
as
broad
as
possible.
D
So
along
those
lines,
just
to
kind
of
you
know
anchor
ourselves
on
what
the
project
is
trying
to
do.
We're
really
trying
to
understand
three
aspects
of
of
free
and
open
source
software,
so
the
first
is
the
prevalence
which
the
census
is
really.
You
know,
though,
the
primary
venue
or
avenue
for
for
attempting
to
do
that.
D
The
second
which
we'll
talk
about
a
survey
that
we've
been
running
as
well
kind
of
after
we
talk
about
the
the
census
stuff
and
so
the
impact
you
know
we're
thinking
about
the
criticality
of
various
pieces
of
open
source
source,
but
in
kind
of
how
it's
used,
but
also
in
kind
of
its
economic
impact
and
then
as
a
piece
of
that.
We're
also
thinking
about
how
we
prioritize
open
source
efforts
to
address
security
vulnerabilities.
D
So
some
of
you
may
have
seen-
or
you
may
have
talked
about
the
the
the
eu
or
the
the
european
commission
kind
of
set
up
a
bug,
bounty
program
for
open
source,
but
the
way
that
they
decided,
which
you
know
how
to
target
what
pieces
of
open
source
was
really
just
based
on
what
the
european
commission
used
themselves.
So
we're
trying
to
give
some
guidance
to
you
know
the
eu.
The
us
government
is
interested
in
this
and
then
of
course,
organizations
like
the
ossf
that
are
interested
in
supporting
open
source.
D
We're
really
trying
to
help
kind
of
give
a
a
prioritized
list.
Based
on
at
least
one
measure
of
impact
and
importance
to
you
know
to
the
world
essentially
and
then
lastly,
we're
also
trying
to
think
about
endurance
and
and
how
you
know
open
source
is
not
developed
in
a
vacuum.
It's
created
by
a
community
of
of
some
volunteers,
some
paid
people
and
you
know,
and
and
various
people,
with
different
incentives
and
and
different.
D
D
That
really
tries
to
look
at
kind
of
the
human
side
of
all
of
this,
and,
and
so
I'm
thinking
about
you
know
what
people
are
doing
now
in
terms
of
developing
open
source
and
how
we
can
help
them
kind
of
bake
in
norms
and
best
practices
from
you
know,
a
lot
of
the
things
we've
learned
from
from
kind
of
private
software
development
and
also
things
that
have
emerged
from
kind
of
bigger
projects.
D
You
know
like
linux
and
apache
and
the
various
larger
open
source
practices,
and
how
do
we
help
kind
of
the
smaller
projects
that
have
become
you
know
later
become
super
important.
How
do
we
help
them
bait
these
practices
in
from
the
beginning,
even
if
they're
small,
and
so
you
know,
and
david
mentioned
2014,
you
know
where
a
lot
of
these
efforts
from
linux
and
and
others
started.
You
know
I'm
sure,
we're
probably
all
familiar
with
heartbleed.
D
But
you
know,
one
of
the
interesting
things
here
is
that
that
was,
you
know
in
general
kind
of
a
fairly
small
project
with
a
small
number
of
contributors,
and
it
just
became
super
important
right.
D
Openssl
became
super
important
and
critical,
and
so
you
know
how
do
we
kind
of
identify
these
projects
that
are,
you
know
core
to
the
the
underpinnings
of
the
internet,
really
the
modern
economy
and
provide
the
support
both
in
terms
of
technical
but
also
kind
of
social
and
other
things
like
that
that
they
really
need,
and
so
you
know,
how
are
we
doing
this?
D
You
know,
as
I
mentioned
I'll
talk
kind
of
first
about
the
sca's,
so
as
mentioned
in
the
chat,
sca
can
stand
for
either
software
composition,
analysis
or
source
code
analysis
essentially
kind
of
the
same
thing,
but
what
these
companies
do
is
essentially
go
into
client
companies
and
analyze
the
code
that
they're
using
for
a
variety
of
reasons.
D
Sometimes
it's
for
you
know
picking
up
potential
vulnerabilities,
but
often
it's
about
license
violations
right,
so
ensuring
that
you
know
when
a
company
is
building
its
own
proprietary
code,
they're,
not
violating
any
open
source
licenses
or
other
types
of
licenses
in
the
software
that
they're
building,
and
so
these
sca's
are
a
useful
place
for
us
to
start
because
they
have
insights
into
what
thousands
of
companies
are
are
using
in
their
software
and
so
we
kind
of
started
by
working
with
them
because
they're,
you
know,
I
wouldn't
call
them
gatekeepers,
but
they're.
D
Essentially,
by
tapping
into
them.
We
get
insights
into
what
thousands
of
companies
are
doing
without
needing
to
talk
directly
to
all
those
thousands
of
often
smaller,
but
sometimes
bigger
companies,
and
so
we
can
really
see
you
know
kind
of
this.
This
broad
view
of
broad
and
deep
view
of
what's
being
used
in
terms
of
open
source.
So
yes,
so
that's
kind
of
what
you
know.
D
The
this
census
2
is
based
around
is:
is
working
with
these
scas
to
see
what
types
of
open
source
software
their
you
know,
their
clients
use,
and
these
are
kind
of
global
companies
and
global
clients.
And
so
we
have
you
know.
D
Our
goal
is
to
really
take
this
to
a
very
broad
kind
of
definition
of
open
source
and
also
a
broad
measure
of
kind
of
the
use
of
open
source,
and
so
with
this
project
you
know
one
of
the
the
our
goal
is
not
to
have
this
just
be
kind
of
a
one-time
thing
and
just
kind
of
say.
D
You
know
this
is
the
state
of
the
world
at
the
moment,
but
actually
have
it
be
something
that
is
updated
on
kind
of
a
yearly
basis,
in
a
way
that
you
know,
maintains
the
privacy
and-
and
you
know,
protects
the
customers
of
these
scas,
but
at
the
same
time
allows
us
to
aggregate
this
data
in
a
way
that
would
be
useful,
for
you
know,
identifying
and
prioritizing
investments
and
also
for
kind
of
research
purposes
right
so
to
better
understand.
D
And
things
like
that
and
so
I'll
pause
in
just
a
second
to
see
if
there's
any
questions,
but
before
I
do
that,
I
just
want
to
mention
that
you
know
our
first
effort
from
this
was
released
back
in
february
before
you
know
the
world
kind
of
went
sideways,
but
we
released
what
we
called
a
preliminary
report,
because
our
plan
is
to
release
much
more
detailed
information,
but
we
wanted
to
put
something
out
to
kind
of
show
what
we
had
found
already
and
this
this
report's
publicly
available
at
that
url
jenny.
D
I
don't
know
if
you
want
to
throw
it
or
throw
it
into
the
chat,
so
folks
can
take
a
look
at
it,
but
I'll
just
highlight
a
couple
of
the
the
major
findings
right.
So
so
the
first
was
you
know
these
are
some
of
the
most
widely
used
packages
across.
You
know
the
the
data
that
we
were
seeing
from
these
from
these
scas
and
we
did
find
that
you
know
perhaps
surprisingly
javascript
kind
of
dominated
a
lot
of
what
we
were
seeing.
D
So
we
decided
to
release
kind
of
two
top
ten
lists.
One
is
of
everything
and
one
is
of
non-javascript
right
so
because
again,
javascript
kind
of
dominated
it,
which
is
important
for
us
to
know
and
understand,
but
we
also
wanted
to
make
sure
we
kind
of
gave
a
broader
view
into
what
else
is
being
used
besides
javascript.
D
D
We
also
thought
about
you
know
we
came
to
some
kind
of
high
level
findings
around
from
from
the
work
that
we
did
as
well,
and
so
for
that
you
know
a
couple
of
these
high-level
findings
that
we
that
we
really
you
know
kind
of
bubbled
to
the
surface.
While
we
were
doing
that
and
the
first,
which
you
know,
I'm
sure
everybody
has
come
across
at
some
point
in
their
experiences,
but
is
inconsistent
naming
right.
D
So
you
know
even
as
we're
talking
to
all
these
different
sca,
vendors
and
and
aggregating
all
this
data.
It
was
no
small
feat
to
to
actually
figure
out.
Okay,
you
know
async
by
from
this
vendor.
D
It
means
async,
slash
whatever
from
this
vendor
and
kind
of
you
know,
and
and
standardizing
these
or
this
inconsistent
naming
is
certainly
something
that
you
know
is
not
only
just
a
kind
of
you
know
an
accounting
type
of
problem,
but
it
actually
am
also
a
serious
problem
from
a
security
standpoint,
given
that,
if
you
don't
know
what
packages
you
have,
how
can
you
know
you
know
when
you
need
to
update
stuff,
and
so
that
was
one
of
the
high
level
findings
that
we
discussed
in
the
report.
D
The
second
is
that
a
lot
of
these
projects
that
you
know
again
bubble
to
the
surface
is
super
highly
used
are
hosted
under
individual
developer
accounts
on
github
or
in
other
places,
and
so
you
know
the
top
ten
most
used
packages.
Seven
of
them
were
actually
hosted
under
individual
dev
accounts,
and
so
there
you
know,
there's
a
couple
concerns.
D
One
security
measures
may
not
be
quite
as
stringent
as
kind
of
project
level
accounts
and
then
also,
of
course,
you
know,
we
always
have
the
the
fear
that
somebody
gets
run
over
by
a
bus
and
then
the
whole
project
falls
apart
because
it's
all
hosted
under
an
individual
account.
So
that
was
another
thing
that
was
a
bit
of
a
surprise,
perhaps
more
so
than
the
first
finding.
D
But
certainly
something
that
you
know
is
is
a
concern
going
forward
and
then
lastly,
you
know
again:
this
is
something
that
you
know.
D
We
all
know
is
a
problem,
but
actually
is
something
that
we're
able
to
to
quantify
here
so
legacy
software
is
you
know,
alive
and
and
well,
perhaps
not
well,
but
is
alive
and
widely
used
within
companies
and
the
software
that
they're
developing,
and
so
this
has
a
variety
of
security
concerns,
but
also
can
lead
to
you
know
time
and
money
costs
you
know
from
from
associated
to
switching
away
from
this
kind
of
legacy,
tech,
and
so
thinking
about
that
and
really
not
only
thinking
about
it
but
actually
being
able
to
quantify.
D
You
know
what's
going
on
there
and
in
this
preliminary
report
we
didn't
quite
have
the
ability
to,
in
this
first
pass
for
a
couple
reasons
to
identify
the
actual
versions
of
the
packages
that
are
being
used,
but
now
that
we
have
more
sca's
involved,
our
hope
for
our
next
version,
and
that
kind
of
brings
me
to
you
know
the
the
next
steps
for
this.
D
Our
hope
is
that
we'll
be
able
to
kind
of
release
a
bit
more
information
about
actually
version
level
package
information,
because
that
is
pretty
important,
so
also
kind
of
not
only
just
think
about
you
know.
What
do
we
need
to
do
to
to
update
the
most
recent
versions
of
the
software?
But
where
are
the
packages
that
are?
You
know
widely
used,
but
are
mostly
kind
of
these
legacy
versions,
and
so
we
should
be
encouraging
people
to
you
know
to
update
those
ones
in
particular,
because
they're
so
widely
used.
D
So
the
next
steps
here
on
this
are
thinking
about
you
know
bringing
in
more
sca
which,
as
I
mentioned,
we've
already
started
to
do
when
we
have
more
than
the
last
when
we
released
that
preliminary
report
and
then
also
we're
doing
some
network
analysis
on
to
layer
on
top
of
this,
so
that
we
can
think
about
not
only
kind
of
the
importance
based
on
usage,
but
also
the
importance
based
on
you
know.
D
What
are
the
packages
that
every
other
package
builds
on
across
the
open
source
ecosystem,
and
so
how
do
we
think
about
kind
of
weighting,
those
as
important,
even
if
they're
not
necessarily
directly
used
themselves,
and
so
our
goal
is
to
release
an
updated
kind
of
report
in
february
2021.
D
That
gives
more
details
and
more
usage
data
that
can
be
both
used
for
research
purposes,
but
also,
as
I
mentioned,
for
better
targeting
in
security,
investments
and
other
types
of
investments
in
open
source,
and
so
I'll
also
mention
and
I'll
pause
for
for
for
any
questions
or
anything.
This
you
know
in
certain
pieces
of
the
world.
D
This
report,
you
know,
created
a
bit
of
a
buzz
in
terms
of
what
we
found,
and
our
hope
is
that
the
next
report
or
our
plan
is
that
the
next
report,
because
it'll
be
more
detailed
and
more
in-depth,
we'll
continue
to
create.
You
know
a
discussion
and
really
highlight
these
types
of
problems
that
you
know
that
we're
considering
with
the
census,
but
also
that
the
ossf
is
starting
to
focus
on
as
well.
So
I'll
pause
there
I'll
just
go
back
to
next
steps.
D
This
not
talk
for
so
long
and
let
people
jump
in
sooner
but
christina
go
ahead.
C
Yeah
so
I
recently
wrote
like
a
pretty
big
grant
proposal
for
the
python
software
foundation
to
get
someone
full-time
working
on,
see
python,
doing
like
kind
of
custodial
work
like
reviewing
pull
requests
and
triaging
issues,
and
all
that
and
on
this
list
I
only
saw
javascript
packages
and
things
that
look
like
java
packages.
So
I,
my
question
is
like
who
are
these
sdas
like
how
what
is
determined
to
be
an
open
source
package
like
what
about
open
source
packages
that
are
used
like
commercially
yeah?
D
And-
and
you
know,
one
of
the
things
with
both
java
and
javascript
is
that
often
the
the
packages
tend
to
be
smaller,
right
and,
and
you
know,
and
perhaps
in
python,
there's
larger
libraries
that
are
used
and
therefore
or
sorry,
the
opposite
and
that
that
that
can
kind
of
skew
the
the
weightings
right
and
that's
why?
D
Actually,
we
want
to
be
able
to
release
a
much
more
detailed
and
kind
of
lengthy
list
of
the
packages
be
for
exactly
that
reason,
because
there's
definitely
python
stuff
that
shows
up
in
you
know
say:
for
example,
one
of
the
things
we
focused
on
was
kind
of
the
top
200.
On
the
back
end
in
the
the
report,
we
only
ended
up
releasing
the
top
10.,
but
in
the
top
200
there's.
Definitely
some
python
packages
there
as
well-
and
I
think
that's
you
know
a
part.
D
A
couple
of
things
go
into
that
one
is,
you
know
just
who
the
the
sca's
customers
happen
to
be,
and
so
the
more
essay
seas
we
get
the
more
companies
we
will
see
and
the
broader
kind
of
breadth
of
you
know
this
we'll
see.
I'm
david,
if
I
recall
correctly,
you
had
a
couple
thoughts
on
that
back
when
we
put
the
report
out,
did
you
wanna
and
I
noticed
you're
off
mute,
so
I'm
gonna
cold
call
you
to
jump
in
one
minute.
A
I'm
happy
to
yeah.
We
had
done
some
preliminary
analysis
and
really
came
up
with
the
same
thing
and
if
you
read
the
report,
you
can
blame
me
because
I
pointed
out
to
harvard
the
the
same
kind
of
issue
that
we
had
identified.
I've
forgotten
the
exact
numbers,
but
something
like
half
of
all.
The
javascript
packages
have
zero
or
one
function
so
you're
talking
so
in
the
javascript
world.
A
It
tends
to
skew
when
you
start
counting
just
number
of
packages
that
other
packages
refer
to,
the
javascript
numbers
become
huge,
and
so,
in
fact,
in
the
report
they
separated
javascript
from
the
other
ones,
partly
because
of
that,
but
I
think
that's
also
fair
and
we
don't
have
as
much
insight
into
the
scas,
but
I
suspect
in
many
cases
when
the
seas
are
paid
to
do
an
evaluation.
A
It's
going
to
tend
to
be
things
like,
for
example,
a
larger
java
java
package,
say,
and
so
there's
going
to
be
some
emphasis
on
just
what
are
the
customers
paying
for
frank?
I
think
it
would
be
might
be
very
important
to
explain
why
you
need
a
third
sca,
because
you
have
two,
you
are
you
have
a
legal
agreement
for
a
third
though
the
data
hasn't
arrived.
Yet
that's.
E
D
That's
right,
so
so,
just
you
know
from
a
from
a
privacy
standpoint,
the
the
what
prevented
us
from
releasing
more
details
in
that
kind
of
first
preliminary
report
was
that
at
the
time
we
only
had
two
sca's
involved
and
obviously,
if
we
released
usage
statistics
that
were
the
aggregate
of
two
things,
then
both
of
those
companies
could
subtract
their
own
numbers
and
figure
out
information
about
their
competitor
right
and
so
we're
trying
to.
D
We
were
trying
to
avoid
that
from
happening,
and
now,
as
david
alluded
to,
we
have
a
third
signed
up
and-
and
you
know,
sign
all
the
paperwork
signed
and
we're
in
the
process
of
getting
their
data
as
well,
and
we
have
a
few
others
that
we've
been
talking
to
that
are
are
in
the
pipeline
as
well.
So
that
our
hope
is,
you
know,
come
january
1st.
D
So
we
can
get
a
dump
of
all
of
these
companies
data
for
the
year
the
calendar
year,
2020,
so
that
our
next
report,
we
can
release
more
details
because
any
individual
company
won't
be
able
to.
You
know,
subtract
out
their
own
numbers
and
then
and
and
figure
out
what
their
competitors
are
doing,
because.
E
D
Part
of
the
problem
with
this
is
you
know,
is
that
these
companies
are
all
competing
against
each
other,
and
this
is
you
know
to
some
of
them
this
this
even
just
this
usage
information
is
actually
very
important
to
you
know
to
their
business
model,
and
so
we
need
to
you
know,
be
respectful
of
the
fact
that
these
companies
are
are,
you
know,
basically
giving
us
their
some
of
the
for
some
of
them.
D
This
is
kind
of
their
crown
jewels
of
information
under
the
agreement
that
will
make
it
public,
but
that
we
will,
in
the
process
protect
their
their
clients.
First
of
all,
and
also
their
kind
of
you
know,
their
secrets
awesome
what's
going
into
it
from
that
perspective,
so
christina,
I
realized
that
was
kind
of
a
long-winded
answer
to
you
know
a
fairly
straightforward
question,
but
the
the
the
tighter
answer
is
in
the
more
detailed
report.
There
will
be.
D
You
know
a
broader
set
of
kind
of
languages
that
are
represented.
It
just
so
happens
in
these
current.
You
know
in
this
existing
analysis.
Those
were
the
ones
that
bubbled
to
the
top.
C
Yeah
I
mean
I'm
just
not
sure
like
what
role
a
report
like
this
would
play
in
identifying
critical
projects
like
I
find
the
conclusion,
like.
The
conclusion
that
I
am
drawing
from
this
is
that
a
package
that
has
two
lines
in
javascript
that
is
called
is
array
needs
like
will
get
resources
to
develop
that
functionality,
whereas,
like
literally
core
python,
like
the
python
programming
language,
is
not
on
this
list.
D
Yeah-
and
I
think
that's
you
know
the
the
the
report
and
in
the
report
itself,
we
talk
about
this
to
some
degree
and
I
think
it'll
be
even
more
so
in
the
next
report,
but
this
has
to
be
taken
in
context
right
and
so
you
know
is
array
like
okay.
That
might
be
widely
used,
but
you
know
we
can
with
a
little
bit
of
a
tiny
bit
of
effort.
D
We
can,
you
know,
say:
okay,
it
looks
fairly
secure
and
people
are,
you
know,
have
done
what
needs
to
be
done,
but
with
bigger
projects
you
know.
That's,
that's.
I
think
the
context
is
is
more
important
to
the
fact
that,
for
example,
python
is
you
know
much
more
white
or
perhaps
hard
to
say
what
more
widely
used
or
less
widely
used.
But
you
know
is,
is
a
different,
is
a
much
bigger
behemoth
and
therefore
may
require
more
resources
to
kind
of
addre.
You
know
address
these
types
of
concerns.
A
A
Is
somebody
takes
over
the
package
and
inserts
something
malicious
is
array
is
not
very
impressive
as
far
as
javascript
goes
on
the
other
in
terms
of
size,
and
nor
should
it
be,
and
you
wouldn't
expect
many
changes,
but
if
somebody
inserts
something
malicious
there
that
could
impact
an
incredibly
large
number
of
sites
around
the
world.
C
Well,
I
think
the
thing
you're
talking
about
too
is
like
not
a
technical
security
concern,
it's
just
social
engineering,
and
we
see
that
all
the
time
in
every
programming,
language
ecosystem
right,
like
an
unknown
developer,
approaches
a
package
maintainer
and
they're.
Like
hey,
add
me
as
a
maintainer.
They
push
some
commits
you're
pwned.
D
That's
right,
that's
right
and
and
but
to
you
know
to
be
to
to
just
to
be
more
clear
about
what
we're
attempting
to
do.
It
is
we're
attempting
to
take
a
pretty
broad
level
of
view
of
what
security
is
right.
So
it's
not
just
you
know.
Is
there
a
buffer
overflow
in
here
or
something
like
that
right,
but
is
there
you
know
the
so
the
you
know
the
the
bus
problem
right.
D
So
if
you
know
if,
if
the
main
developer
gets
run
over
and
nobody
else
has
you
know
access
to
the
to
the
repository,
then
you
know
then
we're
we
have
a
left
pad
situation
right
like
where
you
know
that
that
that's
a
problem
too
from
a
kind
of
different
angle
in
terms
of
security
right,
and
so
we
we
are
trying
to
take
a
a
rather
broad
view
of
security
or-
and
even
you
know
we'll
talk
about
the
survey
in
just
a
second,
but
from
that
like
if
people
just
stop
contributing
to
this
project
because
everybody
gets
bored
with
it,
but
it's
still
a
super
important
project.
D
Well,
that's
also
a
security.
You
know
kind
of
issue
and
and
in
a
different
way,
though
right
but
absolutely
that's,
you
know
a
piece
of
what
we're
looking
at.
B
And
real,
quick,
shameless
plug
on
that
last
item,
christina
there's,
another
working
group
in
the
ossf
called
the
developer
identity
working
group
that
is
focused
on
tackling
that
exact
problem,
because
it's
something
we're
all
worried
about.
I'll
drop.
The
link
to
that
one
in
here
as
well.
We
meet
next
week
excellent.
C
I
have
a
question:
that's
it's
a
little
bit
related,
but
just
and
more
of
a
high
level
like
how
do
you
work
with
these
sca's
like
is
that?
Are
you
paying
to
do
the
work?
One
of
our
goals
would
be
to
actually
get
more
updated.
Data,
like
you
mentioned,
you
know,
make
sure
it
gets
updated.
You
know
at
least
once
a
year,
but
if
we
wanted
to
even
keep
it
updated
more
real
time
like
I'm
just
thinking
out
loud,
you
know.
Are
they
using
like
standard
tool
sets?
Is
that
even
possible?
D
Yeah,
no
I'm
happy
to
talk
about
that.
I
mean
that
that
type
of
stuff
is
probably
not
in
the
report,
because
that
was
the
you
know
the
back
end
struggles
of
what
led
to
the
report,
but
yes,
so
structurally
that
we
are
not
paying
them.
They
are.
You
know
doing
this
for
basically
publicity
right,
so
we're
we're.
D
You
know
we
put
that
we
offer
them
the
opportunities
to
kind
of
release
the
report
in
a
co-branded
way
right,
so
they
can
put
their
logo
on
the
report
and
say
you
know
we
were
a
critical
part
of
putting
this
together
and
giving
the
data,
and
also
you
know
in
in
many
of
those
articles
I
mentioned
the
press
hits
they
get
a
shout
out
in
you
know
the
press
hits
too
and
so
they're
they're
doing
it
out
of
you,
know
the
goodness
of
their
hearts
and
and
free
press
right,
and
so
that's
you
know
always
kind
of
a
tough
motivator,
especially
for
some
of
these
seas,
or
at
least
some
of
the
ones
we've
talked
to
are
actually
rather
small,
and
so
the
the
kind
of
personnel
effort
that
it
takes
to.
D
You
know,
person
power
and
bring
this
project
along,
and
so
yes
and
then
on
our
side,
we
have
funded
through
the
the
seed
funding,
came
from
the
linux
foundation
and
we're
you
know
we're
looking
for
broader
kind
of
support
as
we
go,
but
we
have
some
folks
on
our
side
that
do
the
data
analysis
and
bring
all
these
different
data
sets
together
and
to
your
question
about
kind
of.
Is
this
standardized?
D
The
answer
is
no,
because
you
know
all
these
companies,
you
know
they
they
they,
you
know
manage
the
process
and
the
way
that
they
collect
the
data
differently.
They
do
they
store
the
data
differently.
I
mean
this.
Is
you
know
if,
if
you've
ever
done
anything
with
multiple
companies,
you
know
they
all?
D
Do
it
differently
right
and
that's
exactly
what's
going
on
here
now
to
your
point,
though
we
would
love
to,
and
originally
our
our
thought
was
try
to
try
and
do
this
quarterly
to
you
know:
release
kind
of
a
regularly
updated
cycle.
Then
then
we,
you
know,
started
to
try
and
do
it
and
and
that
we
decided
to
back
off
to
yearly
at
least
at
the
start,
but
absolutely
a
more
frequently
updated.
You
know,
list
or
or
kind
of
you
know.
D
Statistics
is
absolutely
something
that
we
would
love
to
do
it's
just
a
matter
of
kind
of
resources
on
our
ends,
right
and
and
also
the
resources
on
these
companies,
but
I
think
that
you
know,
as
we've
kind
of
gone
through
this
process
now
that
you
know
the
companies
that
we've
worked
with
so
far
are
familiar
with
what
we
need.
D
They
can
kind
of
automate
it
moving
forward
right,
and
so
that's
why
you
know
our
goal
is
to
kind
of
get
everything
set
up
so
that
on
january
1
they
can,
you
know,
run
a
script,
and
that
does
everything
that
it
needs
to
do
and
sends
us
the
data
and
we
have
2020s
data
and
we
can
put
that
all
together
across
the
different
scas
and
then
release.
D
You
know
the
reports
not
too
long
after
that
right
and
so
the
hope
would
be
that
at
some
point
it
becomes
so
automatable
that
it
we
can
do
it
more
frequently,
whether
it's
quarterly
or
monthly,
or
you
know,
as
as
frequently
as
is
feasible.
D
Yes,
so
that's
that
is,
the
answer
is
for
the
preliminary
report.
No,
but
our
our
plan
is
to
indeed
kind
of
you
know
so,
there's
there
well,
it
just
ended,
but
the
debian
like
popcorn,
you
know,
process
where
they
tracked
kind
of
downloads
of
projects
through
debian
and
things
like
that.
We
are
definitely
open
to
that
in
into
including
that
type
of
material.
D
At
the
moment
we
haven't-
and
so
we've
you
know
in
the
report,
we
kind
of
clearly
say
like
there
are
other
ways
to
to
do
this.
This
is
the
way
that
we
felt
would
add
the
most
value
because
most
of
those
data
sources
or
at
least
add
the
most
value
at
the
beginning,
because
all
those
data
sources
are
public
and
we're
trying
to
bring
kind
of
some
of
the
private
data
sources
to
light
in
a
way
that
you
know
shines
some
light.
D
G
Is
it
possible
from
the
sca's
to
get
information
about
more
than
just
developer
libraries?
So
I'm
curious
why
the
focus
that
seems
like
a
kind
of
a
big
gap-
big
miss
there,
because
there
are
a
lot
of
you
know
core
components.
There's
linux,
there's
python
a
bunch
of
core
components
that
don't
get
identified
so
yeah.
You
know
what
the
best
way
is
to
to
to
bring
those,
because
you
know
for
this
working
group
we're
thinking
about
securing
critical
projects.
D
Yeah
thanks
kay,
that's
a
that's
a
good
question
and,
and
that's
you
know
we're
in
some
ways
we're
almost
too
granular
right
in
terms
of
the
level
of
analysis
that
we've
been
looking
at
and
that
that's
based
on
kind
of
the
data
sources
that
are
are
available
to
us
right,
so
so
the
seas,
they're
measuring
things
at
the
package
level,
because
their
you
know
primary
concern
is,
is
license
violations
and
so
that
you
know
necessarily
has
to
kind
of
go
down
to
these
super
package
levels.
D
And
so
you
know
when
we
think
about
the
larger
projects
like
linux
or
python,
or
you
know,
as
christina
just
mentioned,
the
chat
rails
right.
The
these
you
know
projects,
even
even
if
we
say
okay,
python
needs
a
lot
of
investment
well,
which
pieces
of
python
need
a
lot
of
investment
right.
That's
still
kind
of
you
know.
D
The
the
goal
with
this
type
of
project
is
to
help
give
more
granular
insights
into
you
know
what
needs
help
right,
and
so,
in
into
that
point
you
know
something
we
would
envision.
You
know
eventually,
and-
and
this
is
again
more
just
kind
of
resource
limitations
than
anything,
but
you
know
you
could
potentially
say.
Okay,
we
have
this
giant
list
of
these
kind
of
smaller
level
packages.
D
Just
show
me
the
stuff,
that's
in
python
right
or
just
show
me
the
stuff,
that's
part
of
the
kernel
and
things
like
that,
so
that,
if
what
you
care
about,
is
you
know
that
larger
project?
You
can
still
use
this
in
a
way
that
helps
you
kind
of
drill
down
and
and
see
which
pieces
of
that
larger
project
are.
You
know,
in
this
case
the
the
most
used
and
most
relied
upon,
at
least
from
the
the
viewpoint
that
we
have.
H
D
Excellent,
so
if
there's
no
other
questions
at
the
moment,
I'll
I'll
jump
in
and
just
talk
briefly
about
the
survey
and
and
and
where
we
are
with
that,
because,
as
I
mentioned,
you
know,
this
isn't
only
about
kind
of
the
the
technical
part
of
the
the
problem.
It's
also
about
the
human
part
of
the
problem,
and
so
we
launched
over
the
summer
a
survey
of
open
source
developers
to
basically
answer
try
and
answer
a
number
of
questions
related
to
both
security.
D
But
again
this
kind
of
big
picture
view
of
security.
In
terms
of
you
know
the
sustainability
of
open
source
and
these
kind
of
open
source
packages,
and
in
particular
we
focused
on
the
packages
that
came
to
the
surface
through
through
the
the
census
and
in
because
we
wanted
to
really
focus
on.
You
know
some
of
those
most
critical
packages,
but
we
didn't
only
focus
on
that.
D
We
just
tried
to
kind
of
over
sample
folks
that
were
working
on
those
packages
and
we
also
did
a
lot
to
focus
on
maintainers
right.
So
the
you
know
the
the
critical
folks
within
these
pack
within
these
projects
that
are
doing
a
lot
of
the
work,
and
so
we
wanted
to
think
about
everything
from
you
know.
Demographics
of
you
know
who
are
these
people?
Where
are
they
located
and
things
like
that?
D
But
also
thinking
about
you
know
what
can
we
do
to
avoid
burnout
of
maintainers
as
well?
And
thinking
about
you
know
the
relationship
with
payment
right,
because
you
know
when
open
source
was
born.
There
was,
you
know,
a
massive
pushback
about
against
any
money
being
involved
in
it
and
now
obviously
that's
not.
You
know
the
case
right
so
there's
I
remember
hearing
a
a
quote.
D
One
time
that
you
know
money
would
ruin
the
open
source
ecosystem,
which
may
be
true
in
theory,
but
we
were
at
least
at
the
moment
proving
that
it's
it's
not
true
in
practice
right
and
so,
how
do
we
think
about?
You
know
the
role
of
money
in
the
open
source
ecosystem
and
then
also.
D
Lastly,
as
I
mentioned,
we
wanna
also
thinking
about
how
folks
are
getting
their
their
knowledge
around
security
and
best
practices,
and
things
like
that,
so
that
we
can
think
about
ways
of
of
reaching
out
to
them
and
encouraging
them
to
you
know
better
to
kind
of
use
better
practices.
So
we
haven't
really
gone
through
we're
we're
in
the
process
right
now
of
analyzing
the
results
of
the
survey,
but
just
to
give
you
a
few
kind
of
high
level
notes
the
you
know.
D
So
we
we
ended
up
seeing
more
than
2500
unique,
open
source
projects,
because
we
asked
people
specifically
what
projects
do
you
work
on,
knowing
that
many
people
work
on
more
than
one
project
and
we
ask
them
specific
questions
about
the
different
projects
that
they
work
on,
including
you
know,
their
level
of
involvement
right
and
so
of
the
respondents
that
we
have
almost
464
are
maintainers
for
at
least
one
open
source
project,
and
so
again
we
kind
of
focused
on
these
maintainers,
because
in
particular
we
wanted
to
know
you
know
those
are
our
in
many
projects.
D
The
critical
folks
and
and
kind
of
we
wanted
to
understand,
you
know,
are
they
getting
burnt
out?
Are
they
do?
They
have
too
many
requests
on
their
time?
And
and
what
can
we
very
broadly
speaking,
you
know:
what
can
we
do
to
help
those
those
folks
out
to
to
prevent
burnout
to
prevent
them
from
just
you
know,
throwing
their
hands
up
and
saying.
I
can't
do
this
anymore.
You
know,
I'm
gonna
go
do
other
things
right,
so
so
we
have
over
a
thousand
total
responses,
not
all
of
them.
D
You
know
the
survey
was
rather
in
depth,
and
so
not
all
of
them
finished
the
survey,
so
we're
still
kind
of
sifting
through
through
all
of
that,
but
we
know
that
there
are
at
least
six
or
seven
hundred
people
that
completed
the
survey
in
full
and
we
think
we
can
use
some
of
those
folks
that
had
only
completed
part
of
the
survey
and
some
of
their
information
as
well.
D
So
so,
like
I
mentioned
this
ran
over
the
summer,
we
did
you
know
kind
of
try
to
promote
this
in
a
variety
of
ways
where
we,
you
know,
we
had
a
bunch
of
different
articles
about
it.
David
and
I
both
went
on
a
couple
podcasts,
and
so
we
really
tried
to
cast
a
pretty
broad
net
in
terms
of
capturing
folks
on
different
projects
at
different
levels
of
contributions
and
kind
of
across
the
globe.
D
We
sense
that
the
linux
foundation
was
was
kind
enough
to
kind
of
advertise
this
through
a
bunch
of
their
mailing
lists
as
well.
So
we
we
that's
what
we
think
you
know
kind
of
led
to
this
broad
coverage
of
a
variety
of
projects,
but
also
this
kind
of
great
depth
of
high
level
folks
as
well
in
terms
of
the
maintainers.
D
So
so,
as
I
mentioned,
we're
in
the
process
of
reviewing
the
survey
results
now
and-
and
you
know,
I'm
parsing
through
them
and
our
hope
is
to
around
either
late
september
or
early
october,
release
the
results
of
the
survey
and
and
what's
going
on
there,
so
I
will
pause
again
there
and
just
curious.
Obviously,
you
know
there's
less
to
kind
of
talk
about
and
hang
our
hats
on
there
but
curious
if
any
anyone
has
any
thoughts
or
questions
on
kind
of
the
survey.
C
So
maybe
not
as
much
as
a
of
a
question,
but
this
is
I
mean
this
is
very
cool.
If
you,
I
don't
know
if
you
have
access
to
our
agenda
doc
today,
but
we
are
kicking
around
different
ideas
for
how
we
can
help
open
source
projects.
You
know
through
this
working
group
and
so
be
curious.
You
know
super
curious.
C
What
some
of
those
results
are
on
the
survey
because
we're
thinking
about
this
as
like
a
menu
of
sorts
like
hey,
I
need
help
with
this
or
I
need
help
with
that,
and
we
know
that
every
project's
a
bit
unique
and
it's
not
all
a
one
size
fits
all.
So
I'm
super
excited
to
see
to
see
the
results
when
this
comes
out.
D
And
that's
I
mean
that's
exactly
what
the
goal
of
this
was
was
again.
You
know
the
the
in
the
census.
It
was
kind
of
mechanically.
What
are
the
widely
you
know
widely
used
projects,
but
in
the
survey
digging
into
you
know:
okay,
what
are
the
problems
that
these
folks
are
facing?
The
maintainers,
the
the
core
developers,
the
you
know,
and
even
the
kind
of
you
know
the
there's
been
a
lot
of
you
know.
D
Research
has
shown
that
in
open
source,
it's
kind
of
this
power
law
distribution
right
where
there's
a
handful
of
folks
that
do
most
of
the
work,
but
that
long
tail
is
actually
important
as
well,
because
they're,
the
ones
that
are
kind
of
finding
random
bugs
or
doing
small
little
things
that
help
with
the
the
kind
of
sustainability
of
the
project.
So
we
wanted
to
be
able
to
kind
of
separate.
D
C
Oh
yeah,
sorry,
I
didn't
give
a
bit
of
an
intro
on
the
oss
app.
It
seems,
like
you've
heard
a
bit
from
david,
how
we
all
came
together
to
help
improve
security,
so
this
working
group
specifically,
is
is
my
goal,
is
to
do
sort
of
exactly
what
you've
been
talking
about,
is
identify
these
critical
projects
that
are
used
throughout
the
world
and
then
figure
out
how
we
can
help
and
support
them.
D
And
I
think
you
know-
and
I
think
that's
the
thing
is
that
I
I
mean
I'm
I'm
at
a
business
school
and
you
know
this
is,
I
think
the
role
of
businesses
in
in
open
source
and
the
future
of
open
source
is
clearly
becoming
much
more
important
and
you
know,
and
there
there's
all
these
kind
of
not
not
separate,
but
everybody's,
going
towards
a
common
goal.
It's
just
a
question
of
kind
of
how
do
we
prioritize
and
how
do
we
focus
our
resources?
And
I
think
that's
you
know.
D
Our
goal
with
this
project
is
really
to
help
answer.
That
piece
of
the
question
is,
you
know
each
company
everybody
that's
on
here
knows
what
projects
are
most
important
to
them
and
that's
important
right.
Like
I
mentioned
at
the
beginning,
you
know
that
when
the
eu
did
their
bug
bounty
program,
they
focused
on
the
projects
that
were
important
to
them
and
that's
that's
great.
That's
that's
good
and
that's
important,
but
but
what
you
know
can
we
give
a
kind
of
more
global
view
as
well?
D
And
I
do
think
that
you
know
the
the
integration
of
kind
of
these
cross-company
organizations
that,
like
the
ossf
is,
is
going
to
be
particularly
important
to
that,
because
it
gives
us
a
place
where
we
can
all
kind
of
safely
say
you
know,
here's
what's
important
to
us
and
kind
of
aggregate
that
information
up
right.
D
I
mean
my
like
I
mentioned
my
background
was
in
cyber
security,
and
I
worked
with
the
the
financial
services
isac,
which
is
one
of
the
information
sharing
analysis,
centers,
and
that
was
such
a
big
benefit
to
be
able
to
safely
kind
of
share
this
information.
That's
it's
not
like.
D
That's
like
the
core
secret
sauce
of
what
you
know,
makes
google
successful
or
ibm
or
whoever,
but
it
is
important
to
you
know
the
health
of
the
whole
ecosystem,
and
so
we're
happy
to
you
know
kind
of
engage
with
this
group
and
as
it
you
know
as
it
decides
where
what
direction
it's
heading
and
hopefully
be
able
to
add
some
direction
and
on
that
as
well.
C
All
right
well,
thank
you
so
much
for
the
presentation.
We
have
a
couple
more
topics
that
are
very
related
on
our
agenda
today
that
we
can
try
to
get
through
quick.
I
just
I
just
mentioned
the
first
one,
so
I
guess
I'll
just
skip
to
that.
Really
quick
as
dan
started
a
doc
and
there's
a
link
in
the
in
the
agenda
for
a
brainstorming
session
of
the
menu
of
services
that
I
was
just
mentioning
like
what
types
of
things
can
we
do
for
projects
and
we've
seen
a
few
different
models?
C
We've
heard
some
don't
work
as
well
as
others.
So
if
you,
if
you're
interested
click
on
that
doc
and
and
start
adding,
just
some
ideas
there,
and
then
I
think
when
we
get
some
of
this
survey
data,
we
might
be
able
to
expand
this
a
bit
more.
B
So,
just
for
a
little
bit
more
context,
there
kim
and
I
at
google
are
working
on
budget
stuff
for
next
year
trying
to
figure
out
how
much
money
we
have
available
working
with
other
companies
interested
in
contributing
money
to
this
cause,
and
so,
at
the
same
time
we're
working
on
how
we
would
different
ways.
We
could
make
that
money
useful
to
projects,
so
you
can
help
us
brainstorm
on
that.
That'll
also
help
us
make
our
case
stronger
to
get
more
money
made
available
here
and
it'll
be
creative.
B
G
Question
for
david,
I
really
related
to
the
money
topic,
and
this
is
also
related
to
the
core
infrastructure
initiative.
So
I
know
that
the
core
infrastructure
initiative
currently
so
we're
looking
at
I'm
trying
to
bring
the
core
infrastructure
initiative
in
into
open,
ssf
and
kind
of
continue
on
that
that
mission.
But
you
know
we
could
make
it
be
one
integrated
effort
open.
So
the
core
infrastructure
initiative
currently
does
fund
some
work
on
some
projects.
G
I
know
it
does
fund
the
linux
some
linux
security
work
david
is
there:
are
there
other
projects
that
the
core
infrastructure
initiative
is
funding
now
or.
A
Probably,
and
that
in
fact
is
one
of
the
things
I'm
going
to
try
to
dig
out.
Okay
just
ask
right
right,
but,
for
example,
there's
and
some
this
is
not
clear.
You
know
under
rubric
so,
for
example,
whether
or
not
you
called
under
the
cii
or
just
the
linux
foundation,
there's
two
audits
involving
the
linux
processes
and
there's
also
efforts
to
try
to
eliminate
warnings
from
the
compilers,
because,
right
now,
if
you
compile
the
linux
kernel,
there's
an
endless
number
of
warnings
that
people
have
started
ignoring,
which
is
a
bad
idea.
A
C
Okay,
as
an
alternative
to
the
methodology,
which
presumably
is
proprietary
used
by
sca's,
are
people
here
familiar
with
tide,
lift
or
libraries
dot
io,
it's
an
open
source
tool
that
ranks
packages
according
to
a
variety
of
open,
metrics
across
different
programming
languages,
and
if
we
could
consider
that,
as
part
of
like
identifying
critical
packages.
D
Yeah,
so
we
so
that
that's
a
great
point
and
and
if
if
the
group
doesn't
already
have
hooks
in
the
tide,
lifts
are
actually
based
in
boston,
and
so
I
we've
we've
talked
with
them
a
bit
as
well
and
before
the
pandemic
setting
we
were
talking
with
them.
But
yes,
indeed,
we've
we
used
their
libraries
dot
io
as
kind
of
to
kind
of
set
the
base
for
a
lot
of
what
we
were
doing,
because
they've
done
at
least
kind
of
advanced.
D
Some
of
the
the
naming
issues
and
things
like
that
but
agree
that
tide,
lift
is
is
an
interesting
model
and-
and
I
think
it's
again,
it
ends
up
being
kind
of.
You
know
individual
companies.
What
is
important
to
you,
which
is
which
is
a
valid
way
to
to
go.
But
it's
it's
only.
You
know
kind
of
the
tip
of
the
iceberg
so,
but
they
are
are
doing
some
interesting
work
and
they're
continuing
to
grow
as
well.
A
Yeah,
in
fact,
under
under
the
cii
we
actually
when
we
did
an
early
preliminary
version
of
the
census
2,
we
actually
contributed
back
some
fixes
to
libraries.io
because
they
had
a
number
of
bugs,
as
we
were
trying
to
gather
data
from
them.
C
C
So
quickly,
one
other
agenda
item
I
wanted
to
make
sure
we
got
to
today.
Was
we
talk
about
the
critical
projects?
Well,
one.
I
think
that
we
can
all
agree
on
is
linux
we
have
through,
through
the
linux
foundation,
there's
some
more
contracted
work.
That's
going
on
to
help
with
the
linux
kernel
security
efforts
is
sasha
on
the
call
that
maybe
wants
to
speak
a
bit
more
to
this,
so
basically
we're
trying
to
make
sure
that
we
can
make
sure
that
these
types
of
roles
are
sustainable
and
funded
long
term.
So.
E
We
have
one
person,
that's
funded
via
the
cii
and
is
doing
more
work
around
the
tree,
wide
refactoring
and
just
removing
classes
of
issues
out
of
the
kernel,
and
we
have
a
few
parallel
work
streams
that
are
basically
based
on
interns
and
such
and
the
younger
folks
who
are
fixing
bugs
found
from
a
security
tool
so
like
a
system
called
fuzzers
or
various
sanitizers,
and
we
kind
of
work
with
them
to
fix
those
bugs
and
we're
basically
looking
to
bring
all
this
work
into
this
one.
E
C
Cool
so
so
I'm
gonna
say
something
in.
F
There
yeah,
I
was
gonna,
say
as
well
amir
from
ostrich
here
that
we've
also
been
involved
in
that
and
one
of
those
projects,
as
well
with
improving
linux,
and
so
I
was
hoping,
I
think,
in
the
coming
weeks.
We'll
definitely
have
more
results.
So
I
would
love
to
you
know,
chat
with
the
group
about
that
and
kind
of
talk
about
how
we
made
that
happen.
If
that's,
okay
with
everyone.
F
C
Okay,
cool
yeah,
sasha:
let's
keep
the
conversation
going
and
see.
If
we
can,
you
know,
raise
some
funds
or
through
the
ossf
and
make
sure
we
keep
the
next
secure.
G
Right
yeah,
so
I
think
we'll
probably
say
the
best
way
for
us
to
continue.
This
conversation
is
in
the
context
of
bringing
the
cii
into
open
ssf,
and
we
need
to
think
about
how
to
move
the
things
that
they're
currently
funding,
and
you
know
as
we're
doing
that.
We
can
look
at
consolidated,
consolidating
efforts
like
the
the
work
that's
through
funded
through
cii
and
the
interns
that
are
funded
through
the
community
bridge
programs.
Right.
E
Right,
I
think
just
doing
consolidating
all
of
that
under
one
roof
will
just
benefit
the
progress
as
well,
since
we're
doing
a
lot
of
scattered
things
now.
But
then,
if
we
work
under
this
work
group,
we
can
benefit
a
lot
from
future
ideas.
Thoughts.
You
know,
plans
it's
just
worthwhile
to
continue
this
work
under
this
war
group.
I
think.
C
Awesome
so
it's
already
went
backwards
up
the
agenda.
The
last
thing
that
we
had
on
for
the
for
the
talk
today
was
the
working
group
mission.
Did
someone
else
add
this?
Maybe
I
added
it
from
last
time,
but,
yes,
we
should
kind
of
come
up
with
a
collective
mission.
Together
with
this
working
group,
we
can
start
a
new
doc
with
ideas
and
throw
things
on
there
and
then
discuss
next
week.
If
that
sounds
good
for
people.
C
Cool
okay,
so
then
homework
for
next
time
is
take
a
look
at
that
services,
menu
of
services
doc
and
then
also
we'll
noodle
on
a
mission
for
this
working
group
together.
C
Yes,
thank
you,
jenny,
cool,
any
other,
last-minute
things.
No,
I
wanted
clarification
on
what
the
relationship
between
this
working
group
and
other
working
groups
would
be.
In
the
last
meeting
we
talked
about
setting
up
a
slack
channel.
I
opened
an
issue
in
the
repository
and
then
someone
responded
that
we
need
to
coordinate
with
other
working
groups
before
we
decide
to
use
slack,
and
that
just
seemed
like
an
odd
response
to
me.
H
Feel
free
to
create
a
channel
if
you
don't
already
have
one
and
if
you
need
help,
I'm
happy
to
set
that
up
for
you
as
well.
But,
yes,
you
don't
need
to
wait
to
use
slack
and
as
far
as
coordinating
working
groups
at
the
tac
level,
we're
kind
of
driving
that
to
make
sure
everybody's
coordinated.
But
certainly
the
output
of
this
group
will
be
beneficial
to
other
groups.
And
likewise
other
groups
will
probably
drive
some
work
that
could
be
used
by
this
working
group.
A
But
to
quickly
clarify
my
understanding
was
that
the
tech
just
briefly
wanted
some
time
to
coordinate
the
same
way
for
all
the
working
groups
to
communicate,
and
it
that's
now
been
resolved.
They
have
mainly
basically
it's
mainly
lists
and
slack
are
the
primary
quick
communications
as
well
as
obviously
people
can
share
information
with
google,
docs
or
or
whatever,
but
the
primary
ones
for
discussions
were
mailing
lists
and
slack.
Yes,.
H
Correct
yeah
we
wanted
to
use
the
mailing
list
for
like
official
communication
and
slack
can
be
more
casual
conversations
right.
I
think
that
was.
B
Think
we
just
got
it
a
couple
days
ago.
I
just
replied
to
the
issue
with
it
now
I'll
add
that
to
the
readme
it
went
out
on
the
tac
mailing
list.
I
think
ryan
sent
it.
H
So
I
actually
grabbed
the
the
main
list
of
everyone
and
manually
put
emails
in
there.
So
if
I
missed
you,
I
apologize,
and
it's
also
I'm
not
sure
why
you
wouldn't
be
on
the
main
mailing
list,
but
we'll
kind
of
resolve
that
I've
also
asked
lf
for
a
way
to
have
to
be
able
to
email
everyone
in
openssf
for
things
like
this
in
the
future,
so
that
we
don't
miss
out
on
folks
but
certainly
feel
free
to
share
it
amongst
your
working
groups
and
hope
it
will
catch.
Everybody
eventually.