Open Source Governance - The Hard Parts

Open Source Governance:
The Hard Parts
DevOpsDays Vancouver 2017
Nell Shamrell-Harrington
@nellshamrell

What do you think of when
you hear
Open Source?

What makes a project
Open Source?

Open Source Governance - The Hard Parts @nellshamrell

Uploading a project to
Github is easy…

Successfully governing
a project is much harder

Technical and
communication skills are
intertwined

Parts of open source that
touch both technology and
humanity are the hardest…

…but they are also
the most vital

Successful Open Source
governance is never
easy, but it is possible

@nellshamrellOpen Source Governance - The Hard Parts
• Sr. Software Engineer at Chef Software
• Open Source Contributor and Maintainer
• Supermarket
• Habitat
• @nellshamrell
• nshamrell@chef.io
Nell Shamrell-Harrington

Duties of
Open Source Governance

• Make it easy to contribute
Duties of Open Source Governance

• Assist users of the project

• Assist users of the project
• Manage contributions to the project

First Duty:
Make it easy to
contribute

But what happens
between these two steps?
(Hint: a lot)

• Setting up a development environment
Hard parts

• Setting up a development environment
• Testing changes
Hard parts

“Just don’t use x”
is the wrong answer

User Workstation
Vagrant
Development
Environment
$ vagrant ssh

User Workstation
Docker
Container
Development
Environment
$ docker run

You must support
the development
environment

Use a continuous
integration environment
for testing

Consistent development
and testing environments
are hard, but possible

Second Duty:
Assist users of the
project

• Replicating an issue
Hard parts

• Replicating an issue
• Dealing with an upstream issue
Hard parts

How do you replicate
an issue in a different
environment?

What might be obvious to
a maintainer is not
always obvious to a user

What if the issue is
actually with an
upstream project?

If it manifests in
your project, it is
your problem

• Communicate it to the maintainers of
the upstream project
Dealing with an upstream issue

• Communicate it to the maintainers of the
upstream project
• Communicate it to the person(s) who
ﬁled the issue

• Communicate it to the maintainers of the
upstream project
• Communicate it to the person(s) who
ﬁled the issue
• Update the issue in your project
regularly with progress

If the upstream maintainer
does not ﬁx the issue,
change the dependency

Replicating bugs and
upstream issues are
hard, but possible

Third Duty:
Managing contributions
to the project

• Determining whether a contribution
adds value
Hard parts

• Determining whether a contribution adds
value
• Saying no when it does not
Hard parts

• Documentation (please!)
Add Value

• Typo ﬁxes
Add Value

• Typo ﬁxes
• Small bug ﬁxes
Add Value

• Whitespace changes
Does Not Add Value

• Whitespace changes
• Large features (without talking to the
maintainer ﬁrst)
Does Not Add Value

• Small features (less than100 lines non-
test code)
Sometimes Add Value

• Small features (less than100 lines non-
test code)
• Large features (if you talk to the
maintainer ﬁrst)
Sometimes Add Value

How do you tell whether
something adds value?

• Does it ﬁx an existing issue?
How do you tell if it adds value?

• Does it replicate work done
elsewhere?

• Does it replicate work done elsewhere?
• Does it affect in progress work?

A contribution returns
negative value when it makes
other contributions harder.

When it does not
add value, communicate
and be supportive

Open source projects
live and die by
community engagement

Always, always,
always say thank you

Always, always,
always say why

Determining value and
communicating is hard,
but it is possible

Open Source Governance - The Hard Parts

More Related Content

What's hot

Viewers also liked

Similar to Open Source Governance - The Hard Parts

More from Nell Shamrell-Harrington

Recently uploaded

Open Source Governance - The Hard Parts