Zero to 26,000:
My Journey into Open Source

Hi, I'm Steven Maguire

  • I've been building software since 2004.
  • Contribute to open source.
  • Author courses for
  • VP, Technology at Earth Class Mail.
  • Tweet from @stevenmaguire.

Open Source

  • Set a goal
  • ???

The Goal

Contribute to twelve open source projects in 12 months.


  • Step by step guide

  • Important milestones

  • Lessons learned along the way
  • Awesome tools that helped me out


  • Top ranking google results for projects

  • Contributed to popular projects
  • Observed 26k+ downloads

  • Relationships with awesome & helpful people
  • Individual growth

* While financial profit is possible, its about community!

A bit of context

Snapshot of January 2015

  • Head of Engineering at Packback, PHP
  • Immersed in the Laravel Framework
  • Tons of experience on other PHP frameworks
  • Refactoring some personal projects
  • Limited public Github profile
  • "Composer or nothing"
  • Automated testing all the things
  • Continuous delivery via tools
  • Aware of The PHP League and PHP FIG


"I want to build framework agnostic PHP packages that can be installed via composer and improve development experience for others."


.... yeah, but where?

A personal project

I love Trello.

I loooooooove Trello.

Was building a Laravel project to collect analytics for my Trello workflows of my teams.

Trello API uses OAuth 1 for authentication.

Found a popular project. 

There're those PHP League people again, I like their mission, it aligns with mine.

OAuth 1 Client doesn't support Trello.

Score! I will make it happen!

Guess what happened next...

My First Pull Request!

"I thought you were going to add Trello support?"

I found some not-so-DRY code. I fixed it.

A few things happened:

  1. My first* pull request was merged.

My first* pull request

well, not really

My Real First Pull Request

"I thought something was broken; it wasn't"

Then this one

"You're documentation is not right."
(They did not care)

and this one

"I found a bug! I fixed it for you!"
(They did not care)

and again

"I found a new use case and provided support."
(They did not care)


"I want to improve this class."
(They didn't like my design; implemented themselves)

...but finally!

Back to where we started.

My first merged pull request

A few things happened:

  1. My first* pull request was merged.
  2. I read and followed contribution guidelines.
  3. I built automated tests to support my changes.
  4. I learned sometimes you have to email the maintainer to draw attention to your work; and I didn't die.
  5. I accepted feedback and adapted my coding style to match the project, not push my agenda.

I read and followed contribution guidelines

  • Created feature branch to merge into master
  • Verified it passed PSR-2 code style linter
  • Included PHP Doc Blocks
  • It was all in

I emailed the maintainer

  • My pull request sat waiting for a day.
  • The maintainer lives in Australia; he was busy.
  • We exchanged pleasantries and some ideas about improving the project.

I accepted feedback

  • snake_case vs. camelCase
  • PHP doc block consistency

I found a couple more areas to improve code style and documentation based on that feedback.


Now we're cooking.

and finally!

I contributed new functionality.

I was hooked.

New functionality






You get the idea.

Quick pulse check

  • It's February 2015
  • Contributed to two popular projects
  • Met some cool people
  • Personal projects are moving along

In fact

I finished the Trello project and turned my attention to the Uber API.

Uber API uses OAuth 2 authentication.

Found a popular project. 

I got this.


oauth2-client was in the middle of a refactor.

This was huge.

My First* Project!

What makes up a good project?

A good starting place.

Clear documentation.

Attribution and license.

Trust markers.

Other developers need to feel confident in the quality of the code they are planning to rely upon.

Let's take a brief detour.

Where do those badges come from?

1. Github

2. Travis CI

3. Scrutinizer

4. Packagist

  1. Use semantic versioning and cut release tags via Github.
  2. Sign up, build and run automated tests.
  3. Sign up, ensure test good coverage, and "best practices" followed.
  4. Sign up, create listing.

Ok, back to our journey.


Rinse and repeat.

For good measure

A few of these projects "belonged" to The PHP League and I volunteered to maintain them.

My First Open Source Team!

Quick pulse check

  • It's March 2015
  • Maintain a handful of independent projects
  • Member of thephpleague organization
  • Solid project structure, easily repeatable
  • Broader set of tools to manage project quality
  • More cool friends
  • More individual growth

Fast forward

Project sprawl

  • Four API wrapper projects
  • More oauth providers
  • Contribute to oauth2-client core
  • Contribute to oauth1-client core
  • OAuth testing tool
  • Jobs data aggregation libraries
  • Laravel packages for caching and CSP
  • Elvish Ipsum generator
  • HTTP proxy tool

Great Quality


projects as of March 1, 2016


downloads as of March 1, 2016

(not including oauth1 and oauth2 client)


downloads as of April 1, 2016

(not including oauth1 and oauth2 client)


downloads as of July 23, 2017

(not including oauth1 and oauth2 client)

Plus SEO help from Github


Lessons learned

  • Sometimes you have to email people
  • Use semantic versioning (
  • Provide clear contribution guidelines
  • Prioritize code style, use of linters, and automation
  • Use free tools, like Travis CI & Scrutinizer
  • Don't fear asynchronous communication
  • Be responsive
  • Test coverage and code quality matters

Start small.

It’s Okay To Be New


Create an issue or email the maintainer

One small correction.

My First* Project!

My First Relevant Project!

My First Actual Project!

First commits on 
Oct 23, 2013

Among top 5 starred in my profile


Thank you!

on twitter
on electronic mail

on github

Made with