Journey into Open Source

When I started to use PowerShell, I had just entered the IT world. I was a brand new sysadmin working in a brand new position for a local police department.

I learned PowerShell by asking and answering questions, on #powershell in IRC and on the fledgling StackOverflow site. I gave my first user group presentation about PowerShell. It was awesome and I wanted to tell the world.

But I Didn’t Start To Share My Scripts

I could come up with basic and contrived examples all I wanted, but I couldn’t initially bring myself to share my scripts. They always felt unfinished or unpolished. They were incomplete or at least I felt that way.

Tentative First Steps

Eventually, I shared a few things and even contributed to a couple of open source projects. But I wasn’t consistently involved and I still felt my stuff was rough and unpolished (which it was for the most part).

I began to figure out, first from paying attention to the developer community and second from my personal experience, that even my rough, unpolished work might get someone a start or over a hurdle and that others would be willing to help make things I started better.

If I posted a project, I might get feedback from a some people which could help make the project better. I got contributions with documentation or added functionality.

I began to contribute and file feedback to other projects as well.

Side Note: Learning source control concepts was part of this journey, but not majorly so. I had begun using source control myself at the start of my IT career as a way to track how my scripts evolved over time (and as backup).

Embracing Open Source

By this time, I had started working with configuration management tools. Initially, I worked with Puppet and then Desired State Configuration. With DSC is where I began my more agressive open source efforts, helping get the GitHub repository of resources and tools started.

I dumped stuff out there as quickly as I was changing it for my internal needs at my day job. This led to some difficulty for folks trying to adopt my tooling, because my reasoning while clear to me wasn’t obvious to everyone (for some reason, not everyone thinks like I do nor have they had the same experiences).

Going Beyond PowerShell

When I moved on to work at Chef, I entered an organization whose life blood is open source software. I had to start writing code in Ruby, first to teach and talk at conferences, then to contribute to existing cookbooks.

Then things changed, my role at work was changed from a Technical Community Manager to Software Development Engineer. Now I was expected to ship open source software in a language I was just learning. I was really comfortable with PowerShell and I think I write pretty fair PowerShell code. Writing Ruby was, while not a brand new experience, I’m still in the learning phase. To say I was intimidated and self-conscious about my ability to do so - especially given the knowledge, experience, and intelligence of my co-workers and the Chef community at large.

Now, I’ve got a handful of projects and extensions to projects in Ruby out in the wild. I’ve shipped gems and cookbooks and the world hasn’t ended. I’ve not yet experienced a ritual shaming of my code. The world hasn’t ended because I didn’t follow the style guide that time. And when I’ve made mistakes, I can ship a new version to fix it. It’s software, not stone tablets, so I can respond to changes or mistakes or new use cases.

What I’ve Learned About Open Source

NOTE: This isn’t for every project, but the majority that I’ve worked with.

Give Feedback

For the most part, people running projects love feedback - positive and, more importantly, negative but constructive feedback. If there is an open source project you use, and you find something buggy or you think of a new way to apply it - file an issue (or use whatever feedback mechanism the project allows).

Submit That Patch (or Pull Request)

If you’ve found a problem and fixed it or enabled a new scenario for a project - give back. Submit a patch or pull request. Some projects have a very formal process for contributing, some are less so. Find out what the guidelines are and get your changes back to the source project. They may take it, my alter it, or may decline to use it - but you’ve given them the option.

Join The Community

Find out where people interested in that project hang out, either physically or virtually. Are there mailing lists or IRC channels? Is there a Gitter room? Are there local meetups or user conferences? Behind all the code, there are people - users of the software as well as developers. Give back by becoming part of the community. Share your experience.

Start a Project

Got an idea or, better yet, something already going that you can (legally) share? Put it out there. You might be surprised by who comes around.

Just DO Something

At the end of the day, as my old high school calculus teacher would say, “If you don’t know what to do, just do SOMETHING.” If you are thinking to yourself that you’d like to get involved in open source, pick a project - any project, though if it’s something you’d use periodically that helps - and use it, read the code (great way to expand your understanding of a new technology is try to figure out how data and events flow through a system). After you use that software, try to add to the documentation - nearly every project could use help with that!

And If You Are Really Stuck

Find me in one of my communities - I’m stevenmurawski on IRC (#chef, #chef-hacking, or #kitchenci on Freenode) or on Let’s talk about how to help you contribute.