11 wisdoms from half a life in open source

A software engineer at Google working on the Go programming language keynotes at OSCON this year.
460 readers like this.
Rocks stacked

Tony Smith via Flickr (CC BY 2.0)

Brad Fitzpatrick, a software engineer at Google working on the Go programming language, is a life-long nerd.

His father worked at Intel, so he grew up steeped in technology. He started writing software in middle school, and he has been building and working with open source software for 19 years—over half of his life. Fitzpatrick's keynote at OSCON this year was based on bits of wisdom from half a life in open source. 

  1. Don't bash other technologies. The "other" ones might have been the only choices at the time or might have been chosen because of necessary engineering tradeoffs. The cost of factoring in a new technology can be too high.
  2. Your heroes are just people. They are good at some things, and suck at others, just like you. Learn from them, but don't worship them. And remember, you could be someone's hero one day!
  3. Accepting user-generated content means you should prepare for abuse. Fitzpatrick's first website was swarmed with abuse until it had to be shut down. His second was LiveJournal, for sharing stories.
  4. Know why you're making something open source. Laziness isn't a great reason; there are other ways to collaborate that are less maintenance-intensive.
  5. Don't be afraid to write something new, rejecting "current" tools and best practices. Brad wrote memcached (a distributed memory object caching system) to solve a specific problem, and it saved LiveJournal. People derided it as "not the way things are done," but Fitzpatrick's response was: "'My site doesn't work without it, so cool opinion." (Or, "thanks for reading.")
  6. You are going to abandon projects at some point, so have a plan for passing them on to someone else.
  7. "Easy" and "quick" are not synonymous. Many things are "easy" but end up costing a lot of time, especially when you factor in long-term maintenance.
  8. Any code you put online will somehow end up in someone else's production. Make sure that trivial jokes are flagged as such.
  9. Do you find something annoying about a piece of software? Fix it. Is it just too broken? Vote with your feet. There are a lot of great choices out there, and you can always write something new.
  10. All software kind of sucks (including your own) and everything can be fixed. You're welcome to do so, but if you touched it last you might finding yourself owning it.
  11. Give talks! It makes conferences cheaper to attend and makes them scarier, in a good way. There are tons of amazing low-profile people who are worth meeting at conferences, too, many of whom will never feel comfortable giving a talk.

Fitzpatrick encourages people to share their own stories and the lessons they have learned. We'd love to hear from you! Learn how to share your story with Opensource.com.

User profile image.
Ruth Holloway has been a system administrator and software developer for a long, long time, getting her professional start on a VAX 11/780, way back when. She spent a lot of her career (so far) serving the technology needs of libraries, and has been a contributor since 2008 to the Koha open source library automation suite. Ruth is currently a Perl developer and project lead at Clearbuilt.


We used memcached on several large media environments in production when I worked in a hosting company. So, thanks!

I can feel connected to some of what are mentioned. Thanks for documenting them. Good read.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.