Contributing and Releasing Vagrant Hosts Updater 1.0! oops 1.0.1

At LPi we extensively use open source tools in our daily development cycle. One of the tools that I have personally grown to love is vagrant hosts-updater plugin. I reached out the original developer to see how I could help out and ended up becoming a contributor and project maintainer.

The Problem

Vagrant hosts-updater is a simple Ruby plugin that updates your /etc/hosts file so you access your development site with example.com instead of 10.0.0.50.  Vagrant makes it really easy to hook into their event calls. The problem that I saw on the project was the current maintainer was not responding to pull requests or issues. I understand that life changes and sometimes gets in the way and this is where I felt I could make a difference.

 

 

That was it.  Now I was a project maintainer of a fairly popular open source contribution.

Releasing Version 1.0

My goal with version 1.0 was to provide stability and fixes that were a long time coming to the project. This is the original reason why I sought out Falk in the first place, to accept some bug fix pull requests. I learned the basics of the plugin and Ruby over a weekend and had a gem file being built. I released the gem file after testing it on my Linux, Windows, and Mac boxes. Everything worked great and I released version 1.0 sometime before midnight.

Releasing Version 1.0.1

The next day there were several installs that were failing on the newest Mac OS. I panicked a bit. After all, I just took over the project and my goals were to release a STABLE piece of software. I quickly applied a patch and made sure to test on the newest OSX release this time.  I release 1.0.1 and solved the issues that I introduced.

One thing I realize after the original panic blew over, it is okay to panic and have issues or pull requests come into a project. It means that people want to help. If people are willing to create an issue on your open source project, it means they care enough to contribute that.  They might not be able to write code but it is a contribution. Something that prior to our open web was near impossible.

Secondly, when a bug is introduced it is necessary to provide feedback and release when you have a fix for that specific bug. I remember hearing “Bugs erode trust”. I’ve heard it from past managers and read it online in several articles. They simply don’t erode trust though. They provide an opportunity for you show the customer or user that your team is capable of handling some choppy water.  It is impossible to introduce a product without bugs.

What’s next?

Today I officially released vagrant hosts-updater 1.0.2 and am planning on having several added features in the next release.  We are approaching 100,000 downloads and it almost seems like a cause for celebration! So expect several updates relating to open source projects and vagrant hosts-updater.

Remember, if you can create an issue on GitHub you can contribute to an open source project.

  • Aaron Saray

    Bugs erode trust, huh? Sounds familiar 😀

    • Midwest PHP Keynote by @aaronsaray:disqus! Somethings just stick with you. I need to amend this a bit though: Bugs that are not addressed erode trust. I’m being to nit picky though

      • Aaron Saray

        See – I wouldn’t amend it. If you are thinking like a programmer – meaning, you’re responsible for the work – you tend to think that fixing a bug is good enough. Which, it is the BEST thing you can DO, but the trust is already eroded. Now, that’s not necessarily the same thing as customer engagement. A weird thing happens with the first few bugs that are actually addressed – the customer doesn’t necessarily trust the product as much, but they are more bound to you, and like you more. Weird… I know… but I think ‘not addressed’ is some BS pandering by a programmer (hey – I’m one too 😉 ). As soon as they happened, the trust is gone. But that’s just the expense of the business we’re in.