How I finally got over the hump and contributed to open source

I finally contributed my first open source “project” to the greater Internet community. There have been stalled attempts before, there have been ambitious projects and desires to contribute to the core of important projects but I finally found the formula that worked.

The project that I contributed is a simple little plugin to the Croogo CMS. Croogo is a CakePHP based content management system that allows you to manage and publish a site from an admin interface. It has a robust plugin system that allows you to extend the base functionality by downloading and installing modules. It also has a nice theming system with the same philosophy - find a theme you like and download/install it.

My plugin is called “Revisions” and adds a tab to your admin screen that tracks content revisions to your pages and allows you to replace the current page with any past revision with a click. You can check it out on github here.

Along the way, I learned a few things about how I could lower the “activation energy” cost of contributing to open source.

Contributing to the periphery

I’ve always wanted to do more with open source, at one point I had ambitious plans to contribute to framework cores or release a huge multi-class projects… but I never was able to get through The Dip and get to the final release.

Starting small is what helped. Revisions is a small plugin to an existing system. There’s plenty of examples to look at from other plugin writers. I’m working in something I’m familiar with (CakePHP) and it’s a small bite-sized task.

It’s not the sexiest project, it’s workman-like, but it shipped.

Address a need

It’s much easier to contribute if you have a felt need for something. Our CMS system currently in use doesn’t have a great revision system. Investigating Croogo, I wanted to see if we could extend it to include the revision system we wanted. In particular, we had a felt need to be able to “tag” revisions and be able to preview revisions to live content.

Since this was a real sticking point in our current workflow, it made it easy to get the motivation to solve this problem. Hearing complaints every week about the failings of our current system was a good motivation to get to the finish on Revisions.

Perfect is the enemy of shipping

Releasing your work to the world is a scary proposition. Especially if it’s raw code. You are motivated to get everything perfect. Your code needs to look beautiful, it should be elegant, it should be fast, it should do everything.

You’ll never ship this way. I like to dream about how awesome it would be if it did this or that. I can always think about “just one more thing” that would make Revisions perfect. Perfect is the enemy of shipping.

What helped was reading The Lean Startup book by Eric Riese. One of the concepts in the book is the idea of Minimum Viable Product (MVP). In a nutshell, MVP means you develop and release the smallest amount of product necessary to verify if your product is of any use to customers.

For Revisions, the way I did this was to write a list of all the features I wanted for the plugin - the kitchen sink - and then really pare it down to what I thought would be the Minimum Viable Product. In my case, it would be the minimum amount of functionality that would potentially (still need to test this) silence the complaints.

Ruthlessly weeding down to MVP helped get to the point of contribution.

The sound of crickets

Finally, now that it’s released to the community the feedback has been…. pretty quiet.

And I like that.

The world didn’t collapse, no one wrote and said how terrible my code was. Didn’t get a call from the creator telling me to stop contributing. The only feedback I got was -

please port to Croogo 1.4.

Perfect.