18F/18f.gsa.gov

---
layout: post
date: '2014-07-31T13:01:47-04:00'
tumblr_url: http://18fblog.tumblr.com/post/93415834296/working-in-public-from-day-1

title: "Working in public from day one"

description: "Open source your code from day one. Don't wait for a milestone, don't wait for it to be stable — do it from the first commit."
excerpt: "Open source your code from day one. Don't wait for a milestone, don't wait for it to be stable — do it from the first commit."
image: 
authors:
- eric

tags:
- open source
- how we work
- evangelism
- best practices

---

In the wide world of software, maybe you've heard someone say this, or
maybe you've said it yourself: *"I'll open source it after I clean up
the code; it's a mess right now."*

Or: *"I think there are some passwords in there; I'll get around to
cleaning it out at some point."*

Or simply: *"No way, it's just too embarrassing."*

These feelings are totally natural, but keep a lot of good work closed
that could easily have been open. The trick to avoiding this is simple:
**open source your code from day one**. Don't wait for a milestone,
don't wait for it to be stable — do it from the first commit.

Here are a few reasons why you should feel good about working in the
open from the moment your shovel goes in the ground:

**No one's going to read your code.** Your code is almost certainly
boring. Most code is. Instead, people will evaluate your work based on
how they'd interact with it. Is it easy to learn how to use it from the
README? Is development active? Have many GitHub users starred it? And
none of that will matter until your project is far enough along that
it's useful. You will not be in the spotlight until you deserve to be.

**You will make better decisions.** At the most basic level, you will be
vastly less likely to accidentally commit a password to an open source
project than a closed one. But more than that: even though no one is
reading your code, you'll still feel a bit of natural pressure to make
better decisions. You'll hardcode less, and move more into configuration
files. You'll make things slightly more modular. You'll comment more.
You'll catch security holes more quickly. That's a healthy pressure.

**It will not waste your time.** It may feel like some of those "better
decisions" take more time. But even if you're the only person who will
ever work on this project, you have to live there. You'll greatly and
immediately appreciate having made those decisions the minute you return
to your own code after taking a month off. And when making better
decisions becomes routine, they stop taking more time — and you become a
better coder.

**You might just help people.** And people might just help you! The
internet is a big place and a small world, and GitHub has a way of
making unexpected connections. If your work is even a little bit useful
to someone else, there's a good chance they'll find their way to your
door, start poking around, and find a way to be useful right back. Even
if you're working on what you think is the most niche project that no
one else would ever use: leave the door open for providence.

Once you get used to beginning your work in public, it stops feeling
like performance art and starts feeling like breathing. It's a healthy
routine that produces better work and personal growth, and opens the
door to spontaneous contribution and engagement. When your default is
open, everyone wins.