99 Ways to Ruin and Open Source Project

# 99 Ways to
# Ruin
# — an Open Source Project —

???

Good morning, welcome, and thank you for coming to "99 Ways to Ruin an Open Source Project".

---
class: dark, middle, center

> …free as in _freedom_, not as in _beer_.

---
class: dark, middle, center

> …free as in _puppies_, not as in _beer_.

---
class: statement

# Open source projects are like puppies:

- they are fun and cute when they are young

- they ruin everything you own and your social life

- they are incredibly resilient

- they can be trained

- their shortcomings are often a failure of the owner

- they eventually get old and boring

---
class: statement, middle

# but puppies don't _mean_ to
# .huge[ruin everything]
.right.bottom.absolute[![](images/puppy.png)]

???

They're _puppies_! They just want to play, snuggle, eat and sleep.

In the open source world, we all are like puppies as well. As users and maintainers, we just want to do our job and enjoy it. But in the process, we do things that harm projects and people.

---
class: dark, middle, center
name: non-events-and-paper-cuts

# .tiny-headline[open source projects are ruined by]
# .fancy-headline[the accumulation of]

.pull-left.right[.emojicon.nonevent[] non-events]
.pull-right.left[.emojicon.papercut[] paper cuts]

???

The reality is, open source projects are incredibly resilient. Rarely is there a single event that permanently ruins a project.

Open source projects are generally ruined by an accumulation of:

- non-events: absence of vital information, lack of communication
- paper cuts: small offenses that alone are not a big deal

as these two things accumulate, they cause lasting harm to the project.

Projects miss opportunities to gain new users and contributors as they move on to other projects that are more stable.  Contributors burn out and the project is left to wither.

---
background-image: url(images/bkeepers.jpg)
background-size: cover
class: section, dark, bottom, text-shadow

# Hello, I am
# @bkeepers

???

Hi, my name is Brandon Keepers. I lead up our open source efforts at GitHub.

Part of my job is to make it difficult for people to do the things that cause harm to open source projects. Today I will share with you some of the things I have learned. You can use this power for good or evil. With great power comes great responsibility.

Just a word of warning in case it isn't already obvious. This talk may contain excessive sarcasm.

---
name: outline
class: section, overview, middle

# How to Ruin the:

0. [Motivation of Maintainers](#contributors)
0. [Confidence of Users](#users)
0. [Integrity of the Code](#code)
0. [Reputation of the Project](#reputation)
0. [Trust of the Community](#community)

???

I have grouped the non-events and paper cuts that ruin projects into five categories…

This is by no means an exhaustive list, but these are things I've noticed in projects over the past few months.

So, all the advice I received when getting feedback on this presentation is that I shouldn't feel the need to list all 99 ways. So, in the spirit of ruining things, I ignored that advice. On the plus side, the great thing about numbered lists, is that they give you a counter. So if you're sitting there wondering, "how much longer is he going to drone on about the destruction of humanity?", you have a counter.

---
class: section, middle
name: contributors

# How to Ruin the
# Motivation of Maintainers

???

As users of an open source project, there are countless me can make life more difficult for other users and maintainers. The important thing is that you focus on our own needs.

---
class: meta-example

# Avoid giving any constructive feedback.

---
class: example

# Don’t report friction that you experience.

---
class: example

# Don’t report errors that you encounter.

???

It's probably just your machine, so it's not really worth taking the time to report it. Besides, if it really is an issue, I'm sure it'll effect many other people, and since something like 5% of users report errors they encounter, it'll get reported eventually.

---
class: example

# Report issues with as little detail as possible.

![](images/issue-no-description-provided.png)

---
class: example

# Complain about the project on Twitter.

---
class: meta-example

# Waste the time of the maintainers.

---
class: example

# Don't read the contributing guidelines.

---
class: example

# Ask lazy questions.

![](images/lazy-questions.png)

???

It's way more efficient to ask someone else to look up the answer than it it so figure it out for yourself. So if you have a question that you're too lazy to find the answer too, ask the maintainers.

---
class: example

# Don't read the docs before asking questions.

---
class: example

# Email the maintainers to ask for help.

---
class: meta-example

# Make your contributions difficult to accept.

---
class: example

# Open pull requests without a description.

![](images/no-description-provided.png)

---
class: example

# Avoid following the existing styles.

???

Let's be honest. Your coding style is better than this crappy project. Consistency is overrated. You can submit another PR to update the rest of the styles after this one is merged.

---
class: example

# Change the style of unrelated code in your pull request.

---
class: example

# Open pull requests with tons of changes.

![](images/diff-too-big.png)

---
class: example

# Open pull requests with changes that you know won’t be welcome.

---
class: meta-example

# Make maintainers question the reason for their own existence.

---
class: example

# Use 👍 and `+1` as much as possible.

???

---
class: example

# PING

---
class: example

# Demand that your issue be fixed right now.

---
class: example

# Spew hatred at the maintainer.

![](images/spew-hatred.png)

---
class: example

# Dog-pile on contentious discussions.

…184 previous comments, and then…

![](images/dog-pile.png)

---
class: example

# Never show appreciation for all of their hard work.

---
class: section, middle
name: users

# How to Ruin the
# Confidence of Users

???

So those are some ways we can make life miserable for maintainers.

Most open source projects start with code and no users. In this section, we'll talk about how to keep it that way.

---
class: meta-example

# Make it difficult to understand what the project does.

???

You can do this in several ways…

---
class: example

# Don't include a description.

---
class: example

# Use an incredibly vague description.

---
class: example

# Don’t include a `README`

![](images/readme.png)

???

The best users will just look at the code and know what it does and how to use it. If you add a README, then less-skilled users may discover it, and ain't nobody got time for that.

---
class: meta-example

# Make it difficult to get started.

---
class: example

# Don’t tell people how to use it.

---
class: example

# Don't bother with package managers

???

It's so much work for you to put together a package. Just waste your time. Let every user deal with the hassles of installing it on their own.

---
class: example

# Use undeclared dependencies.

???

Package managers are trying really hard to make it easy to manage dependencies. We need to fight against this. Avoid declaring your dependencies.

---
class: example

# Make it un-configureable.

```
$ patch -p1 < changes-to-make-it-work.diff
```

???

Hard code it to your environment, or make configuration something that happens at build time instead of run time

---
class: example

# Require excessive configuration.

???

Bonus points if you can use XML.

---
class: meta-example

# Make releases unreliable.

???

Despite these attempts, some people may still try to use your project. So the next strategy is to make it difficult for them to keep up with it…

There are many ways to do this.

---
class: example

# Avoid roadmaps.

???

We all know that most software companies don't believe in planning. We call it being "agile". What's more agile than not having a plan at all?

I've found it's best to let each release be like present, where the user doesn't know what they get until they open it up.

---
class: example

# Release as irregularly and infrequently as possible.

???

People love consistency, so don't give it to them.

---
class: example

# Release after every single change

???

or better yet, release as often as possible, like after every change.

---
class: example

# Delay releases with critical bug fixes.

---
class: example

# Make drastic changes between versions.

---
class: example

# Make breaking changes in minor releases.

???

Have you heard of semantic versioning? This is the idea that the version number communicates the type of changes included in a release.

Don't follow it.

---
class: example

# Don't provide an upgrade path between version.

???

After you make breaking changes, it will probably be a little painful for some of the biggest users to upgrade. There are things you can do to make it easy for them, but don't.

This is a good opportunity for them to consider moving on to another project.

---
class: example

# Forget to mention known limitations.

???

Those limitations will probably only effect the few people that heavily invest in the project, so there's no need to scare away everyone else immediately.

---
class: section, middle
name: code

# How to Ruin the
# Integrity of the Code

???

Those are some ways to ruin the confidence of users in our project.

Even if we do that, some people might still find our code useful, so let's see what we can do to change that.

---
class: meta-example

# Introduce some legal ambiguity.

???

A non-technical way to do this is to…

---
class: example

# Don’t apply a proper open source `LICENSE`

???

You own the copyright of your code by default and other people don't really have permission to use and modify it. So create something useful, dangle it out there in front of the community's face, but don't license it for reuse.

---
class: example

# Use a `LICENSE` that is inappropriate for the intended use.

???

There are over 60 licenses that fit the open source definition and are approved by the Open Source Initiative, and many of them have a compelling reason for their existence.

For example: say you write a library for handling credit cards. Use the GPL, a copyleft license that ensures any other code used with it must also be open source. That way, anyone that uses it has to release all their source code. Not only is this is the right thing to do for freedom, it guarantees that very few people will use it.

---
class: example

# Use a non-standard license that hasn't been vetted by the community.

???

WTFPL, Beerware

---
class: example

# Violate someone else’s copyright, patents or trademark.

---
class: meta-example

# Have as many dependencies as possible.

???

We live in a world of finite resources, so code reuse is one of the most important things. The great thing about dependencies is that they allow you to shift the blame for bugs. When a user has a problem using your project, you're not responsible for helping them.

---
class: example

# Depend on many trivial libraries.

???

There are a lot of little libraries out there for doing trivial things. Use all of them. If they save you from writing a few lines of code, then it's a justifiable dependency.

---
class: example

# Have a lot of transitive dependencies.

???

Choose libraries that also depend on a lot of other libraries.

---
class: meta-example

# Make the code difficult to read.

---
class: example

# Prefer clever code over clear code.

???

I love that moment where I'm trying to figure out how a piece of code even works, and after reading through it a few times, I find some little clever trick and have that "aha" moment.

---
class: example

# Don’t follow a style guide.

---
class: example

# Avoid community conventions.

---
class: example

# Use inconsistent conventions.

---
class: meta-example

# Make the code susceptible to breaking changes.

???

The code may have been solid when you released it, but over time there are a lot of opportunities to make it less stable.

---
class: example

# Don't write tests.

???

Don't bother with tests. They are a lot of work. They require you to think differently about how you structure your project. And eventually they will all be broken anyway.

---
class: example

# Don't use continuous integration.

???

Make contributors run the tests manually.

---
class: example

# Accept every single pull request.

???

Pull Requests are like puppies, and puppies are great at destroying things.

---
class: section, middle
name: reputation

# How to Ruin the
# Reputation of the Project

---
class: example

# Attract users before it’s ready for prime time.

---
class: meta-example
# Use a name that is impossible to remember
---
class: example
# Use a name that is unpronounceable
---
class: example
# Use a name that is offensive
---
class: example
# Use a name that is a really cleaver pun.

???

Most people hate puns, so not only will they not remember the name, they’ll be annoyed when they realize what it means.

---
class: example
# Use a name that is un-google-able
---
class: example

# Change the name after the project is gaining momentum.

---
class: meta-example

# Avoid any form of marketing.

---
class: example

# Don't build a project website.

---
class: example

# Never blog about it.

---
class: section, middle
name: community

# How to Ruin the
# Trust of the Community

---
class: meta-example

# Exert excessive control.

---
class: example

# Never give anyone else commit access.

---
class: example

# Require a 👍 from one person.

---
class: example

# Ignore concerns voiced in issues.

---
class: example

# Refuse to implement often-requested features.

---
class: meta-example

# Poorly manage contributions.

---
class: example

# Don’t accept any pull requests.

---
class: example

# Don’t give any feedback on pull requests.

???

Pull requests are intended to be conversations, but many projects treat them as
Merge or close as-is with no interaction.

---
class: example

# Take forever to reply to pull requests.

---
class: example

# Give overly blunt feedback on pull requests.

---
class: example

# Give pedantic code reviews.

---
class: example

# Commit to reviewing changes on a specific date, but don’t.

---
class: example

# Never show appreciation to contributors.

---
class: example

# Require sending a FAX before contributing.

---
class: meta-example

# Restrict the available communication channels.

---
class: example

# Don't create a mailing list.
---
class: example

# Don't create a chat room.

---
class: meta-example

# Let inappropriate behavior go unchecked.

???

The internet can be a horrible place. Sure, being the maintainer, you could help set the tone and make the project a safe and welcoming place.

But don't.

---
class: example

# Marginalize women.

---
class: example

# Comment on how someone's avatar looks.

---
class: example

# Marginalize minorities.

---
class: example

# Ridicule non-native English speakers.

---
class: example

# Ridicule n00bs.

---
class: example

# Ignore offensive behavior.

---
class: example

# Spend all your energy feeding the trolls.

---
class: example

# Don’t adopt a code of conduct.

???

There's been a trend of projects explicitly communicating their values & intentions. This has a tendency to make projects feel like a safer place for more people.

---
class: meta-example

# Create a power and information imbalance.

---
class: example

# Make important decisions in private channels.

---
class: example

# Put your needs over the community

---
class: example

# Treat contributors as free labor.

---
class: dark, middle, center

# .fancy-headline[Let's Review…]

---

---
template: non-events-and-paper-cuts

???

All

---
class: statement, middle

# .tiny-headline[In my experience, harm is caused by the]
# failure to establish good patterns.

???

In my own experience, open source projects are ruined by the failure to address repeated  non-events and papercuts. These are systematic failures, and I think it's the project owners' responsibility to address them.

- identify common sources of friction for users and document/fix them
- document a release process
- establish a code of conduct and set the tone
- habits of reviewing PRs and responding to issues

---
class: middle, dark

# .tiny-headline[Bad things may still happen, but]
# .fancy-headline[they won't accumulate.]

???

The job of the maintainer is to identify patterns, encourage the constructive ones and mitigate the destructive ones.

---

# Thanks for listening!
# @bkeepers
# bkeepers@github.com