1 of 38

Slide Notes

DownloadGo Live

From First Look to First Pull (OSCON 2016)

Published on May 06, 2016

I spoke about contributing to Open Source from the viewpoint of the distractions and problems you'll face. There are many reasons to contribute to OSS, but so many ways and reasons (mostly internal) to avoid it!

How do you circumvent these problems? Why is motivation is better than time management? What is YSAAS?

This talk sought to answer these questions and many more, with humor and empathy and respect for contributors past , present, and those yet to contribute.

Here is a video of me presenting the talk.

PRESENTATION OUTLINE

From First Look to First Pull

Contributing to your Favorite Open Source Projects
Photo by toolmantim

I

so do you.
Hello everyone!

My name is Quinn Murphy, and I do love OSS. And I love starting to contribute and help my favorite projects grow.

What I want to talk to you about today is what I learned about OSS and myself when I started.

What I want when I am finished is for *you* to know that you can start contributing yourself.

Rules versus Real Life


A bit about myself.

I am a system administrator, and while I do code (in Perl and way too much Bash), that hadn't been where I'd spent most of my time. I have gaps of skills and process...


I managed a team of 6, have a son and wife, write and design games...I have a time deficit as well.

So basically, though there were a lot of great rules and setups for getting started contributing to open source, I found relatively few were dealing with my problem -- real life.

Real life is an angry dog that is barking at you, keeping you from your work.

FEAR
TIME
SKILL

But what if the dog is you?

Let's just get over the weird visual of you barking at yourself and assume that this was a smooth metaphor for a second...

Real life is real, but what has kept me and so many others I know from making contributions are:

Fear: fear of not fitting in, fear of not measuring up

Time: I mentioned this but let's also say that time is what you make it. It's about proritizing more than scheduling.

Skill: sometime's you're not *afraid* you don't measure up, you just don't. *Yet*

It's WHO YOU BECOME, NOT WHO YOU ARE.

What I've learned in the last few months:

Open Source really needs the person you are going to become, not the person you are.

ROAD TRIP

I have heard far too many people compare themselves to the greats, but even the greats have been on a trip.

The greats are great, in fact, because they don't stop their journey.

What I've decided, what you have to decide, is to get on the road.

Getting Started

So...let's take a trip.

THE ITCH


Having a github account is just convenient on multiple levels! I put some of my own fledgling repos and gists up there, but I was mostly using Github as a one-stop software shop.

Then last year, I got the Itch.

I love the idea and the implementation of OSS so much that "giving back" became a primary motivation.

Where to Start?

Solving your own problems.
Let's hear it for nebulous goals!

"Giving back" isn't, as it turns out, enough to start. Where do I start? What do I work on?

Well, what am I working with at the moment? What are my problems?

Photo by mindgutter

Just my (Book)Type

So, let me tell you about some software I work with and love.

Booktype lets you build print, ebooks and pdfs with a single button click. It supports group editing, roles (like authors and editors), and versioning. It uses CSS to create elegant layouts and is a great choice to use for book sprints.

One of the things I do is make storytelling games. I use Booktype to help me make books. I loved it from the first time I used the demo.

https://omnibook.pro


You should try a demo at https://omnibook.pro. It's completely, totally free and you can test drive making your own books with it.

---

So now an open source project I'm demoing, and I really want to create my own instance to work with. I go through the documentation for the install that's on github.

The only problem being...

Which Documentation?

....which documentation? The documentation was fragmented across versions and locations, none of it sufficient for me to get a full install going.

I spent a lot of time trying to get this set up. I wanted to have my own instance!

Luckily for me, this was my...

First ProbLEM

Let's Do This
...First problem! You like problems when you are looking to get involved in a project because they offer opportunities to start work.

More importantly...this is what OSS is all about. It's about identifying problems and then owning them.

There's a problem here...can I fix it?

That is when you reach out for help. I sent an email to the awesome people at Sourcefabric. It was Julian Sorge who pointed me at Daniel James, who asked:

"Did you read the Digital Ocean docs?"

Oh. I hadn't found those in my searches and they weren't linked to on the github docs.

And that's how I made my first pull request.

The First Pull Request...


I asked:

"Can I...put this in the README and make a pull request?"

"Go ahead."

It can often work just like that. I solved a real problem by looking around and reaching out.

If you can see problems, you can *solve* problems.

Yay for me!
Photo by roger_ipa

But Code Tho...

But my problem was that I dreamed of contributing code. I wanted to contribute some tool or feature to an OSS project. Improving documentation is absolutely necessary and important, but I was starting to get in touch with my selfish, less than altruistic motives for wanting to contribute to open source.

I didn't just want to give back; I wanted to get better. You get better at real coding in my experience by contributing to real code.

I don't believe that non-code contributions are second-class citizens in OSS projects. So many projects need better information or tools or design to push them to that next level.

It' just that my focus was on getting better at coding, and I wanted to shift my focus from Perl to Python.

CONSUMER TO CONTRIBUTOR

But how can I contribute code when I'm not a great coder?

The Definitive Guide to OVercoming Your Fears

  • Uhhhh.
  • Hmmm.
  • Don't think about it?
  • Panic?
I asked myself this question, and I've heard other raise this question, so I decided to make this slide, which is, as far as I know, the *definitive* guide to overcoming your fears. It's Creative Commons Attribution License, so remember where you heard this, OK?

Step 1. "Uhhhh"
...which rolls right into Step 2,"Hmmm."
In Step 3 I offer you the ability to step out of the problem altogether by not thinking about it.

If the previous steps do not help you, I suggest you panic.

Run for the Hills! Open Source is coming!

....

"AM I GOOD ENOUGH?"

'No' is really exciting.
When you are afraid of contributing, you might ask:

"Am I Good Enough to be doing this?"

That is the wrong question, but let's look at the responses anyway.

If you say "Yes"...are you challenging yourself at all? Are you looking at something only to meet your current capabilities?

If you say"No", you should be excited....really excited.

More on why in a second.

"I'm Not Good Enough."

How Will You Get there?
You can also just plant the flag:

"I'm not good enough".

But...can I wax philosophical for a moment?

Have you noticed that most of the stuff you've ever truly wanted is out of your capability at the moment you desire it?

The things you want in life always get conveniently placed on the far end of a long table.

You have to move to get those things.

Getting Good

The Act of Changing.
What if those fears are just a fear of changing? A fear of being ridiculed, of being vulnerable?

These are fears, and they are valid, but they aren't enough by themselves to stop you from changing.

Only a fear of change will do that.

Your capability today is something you can change as long as you are willing to be changed by the process of learning and trying and failing.

So...what was I trying to be good at?

Why did it have to Be SNakes?

I've done a lot of scripting, and even done some moderate size solo work in the past.

I do a fair amount of scripting, but I do entirely too much of it in bash.

I have had to license my for loop 1 liners as lethal weapons in my home state of MA.

More importantly, because I only script apps to support apps, I miss out on emerging practices and languages in development. I want to stay current, but I also need to expand my toolkit with something industrial strength.

Why, hello there Python! Fancy meeting you here.

IT REALLY DOES ROCK.

python -c "import antigravity"
I had made the decision because it seemed smart for my career, but I spent a few days doing a script that I would normally do in bash or perl in pytho

I seriously didn't shut up about it for several days.

"Did you know that Python is elegant and intuitive?"

"Yes Quinn, we do. Still."

---

But really. Python does rock. And I wanted to go deeper.

Setting Targets

You can only hit what you aim at.
Booktype is a Django app, so it actually provided some opportunity to practice and make something worthwhile...

But I didn't want to be a nuisance with my poor neophyte coding.

But...how was I going to stop being a neophyte without doing the coding?

The first thing you should be doing, and what I did, is talk to people in the community. What do they need? Do they have time to look at some things?

What actually helped get me out of paralysis was talking with community members to identify projects that were just outside of my reach. Too far and I can't see it; too close and there's no motivation.

All I had to do was learn enough code to write the simple utility I wanted to add. I knew what the utility would look like in Perl or bash, so I know I could get there eventually.

With targets set, it was time to do the hard part, which was spend time learning and coding.

MaKING TIME. MAKING CHANGE

When I applied to speak on this topic, I had this grand vision that I'd show you my contrib boxes on my github profile, and there would be a point where you saw everything go green, neverending rows of green contrib activity.

To quote Marlo from the Wire:

"You want it to be one way, but it's the other way."

You can get hype about changing and transformation, but that takes time.

I had to learn how to make that time. I want to share with you some strategies for how I did it.

YSAAS

Yak-shaving As A Service
The first problem is just impedance.

"Yak Shaving as a Service"

Yak-shaving is all the administrivia you must clear before you can actually do the work you intended to do.

I'd like to fix this bug.
But first I need to download the source to my own fork.
So I'll need to trigger the fork on the site.
And then I'll need to clone the fork.
For which I need to update my ssh key.
But first I need to generate a key, or move my old one.

In your day job, you've got a lot of stuff tuned to get to work in short order. When you have side work that you're doing and you're not getting paid for it, it's easy to not bootstrap sufficiently.

So the "stack" that your YSAAS is built on grows.

Yak Stack

  • Keep it lean.
  • Make a (head)space.
  • Leave notes for future you.
  • Ritualized workspaces for quick entry and exit.
Let's think of your Yak Stack as a distributed system of bootstrapping and administration that, while necessary, adds a tax of time and inconvenience to that work of learning and growing.

You want to keep that "stack" lean. give it a space, and give that space some thought when you can.

A great trick is leave yourself a sticky note for the next session in the workspace after you finish your current session.

A set of rituals for starting and stopping your OSS work also reduces impedance.

I've used stuff like tmuxinator to build project spaces that I can attach to or detach from easily and get right into the action.
Photo by Ramen Junkie

Ops Guys Love Metrics

  • MTBT
  • MTTAW
  • AVG(doubts/sec)
Distractions are also impedance. Since I am an Ops guy, I'd like to offer a few metrics for you.

....like MTBT, or "Mean Time Between Tweets". I have to block Twitter when I make time to code or else I fall into it.

....alsot MTTAW, "Mean Time to Actually Working". Oh, it looks like now is the time to answer every e-mail, and clean the desk...right before I have to work on this. Lovely!

...and last, your average doubts/sec is there to slow down your thinking.

A good ritual should help you move past these distractions.

"I DON'T HAVE ENOUGH TIME"

Of course you never have enough time.

You're busy. I'm busy. We are all busy.

But actually, what I've noticed is when we say we're busy, what we are often saying is "I'm overwhelmed".

There's nothing wrong with overwhelmed, but that is a different set of solutions for a different problem.

StoP MANAGING TIMe.

Start Making Time.
I used to tell myself that I couldn't practice coding because I was out of time. But I wasn't too busy to do any number of non-essential activities.

I don't have any more or less time than you did, but I made decisions to spend that time on things that had value to me.

Time Management is OK, but rather than trying to shuffle around your time, you need to learn how to *make* time.


Photo by oschene

Motivation > Time Management.

Getting truly motivated to do something is better than every time management strategy that you can devise.

The short of it is that you can have every calendar app and getting things done variant you want...

Motivation > Time Management.

Getting truly motivated to do something is better than every time management strategy that you can devise.

The short of it is that you can have every calendar app and getting things done variant you want...

Remember the DOG?

Motivation is What Fights the Dog.
...but remember the angry dog? This dog wants to tear your Kanban board to shreds. It thinks your calendar is a joke.

The dog is outages, delays, sickness, excuses...anything that can disrupt your schedule it will offer. So your time management will work to a point, but at some point it will fail.

I am an ops guy. I think *everything* is going to fail eventually.

Having the proper motivation, knowing what you really want out of contributing, is what helps you fight the dog. It is what gives you the energy and will to recover 15 minutes in an otherwise exhausting crazy day.

The Definitive Guide to Staying Motivated

  • Schedule a talk at OSCON about contributing to OSS.
  • Be Selfish.
  • Be Selfless.
  • Picture Future You.
  • Be Vulnerable.
So now, The definitive guide...for staying motivated.

There are a few strategies for finding a powerful enough motivation.

You can schedule a talk at OSCON about contributing. I hear that is pretty motivating. :)

Be Selfish. Focus on what it is you are learning. You picked a big enough target didn't you? What will you know when you finish?

Be Selfless. Who could you help do this? What problems are you solving for the community?

Picture Future You. What will it be like after you've learned what you needed? How will you be at least 1% better after doing this?

Be Vulnerable. Asking for help is an opportunity to connect and learn from someone else. Check to see if someone can pair program with you, or take a second to review code before you submit. Connect.

The SECOND Pull Request

Sweet, sweet, (and Simple) Code.
I want to be the best technologist I can possibly be. I want to design and support services and to do that I must understand the processes and methodologies to build them. I can spin apps up, but I want to be capable of (given sufficient resources) building my own.

That drives me. That's gotten me to practice my python, seek out pair programming, read books and more until I can submit my second pull request.

I spent a lot of time on an issue with my Booktype configuration that I simply could not figure out.

After many hours of troubleshooting and some help on the forums, I realized that I had set a variable in my file to a non-existent file.

There wasn't an error that indicated this, which forced me to look all sorts of places.

It sure would be nice to have a config checker for the app! So I'm building it. There are some difficulties I've been having, but I put in time almost every day.

I learn more about python, more about Booktype, more about development.
Photo by Kovah.de

Talking to Your Future Self

AKA, Wrapping up
I haven't really focused on the process of contributing to a code community like Github; this is because smarter people then me are already giving you those tools.

What I want, what I hope I can do is get you to see that pushing yourself towards contribution grows you *and* the project.

ROAD TRIP

Still Traveling...
I'm still travelling on this open source road trip. I've made a few stops, and I know I'll make some more.

The last thing I have learned is that involving yourself in open source is enriching for another reason....

Not Just Part of the CODE

Be Part of the Conversation, the Community
When you contribute code or other information, you don't just join the code.

You join the conversation, you join the community of people who believe in collaboration and sharing and technical excellence just like you.

Open source would have died if it were just about code.

OSS is about people and relationships.

Despite problems (no community is perfect), I believe the future of open source is incredibly bright.

You should be a part of it.

Thank You!

twitter: @qh_murphy | Github: gamefiend
Thank you so much.