I'm not ashamed to admit that I don't usually contribute to open source as a way of giving back to the community for everything it has given me. Don't get me wrong, it's a great side effect, but the reason that I contribute to open source is that it makes me feel good.

That's it.

Not the most altruistic of motives, I know.

It's incredibly satisfying to create something that thousands of other engineers may benefit from, so I went about compiling a list of all the open-source projects that I actively use and would love to make my mark on.

The list (while not complete) looks something like this:

• Electron
• Visual Studio Code
• Vagrant
• PHP
• Laravel
• Composer
• Vim
• Curl
• Faker
• Jekyll

My Contributions

So far, I've been able to check off a couple of these: Faker, Electron, Vagrant, and Composer. The changes aren't exactly groundbreaking, but in order to check a project off of my bucket list, I have a rule that it must be a substantial change (such as a major bug fix or new feature), and not something minor like a typo-fix.

Faker: US SSN Support

Faker is an extremely robust (and now archived) PHP library for generating fake data for testing. As an advocate for shift-left testing, it has been one of my favorite projects to date and is one that I use almost daily.

One of my first real open source contributions was adding support for US Social Security Numbers (SSN) to Faker. A pretty simple addition, all things considered, but one that solved a personal need and got my code into the hands of every single project that has used Faker since—what a rush!

Faker: US EIN Support

It wasn't long after adding SSN support to Faker that I got the itch to fill another gap I saw: US Employee Identification Numbers (EIN). In the US, an EIN is like an SSN, but for companies. At the time, I didn't need to generate an EIN for testing, but that didn't stop me. I knew that someone would need the feature—and, after five years, I can safely say that I have personally needed to use it during testing.

Electron: Non-Native macOS Fullscreen

Everyone knows what Electron is, so I won't repeat what doesn't need repeating here. That said, this is probably my proudest contribution to date and one that has had the most exciting downstream effects.

When macOS released Lion, they changed the way their native fullscreen works. Rather than simply maximizing the window and removing the title bar, dock, etc., they instead do all those things and move the window to a new desktop window. While not a big frustration in itself, when combined with multiple monitors, all the other monitors would be blacked out and rendered useless. As you can imagine, this was incredibly frustrating for most power users (myself included).

As a fan of Visual Studio Code, I (and many others) longed for the old-school fullscreen in my editor, but it was hampered by Electron's own limitations. So I did some digging and found that iTerm2 (a popular open-source terminal emulator for macOS) had developed its own workaround to the Lion-style fullscreen. After a lot of trial-and-error in a language I had never written code in before (👋 Objective-C), I was able to reproduce the functionality within Electron and (eventually) get the feature merged in.

What made this so exciting was that, while I contributed a much-desired feature to an incredibly popular product, there were some great downstream effects in products that were built on top of Electron such as Atom and Visual Studio Code.

Vagrant: Custom Vagrantfile Templates

While I've mostly moved over to Docker to manage developer environments, I've always been a huge fan of Vagrant. It has that wonderful combination of both simple and powerful that I love, so contributing back to it was pretty high on my list.

A gap in the Vagrant feature set that I noticed was the lack of Vagrantfile "templates." For an uninitiated Vagrant project, a Vagrantfile defines exactly how the underlying virtual machine should be provisioned, and I often found myself copying and pasting the same general set of instructions over for every project I used.

The solution that I came up with was a templating system that allowed you to initialize a Vagrant project using a defined template file. This made it easy to kickstart any project with a pre-defined set of instructions and resources without having to copy and paste the same block of code over and over.

Vagrant: Vagrant Aliases

Still on the Vagrant train, another feature that I'm particularly proud of contributing to is "Aliases." Vagrant Aliases, a feature that was inspired by both Git aliases and Bash aliases, is exactly what it sounds like: the ability to define additional Vagrant commands as aliases (for example, vagrant destroy executing rm -rf .vagrant).

Composer: Default Init Values

Every PHP developer knows about Composer, PHP's de-facto package manager. One feature that was missing at the time was the ability to define default values when initializing a Composer project, meaning that you always had to type in your name, email, etc (even if they never changed).

At the time, I was leading development at a digital agency, which meant I created a lot of Composer projects. While filling out the same details every time wasn't the most time-consuming experience, it got tedious enough that it was worth the diversion to streamline my process a bit.

What's On Your Bucket List?

Clearly, I haven't made that big of a dent in my open source contributions. As you can tell, the big ones tapered off around early 2018 (which happens to be just shortly after my second child was born). That said, I still try to look for opportunities to contribute when and where I can (despite having very little time to do so).

But, enough about me. Do you happen to have your own open-source bucket list, and if so what is on it? Shoot me an email or drop a comment. I'd love to hear from you!

Also published at flower.codes.