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!

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.

So, what do want for your open source project?

• Want to host your git repo and manage code reviews: github, gitlab, bitbucket.

• Want some project and issue management: they do that to.

• Want to build your project in a CI system: travis, circle, appveyor, codeship, semaphore.

• Want to test your code agaist a bunch of browsers or devices: ok I didn't need this so I don't have a link dump but trust me, they're out there.

• Want some code coverage stats and static analysis: codeclimage, codecov, coveralls, houndci, codebeat, sonarcloud.

• Want to chat with others about your project: gitter, slack.

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.

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.

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.

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.

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.

​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.

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.