►
From YouTube: OpenFeature Project Meeting - Mar 03, 2022
Description
Project sync-up. We did introductions and overview of the OpenFeature project, and than had a Q&A session with participants. After that we discussed the next steps and the meeting cadence.
Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit#heading=h.vqjhqfod6mpn
A
As
we
saw
a
lot
of
these
libraries
being
out
there,
they
are
kind
of
like
all
doing
the
same,
but
not
exactly,
but
finding
more
agreement
in
the
industry
and
bringing
everybody
working
on
this
together
to
hopefully
have
a1
version.
That
will
also
help
us
all
to
invest
resources
not
in
especially
building
their
client,
libraries,
but
also
other
topics,
and
I
pass
on
to
kevin.
B
Hi
everyone,
my
name,
is
kevin
chu,
I'm
on
the
product
team
at
gitlab,
and
one
of
my
teams
is
responsible
for
gitlab's
feature
flag
feature
and
the
idea
of
having
an
open
source
truly
an
open
source
feature
flag.
Library
is
very
appealing
to
us,
and
I
see
my
friend
from
flagsmith
ben
then
over
to
you.
C
Yeah,
hey
everyone.
My
name
is
ben.
I'm
in
london,
I'm
one
of
the
co-founders
ceo
of
flagsmith.
We
are
a
commercial
open
source
speech,
flagging
platform,
primarily
doing
sas
private
cloud
and
on
tenancy
sorry
on
premise.
Mainly
many
sort
of
engineering
led
feature
plugin
rather
than
av
testing,
but
yeah
like
we've,
just
spent
hundreds
and
hundreds
of
hours,
rewriting
all
our
sdks.
D
E
F
G
Go
ahead,
please
sure
my
name
is
alex
jones,
I'm
the
director
of
kubernetes
canonical,
so
that's
everything
communities
from
microcase
to
charmed
communities,
to
our
our
our
customization
of
operators.
I'm
excited
for
this
group
because
I
think
that
there
needs
to
be
a
standard
in
the
space.
There
are
a
lot
of
companies
commercially,
who
are
doing
great
things,
but
it'd
be
good
if
we
could
have
more
of
an
open
source
agreement
on
what
looks
what
what
looks
good
to
us
so
yeah
excited,
I'm
not
sure
who
hasn't
gone.
H
H
We
already
covered
one,
so
I'm
a
member
of
the
dana
trace
hospital.
I'm
a
cdf2c
chair
also
captain
jenkins
for
me,
future
flags
and
open
source
always
a
pain
because
there
is
no
standard
solution.
It's
my
key
interest
and
also
I'm
happy
to
get
this
initiative
because
I
agree
with
alex
it's
definitely
a
car
gap
in
the
open
source
servers.
Now
there
are
many
open
source
implementations
available
to
my
new,
but
having
industry
white
standard
would
be
super
useful.
I
J
I
J
J
I'll
I'll
finish,
the
michael
trinity,
in
this
case
michael
winkler,
I'm
in
in
dynatrace
responsible
as
pm,
director
on
cloud
automation,
sites
or
anything
around
cloud,
native
topics
etc,
and
I've
been
looking
at
feature
flags
and
looking
into
feature
flags
for
the
past.
I
would
say
nine
months
lately,
so
it's
time
to
deliver
right.
Nine
months
are
over
and
I'm
really
happy
to
be
here
and
with
that
handing
over
to
david.
H
H
F
Yeah
sure
so
for
those
of
you
who
have
already
seen
the
presentation
I
apologize,
but
we'll
just
try
to
get
everyone
up
to
speed
and
I'll
try
to
move
pretty
quickly
through
it.
If
you
do
have
any
questions,
though,
just
feel
free
to
you
know,
stop
me
at
any
point
and
I'm
happy
to
dive
into
it
a
little
bit
deeper.
F
Cool
all
right,
can
everyone
see
the
screen
real,
quick
thumbs
up,
looks
good,
okay,
perfect
all
right.
So
obviously
we
were
talking
about
open
feature
here
and
part
of
it
is
focusing
on
the
cloud
native
feature:
flag
management
aspect
of
it,
but
also
as
we'll
kind
of
dive
into
it's.
It's
also
more
probably
about
the
spec,
and
that's
probably
why
most
people
are
here
so
see
there.
We
go
perfect.
I
think
here
we
go
sorry
about
that
technical
difficulties,
all
right.
F
So
basically,
a
big
inspiration
for
for
the
structure
of
the
project
was
was
open,
telemetry,
which
we
feel
did
a
really
nice
job,
trying
to
commoditize
agents
effectively.
That's
a
pretty
complex
part
of
observability
so
for
those
that
aren't
familiar
open,
telemetry
is
effectively
monitoring
or
observing
observability
data,
and
it's
a
way
to
capture
that
in
a
uniformed
way.
F
One
of
the
big
value
props
of
that
was
we
could
effectively
let
the
community
help
contribute
to
the
agents
to
collect
data,
and
we
thought
that
was
a
really
good
way
to
handle
feature
flagging
as
well.
So
we
really
wanted
to
model
this
this
organization
off
that
one
and
really
our
first
goal
would
be
to
define
that
open
standard
in
a
vendor
agnostic
way,
so
keeping
keeping
in
mind
some
of
the
existing
use
cases
as
we
build
out
the
spec
and
make
sure
that
we
account
for
all
of
those.
F
As
part
of
that,
once
we
have
the
spec
in
place,
we'd
like
to
build
a
unified
api
and
sdk
we'd,
also
like
to
provide
a
developer
first
cloud
native
reference
implementation.
So
that's
something
we'll
get
into
in
a
little
bit
and
then
obviously
support
some
extensibility
for
commercial
offerings.
So
the
the
initial
developer,
you
know
first
cloud
native
implementation
would
likely
be.
You
know
missing
certain
things
like
audit
logs
and
permissions
things
like
that.
That
would
be
more
enterprise,
focused,
typically
cool,
so
the
the
current
ecosystem.
F
We
talked
about
this
just
a
little
bit
at
the
beginning,
but
there
are
quite
a
few
different
sdks
for
all
the
different
vendors
and
they're
effectively.
You
know
doing
the
same
thing,
so
we
sort
of
view
that
as
a
an
issue
or
it'd
be
nice
to
kind
of
commoditize
the
sdks
themselves,
they
are
open
source
and
I
think
a
couple
on
this
call
can
probably
say
that
there's
a
bit
of
a
limited
ecosystem
around
that,
but
they
are
open
source
and
that's
pretty
standard.
F
You
can
definitely
look
into
basically
all
of
the
sdks
for
all
of
the
vendors,
which
is
something
that
I've
done
in
a
lot
of
cases.
So
I
can
kind
of
talk
about
that
in
a
bit
as
well.
This
is
this
tends
to
be
a
big
one
too.
There's
a
lot
of
vendor
lock-in
at
the
code
level,
so
it
actually
to
switch
feature
flag
managers.
You
would
have
to
potentially
touch
hundreds
or
thousands
of
files
in
your
code
base
in
order
to
switch
over
to
a
different
vendor.
F
There
are
they're
not
really
taking
advantage
of
some
cloud
native
capabilities
and
the
other
piece
that
I
really
like
from
my
perspective.
That's
really
interesting
is
some
of
the
missing
integrations
with
observability,
specifically
open
telemetry.
In
this
case,
where
I
think
you
know,
we
could
really
enhance
monitoring
capabilities
by
adding
you
know,
feature
flag
information
to
distributed
traces.
A
And
maybe
one
word
here
I
mean
we
have
some
vendors
here
and
obviously
you
might
think.
Well,
we
as
vendors
actually
like
render
login.
That's
not
that's
bad,
arguably
well,
first
of
all,
the
users
don't
like
it,
but
we
also
thought
about
this.
If
like
either
way
with
open
telemetry,
specific
vendors
come
up
with
middleware
and
other
components
that
can
be
controlled
via
features,
it's
still
hard
to
figure
out
which
feature
flagging
solution.
They
should
be
using
for
their
components
like
think
of
any
middleware
layer.
A
You
might
argue,
it
goes
more
into
how
you
would
could
like
config
configure
these
libraries
still
it's
very
unclear
how
to
easily
integrate
it
and
in
most
cases
today,
in
this
scenarios
we
see
like
very
much
also
blend
library,
specific
configuration
files
which
are
hard
to
integrate
into
a
vital
feature.
Flagging
solution.
F
Yep,
exactly
thanks
so
cool
moving
on
to
the
proposed
solution
here,
so
basically
starting
off
with
the
open
standard
like
that.
That
has
to
be
kind
of
the
basis
for
this
whole
project,
and
once
we
do
that,
we
can
possibly
in
parallel,
we
basically
develop
a
spec
compliant
and
vendor
agnostic
sdk.
So
the
vendor
agnostic
part
is
interesting
there.
So
if
we
can,
if
we
can
accomplish
that,
it
would
allow
users
to
start
off
with
open
feature
and
change.
F
I
like
to
integrate
with
cloud
native
technologies
such
as
telemetry,
which
would
allow
for
enhanced
distributed
traces
for
those
that
are
familiar
metrics
and
then
another
interesting
piece
that
open
telemetry
could
provide
would
be
request,
scoped
context
which
would
actually
allow
you
to
pass
context
across
services
in
your
application
and
then
the
last
one
would
be
providing
a
kubernetes
focused
reference
implementation.
So,
looking
into
what
kubernetes
provides,
there's
some
really
interesting
opportunities
that
would
allow
us
to
build
a
really
complete
feature
flagging
system
based
on
the
technologies
that
are
already
provided
by
kubernetes
itself.
F
In
this
case,
we
would
create
or
use
the
operator
pattern
and
a
custom
resource
definition,
which
would
basically
represent
the
feature
flag
itself
that
could
be
pushed
to
a
feature:
flag,
sidecar,
which
could
likely
be
written
in
a
single
language,
and
then
we
would
have
the
the
different
language
sdks
be
able
to
connect
to
that
sidecar.
In
order
to
evaluate
the
the
state
of
the
feature
flag.
F
Cool
the
specifications,
so
it's
it's
currently
in
the
research
phase.
This
is
where
really
interesting.
To
get
some
feedback
on
what
type
of
research
would
be
useful
and
there's
probably
quite
a
few
people
on
this
call
that
has
already
done
quite
a
bit
of
research
as
well,
so
where
we
can
kind
of
combine
notes
there.
I
think
that
would
be
very
valuable.
F
So
far,
the
research
has
been
focused
on
back
end
feature
flagging,
although
client
has
been
a
huge
topic
as
well
and
that's
something
we'll
have
to
tackle
in
the
near
future
for
milestones
so
we're
right
near
the
beginning.
This
is
where
we're
still
defining
our
mission:
governance,
vision,
the
initial
scope
and
the
architecture,
so
even
that
architecture
diagram
that
may
not
be
what
we
go
with,
but
it's
just
a
proposal
at
this
point,
we'd
really
like
to
be
able
to
announce
something
in
may.
F
H
F
H
F
Okay,
great
the
the
august
time
frame
on
there
was
not
I
mean,
there's
nothing
like
written
and
so
on
at
this
point,
but
that's
where
I
like
to
really
push
some
of
the
like
observability
components
to
this,
with
the
hope
of
having
something
ready
to
ga
around
kubecon
us,
which
happens
to
be
in
my
hometown,
so
pretty
exciting,
all
right.
So
what's
next
so
we're!
What's
now
we
are
still
kind
of
in
the
project
and
governance
bootstrapping
phase
a
lot
of
the
repos
out.
F
There
are
still
marked
as
work
in
progress,
as
I
mentioned
just
a
second
ago
that
we
we
have
applied
for
the
cncf
sandbox
and
the
cycle
starts
may
6th.
So
hopefully
we
hear
some
information.
You
know
relatively
soon
we
have
reached
out
to
a
number
of
potential
contributors,
including
yourselves,
and
then
just
working
on
summarizing
some
of
the
research
and
the
initial
spec
of
the
draft
or
draft
to
the
spec.
G
G
H
C
Okay,
I
have
a
question
michael.
Do
you
intend
to
like
have
a
second
you
know?
Is
this
meant
to
be
a
kind
of
the
lowest
common
denominator
kind
of
platform
to
build
additional
aspects?
You
know
version
two
of
the
specification
on
top
of
or
because
the
thing
that
I've
found
is
like
a
lot
of
things
in
computer
science.
You
know
they
seem
simple
on
the
surface,
but
they
can
get.
C
You
know
there's
this
there's
I'm
just
curious
to
know.
Yeah
like
I,
I
I'm
fairly
naive
towards
these
sorts
of
projects,
so
I'm
just
not
sure
like.
If
it's
common
to
have
like
you
know,
try
and
get
a
version.
One
out.
That's
that's
simple
and
does
the
core
use
cases
but
doesn't
try
and
do
anything
too
elaborate.
You
know.
A
A
When
you
look
at
feature
flagging
and
I'll
leave
the
architecture
and
the
distribution
of
flex
out
of
the
equation,
then
you
have
obviously
the
part
pretty
much
work
that
you
put
into
your
application
to
query
for
features
like
to
fit
in
data
and
to
clear
features.
That's
what
the
sdk
would
do
and
that's
what
the
connection
idea
was
open
to
land
between
getting
like
open,
telemetry
package
data.
I
think
that's
the
first
thing
we
should
like
really
tactic
and
work
on.
A
Githubs
type
of
deployment
model
is
going
to
be
super
helpful.
They
work
on.
Do
we
want
to
standardize
on
rules
which
rules
do
we
want
to
standardize
on?
Can
we
find
a
common
ground
to
e,
to
a
define
them
and
and
b
manage
them
will
be
in
a
longer
discussion,
but
my
proposal
is,
I
think
it's
also
what
microstorages
work
on.
Can
we
agree
on
a
user-facing
api
first,
because
if
we
can't
agree
whether
we
call
it
has
feature
or
is
feature
enabled,
then
we
won't
get
any
further.
A
But
if
you
don't
say
well,
this
is
kind
of
doable
and
I
know
that
mighty
house
has
done
some
work
already.
I'm
seeing
how
it
fits
together
with
the
with
the
other
approaches,
what
it
might
be
still
message:
signature
changes,
method,
name,
changes,
that's
really
where
it
would
start,
because
if
you
can
get
this
done,
it's
a
good
first
step.
A
C
Yeah
sure
yeah
I
mean
I
I
think,
there's
definitely
you
can
you
can
definitely
it's.
You
know.
They're
called
what
you're
talking
about
the
core
use
case:
they're,
simple,
right,
they're,
boolean
generally
so
yeah.
It's
just
I'd,
just
be
curious
to
know
what
the
kind
of
like
medium
to
long-term
trajectory
of
of
the
of
the
project
would
be
really,
but
I'm
sure
you
can
you
can
def.
A
A
A
I
want
to
play
around
with
them
and
I
want
to
communicate
them
to
my
resume
team
and
I
might
not
even
care
which
tool
they're
using
because
actually
it
might
be
a
different
tool
that
I'm
using,
I
might
be
totally
fine
with
the
github
space
open
feature
implementation,
but
for
some
more
complex
or
more
advanced
workflows
that
the
sre
teams
are
using
or
that
feature
rollout
as
part
of
customers
is
used
and
other
things
that
I'm
not
even
involved
in
like.
If
I'm
writing,
say
the
new
card
feature.
A
I
want
to
tell
you
how
you
can
actually
enable
it.
That's
it's
available
in
the
code
but
which
uses
I'm
going
to
roll
it
out,
based
on
like
behavior
and
like
business.
Metrics
like
heart,
values
and,
like
other
topics,
isn't
actually
even
my
business,
and
I
might
even
not
care
about
because
it's
the
product
management
team,
the
line
of
business
teams
that
take
care
of
it
and
the
more
we
move
like
away
from
the
unified
implementation
topics.
What
we
do
there
and
at
some
point
it
will
be
just
a
cutting
point
where
we
say
well.
A
This
is,
I
think,
where
it
makes
sense
for
this
developer
focus.
That's
also
why
we
call
it
developer
first
use
case
into
more
of
an
end-to-end
platform
use
case,
so
the
goal
is
not
to
build
like
a
massive
end-to-end
platform
for
enterprise.
Great
feature
management,
with
everything
that
you
have
in
there,
but
other
things
might
make
sense
like
if
we
get
all
the
features
that
are
enabled
or
not
just
exposing
simple
prometheus
type
of
metrics
about
what
we're
already
collecting
on
feature.
A
Requests
might
still
be
useful
for
other
people
as
well,
but
I
hope
it
makes
it
a
bit
clearer,
but
I
think
that
the
point
is
once
it's
beyond
this
is
the
feature
here.
You
can
turn
it
on
and
off
some
rules,
but
the
other
workflows,
I
think,
won't
make
it
in
there
I
mean,
maybe
at
some
point
we
we
find
a
way
that
okay,
we
actually
agree
on
even
more.
F
F
Probably
jump
in
real
quick
too,
so
I
did
do
some
research
based
on
flagsmith
and
launch
darkly
and
unleash
so
far
and
there's
there's
a
lot.
You
know
obviously
like
the
method,
names
and
stuff
are
all
different,
but
in
terms
of
functionality,
they're
they're
pretty
similar,
at
least
from
like
the
sdk
standpoint,
and
so
that
was
the
first
approach
that
I
took.
A
You
wouldn't
have
to
say
well
it's
great
that
you
took
open
source
sdk,
whatever
it
is,
and
now
you
want
to
switch
over
to
a
different
backend.
That's
also
how
to
alex's
point
how
telemetry
is
differentiating.
You
don't
have
to
touch
your
entire
code
again
and
then
again
you
might
use
third-party
components.
A
I
think
link
id
would
actually
be
a
great
example
for
a
service
mesh,
so
service
meshes
themselves
might
expose
some
of
their
configurations
and
some
of
their
features
also
via
open
features,
so
that
you
can
then
even
control
them
and
turn
them
on
and
off
which
you
couldn't
do
today.
You
would
have
more
or
less
to
learn,
okay,
how
is
this
thing
even
configured
and
and
which
features
might
have
been
using
as
well.
A
That's
great
to
get
it
oh
interesting,
like
all
feature,
flagging
providers,
vendors,
whatever
we
want
to
call
them
sdks-
are
open
source
anyways,
so
we're
just
making
something
open
source
that
is
already
kind
of
like
open
source
today,
except
that
there's
like
seven
eight
different
versions
out
there.
That's
why
I
think
if
the
sdk
agreement
is
there,
that
was,
I
remember,
very
early
discussions.
We
also
had
around
open
telemetry.
We
all
agreed
that
we
had
a
large
number
of
engineers
like
in
the
case
of
dynatrace.
A
It
was
close
to
100
engineers
just
working
on
instrumentation.
If
we
can
cut
this
down
in
half,
it
would
be
great.
It
get
the
same
data
quality
that
was
a
massive
business
driver
for
us
back
then
as
well.
So
that's
why
I
also
think
like
having
this
sdk
like
very
high
level
and
abstract
inspect
type
performance.
The
same
way
like
an
open
telemetry
defines
also
in
their
specs.
A
In
there,
in
a
way
that
it's
still
compatible
with
the
users,
this
is
still
something
where
we
have
to
think
through
yeah.
I've
been
pretty
nervous
that
I'm
not
a
big
fan
of
distributions
per
se,
because
they're
confusing
sometimes
but
like
especially
having
a
dedicated
layer-
and
I
think
the
layer
here
is
clear.
A
A
A
A
Even
if
you
look
at
projects
like
open,
telemetry
like
open
parameter
is
great,
but
by
itself
you
don't
get
any
data.
You
need
to
connect
it
to
your
prometheus
to
your
jaeger
and
other
solutions,
and
we
have
to
ensure
the
developer,
focused,
end-to-end
experience
and
that's
like
the
the
minimum
piece
that
we
should
put
into
the
open
source
end-to-end
solution,
which
I
believe
leaves
a
lot
of
room
for
everybody
here
to
still
build
additional
functionalities
and
capabilities.
On
top
of
it.
A
Yeah
two
things:
our
biggest
internal
demand
right
now
is
server
side,
most
of
the
pro
approaches
and
the
usage
of
our
customers.
Right
now
is
the
server
side.
It
was
just.
We
brought
it
up
servers
at
first,
because
that
was
our
most
of
our
also
internal
demand
was
we're
not
saying
that,
like
client
side
is
less
interesting
or
less
relevant
in
server
side.
This
was
just
purely
driven
by
by
demand
honestly
that
that's
all.
F
And
probably
the
kubernetes
and
open
telemetry
stories
work
slightly
or
definitely
work
better
on
the
server
side
at
this
point,
but
it's
definitely
come
up
a
number
of
times,
even
on
the
github
org.
Someone
asked
about
the
client
side,
so
it's
something
we'll
have
to
at
a
bare
minimum:
have
a
plan
for
and
some
documentation
around
that-
and
hopefully
you
know,
have
some
proof
of
concept
out
sooner
than
later.
How
we
can
support
that.
A
F
H
D
Half
of
those
are
client
sides,
just
I
know
a
data
point.
You
know
we
emphasize
that.
I
think
there
is
a
need
for
client
side.
It
will
vary
depends
on
the
company
that
is
willing
to
use
you
for
what
those
are
cons.
You
know
more
consumer
base
tend
to
be
really
more
kind
inside,
but
it
comes
at
its
own
challenges,
of
course,
collaborative
perspective.
F
H
Work
on
this
another
topic
for
research
would
be
to
define
what
future
flag
is
in
terms
of
data,
for
example,
well,
basically,
foundation
for
api,
so
describing
what
data
would
you
provide?
What
would
be
at
least
expressions
conditions
and
the
use
cases
you
would
like
to
support,
because
I
believe
it
will
be
the
most
of
the
complexity
of
the
specification
and.
D
D
D
You
have
correct
yeah,
I
believe
we
were
the
first
ones
and
then
ld
launched
the
same.
So
in
a
way
we
kind
of
agree
on
basic
capabilities
already
there
and
I
wouldn't
call
it
heavily
used,
but
they
have
more
than
50
or
60
or
70.
At
this
point,
if
you
know
more
installation
so
maybe
worth
looking
at
it
is
that.
F
A
A
F
Yeah,
I
think
it's
very
valuable
to
have
at
least
two
feature
flag
systems
in
here,
so
we
can
really
get
some
interesting
perspectives.
I
think-
and
hopefully
that
really
helps
make
sure
we
don't.
You
know,
fall
into
mistakes
that
you
guys
have
already
kind
of
solved
so
yeah.
I
definitely
try
to
leverage
your
expertise
in
this
area.
F
A
Deliberately
not
pushing
something
out
there
and
wanted
to
get
together
with
the
group,
because
we
want
this
to
be
a
collaborative
project
and
not
like
this
is
what
we
want.
Well,
you.
I
want
all
of
you
to
actually
work
with
you
on
this,
so
I
think
for
the
next
meeting
bye
battle
mike.
I
think
we
should
really
discuss
the
first
version
of
what
an
api
could
look
like
based
on
your
findings
and.
F
Yeah,
I
think,
maybe
for
the
next
one
I
could
even
potentially
have
some
code
samples
or
something
ready.
So
we
have
something
to
look
at.
If
that
would
be
helpful,
maybe
it
would
help
bring
it
to
life
a
little
bit
more.
If
I
could
show
a
basic
idea
and
a
maybe
a
high-level
spec
and
chat
about
that,
there's
also
some
you
know.
D
F
A
Sure
is
the
time
by
the
way
today,
good
for
everybody,
because
if
you
set
up
the
meeting
cadence
this
time
should
work.
I
mean
today,
everybody
had
time
and
we
had
to
bring
a
lot
of
time
zones
together,
which
is
always
very
hard.
So
I
think
it's
the
hardest,
usually
for
the
people
on
the
west
coast,
because
they
have
to
do
that.
It.
F
K
A
K
A
A
C
C
You
know
very,
very,
very
low
latency,
and
so
maybe
this
is
just
because
we've
been
working
on
this
a
lot.
But
that's
the
thing:
that's
in
the
front
of
my
mind
is
is
that's
a
that's,
a
big
question
and
it's
something
that
is
less
relevant
on
client-side
sdks,
so
yeah
how
that
works
and
or
maybe
there's
like
different
operation
modes
or
something
but.
F
Yeah,
I
mean
that's
a
good
point.
I
mean
especially
us
being
dinosaur
in
a
monitoring
company.
If
the
feature
flight
system
introduced
like
a
half
second
latency,
it
would
be
totally
obvious
and
pointing
you
know
completely
to
the
feature
flight
system
itself,
so
it's
something
that
would
have
to
be
incredibly
low,
latency
and
the
tests
that
I've
run
so
far.
This
is,
I
haven't,
run
load
tests
or
anything
on
there,
but
taking
advantage
of
like
a
sidecar
process,
it
does
have
extremely
low
latency.
F
There
are,
it
is
higher
latency
than
running
in
process,
so
we'd
have
to
kind
of
chat
about.
If
that
the
benefit
outweighs
the
negatives,
but
it
would
allow
us
to
effectively
write
a
singles
rules
engine
and
make
the
clients
themselves
incredibly
lightweight
and
and
that
that
would
also
mean
like
if
flagsmith
you
know,
wants
to
add
in
their
client
or
their
business
logic
or
whatever
you
could
inject
it
into
that
sdk
itself.
So
that's
kind
of
where
my
head
is
right
now,
but.
D
H
G
G
First
couple
of
architecture
meetings
I,
let's
not
just
get
stuck
straight
into
it-
let's
actually
figure
out
minimum
viable
products.
You
know
that
what
is
it
we
want
to
build
as
a
kind
of
v1
and
then
we'll
let
everything
else
come
through,
because
if
we
start
weeding
around
and
is
it
going
to
use
the
golang
unix
sockets
or
is
it
going
to
be
a
wasn't
built?
You
know
like
this
is
the
wrong
approach.
So,
let's,
let's
really
get
that
architecture
spec
down.
G
G
A
Yeah,
that's
why
I
also
want
to
go
as
quick
as
possible
to
have
something
as
a
discussion
basis,
because
it's
always
easier
to
discuss
something.
That's
like
very
completely
there,
and
even
when
people
say
they
don't
like
it.
We
talk
about
something
very
specific
where
things
would
not
fit
together
and
that's
why
we
propose
like
really
throughout
like
the
serious
year.
One
very
first
drafted
then
have
people
start
commenting
on
it,
but
doing
so.
We
wanted
to
have
agreement
in
this
round
first,
that
they
don't
feel
okay
like
we're
just
throwing
something
out
there.
G
F
A
I
mean
the
only
thing
I
would
not
like
put
too
much
into
this
customization
for
the
open
source
project.
I
think
we
can
still
bring
up
this
discussion
in
that
round
like
how
people
can
build
commercial
solutions
on
top
of
it,
like
also
like
thinking
from
an
open
source
perspective,
it
shouldn't
feel
like
that
open
core
projects
we're
all
building
it
should
it
sort
of
must
technically
be
possible
to
use
it,
as
is
if
the
only
thing
you
want
to
do
is
turn
feature
flags
well,.
A
Yeah,
I
wouldn't
just
put
it
in
like
the
intent
of
the
open
source
project,
it
everybody
yeah
making
money,
but
it
might
feel
weird
to
somebody
using
it.
Okay,
getting
me
something
vendor
independent,
just
to
sell
me
something
right
the
next
day.
I
think
it's
just
more
perception
than
anything
so,
but
enabling
advanced
features,
how
they
can
be
implemented
and
so
forth
is
maybe
the
better
wording.
Honestly
and
technical
is
a
better
burden
to
sell
the
commercial
product.
C
Yeah
I
mean
I,
I
think,
there's
a
nut.
I
feel
like
there
will
be
a
natural
lowest.
Common
denominator
is
not
quite
fair
but,
and
I
think
there
will
be
a
natural
level
where,
if
you
try
and
abstract
you
know,
with
what
higher
high
level
features
it
it,
it
will
be
impossible
so
yeah
I
I
I'm
just
going
to
speak
for
myself,
but
I
don't.
I
don't
see
that
being
an
issue
because
I
I
just
think
yeah
it'll
be
impossible
to
come
up
with
a
specific.
You
know.
C
C
You
know
we're
coming
more
more
at
it
from
an
engineering
side
and
just
I
think,
they're
you
know,
the
requirements
are
always
there's
they're
always
different,
and
I
mean
you
know
if
it
was
server
side.
Only
then
I
mean
most
of
our
customers
have
client-side
implementations,
but
every-
and
I
guess
if
the
specification
came
to
cover
that
I
still
think,
there's
there's
points
of
difference
around
you
know
a
you
know:
api
hosting
and
low-latency
things
around
that
and
you
know
likes
already
been
mentioned.
F
F
F
A
Okay,
yeah,
but
let's
really
try
to
get
the
first
version
out
to
get
the
teammate
together
and
have
some
asynchronous
collaboration
that
we
have
things
to
discuss,
especially
on
the
api
side
and
getting
things
out
there
again,
maybe
also
last
but
not
least,
all
of
they
work
right
now
done
on
open
feature.
I
mean
we
moved
it
into
the
cnc
after
every
foundation,
governed
that
it's
not
like
driven
by
one
organization
but
rather
foundation
managed.
But
everything
even
right
now
is
all
apache
2
licensed.
H
What
you
will
need
to
do,
or
you
need
to
stop
a
bootstrap
governance,
so
there
is
some
charter
draft
in
the
community.
I
do
not
think
that
today
is
right
time
to
discuss
it,
especially
timing,
but
for
the
next
meeting,
something
I
would
definitely
suggest
so
that
we
discuss
how
this
works.
How
many
members
we
have?
Who
would
be
these
members
and
how
we
organize
the
elections
going
forward.
A
H
Yeah,
so
the
chatter
is
already
published,
so
thanks
to
daniel
for
feedback
to
michael
but
yeah,
everything
is
up
for
changes.
So
if
you
have
strong
opinions
about
how
governance
should
work,
how
we
can
ensure
vendor
neutrality,
assuming
that
there
will
be
multiple
participants,
then
please
feel
free
to
contribute.
There
is
governance
charter
in
the
community
repository
and
basically
any
comments
and
get
back
would
be
also
appreciated.
H
One
question
before
we
close
down
so
my
interpretation
of
the
current
project
status
is
that
it's
public,
but
we
fly
behind
below
the
riders,
so
we
don't
do
white
announcements
and
social
media
etc,
but
basically
people
are
free
to
talk
about
it.
Is
it
the
correct
interpretation
of
the
current
stage.
A
I
would
just
refrain
from
like
reaching
out
wider
to
user
audience
a.
We
have
nothing
implemented
yet
number
one
that
people
can
actually
really
comment
on
and
it
cannot
really
be
used
by
anybody.
So
that's
where
it
does
not
figure
out
which
outreach
is
mostly
with
interested
parties
right
now,
because
if
an
end
user
would
look
at
the
current
repos,
what
should
they
do?