What a Wonderful Time to be OSS


So for a while I've been telling myself I should do some open source work. Yeah, I know, it's a naughty word these days. I would like to do some open source work, how's that. Anyways, I finally did do it. I made a thing!

Childhood makes me expect free pizza when I accomplish things.

If you're interested in checking it out it's over here. Just a little plugin for Go.CD to run build tasks inside Docker containers (maybe I'll do a write up later about the motivations for this). Through the process though, I did learn a few things I thought I'd share.

So Much Free Stuff

Since I'm a devops/software craftsman/whatever you call it guy, my first thought starting out was: "How do I do all the fancy things I believe make software better...without spending money." Well, I'm glad I asked since it turns out there is an unbelievable collection of tools available to the open source community for the low, low price of $0.00.

When Google images fails, there's always imgflip.

So, what do want for your open source project?

WOWEEE! That's a lot of serious, professional grade tools available gratis, and that is by no means is a comprehensive list. I feel like it's my birthday.

Why are there so many kids stickers licensed for re-use.

Well, not my birthday exactly. It's Christmas for the whole open source community. It's wonderful seeing companies contributing back to the community they benefit so much from. It's like the promise of open source is really coming true.

I take the socialism reference as a compliment. Fight me.

Coding can be Fun Again (sorta)

Working on my own project reminded me why I started doing this programming thing in the first place. I remembered the joy that coding can be. No deadlines, no sales team, just me and my code. Free as can be.

Does anyone actually pose like this?

Want to take the time to learn Gradle instead of using Maven that I already know, sure. Want to try some newfangled idea that might not work, do it. Found a new pattern that makes some code blocks cleaner, go ahead and refactor it. Maybe. One thing you need to remember is that no matter what it is, shipping is still a feature.

Always quote smart people. People trust you then.

Yeah, maybe trying this or that would've made something more elegant. Maybe thingymawig A would've made jigermadoodle B better. That's a never ending rabbit hole from which your beautiful software will never escape to see the light of day. At a certain point, you've just gotta SHIP IT!

Being a Team of One can be Scary

When it comes to software, one really is the loneliest number. This project was small (and probably just a tad bit niche), so me, myself, and I was the "team". At first this can feel free. No one else's opinions. No one to say no. No one to watch your back. Wait, wat? That's right, it's just you coding without someone to call your terrible ideas terrible. No one to tell you that your 25 line triple-nested loop is completely incomprehensible. There are a few things I found that help though.

Video games are my reference for life.

Re-enforce good habits

You have them, don't you? Good. Use them. The same stuff that helps make every other project you've worked on better still applies when you're working alone. Doubly so.

Test, Test, Test

You're QA now. Except you don't have the time of a QAE (or, I'm guessing, the desire to sit and manually verify your code time and time again). So, write automated tests for everything. A lot of them. Thank me later when you confidently hit that release button.

Listen to Your Tools

Those wonderful static analysis tools I listed above. Don't just use them, listen to them. The code metric limits are there for a reason. Remember, there's no one else to say "no" to bumping them 5 times their default values (or disabling them). Instead of reaching for that lever right away, step back. Think "should this be refactored?" The answer is usually yes.

Code Reviews are Still Important

But, how can I do code reviews on a team of one? Yourself, obviously.

Obvious answer is obvious.

No, it's not a good as having someone else looking at your code, but it's better than nothing by a long shot. The real trick is the same one that your English teacher (probably) told you to do when you wrote papers: set it down and walk away for a while, then come back and review it. You'll be suprised at the things you'll find in your own code, believe me.