Why Write Open Source Libraries

1. Exploration. I can sample platforms and sample stretch languages without sinking my stakeholders if I fail. Also, it’s easier to try something radical in a small, green field project than in a big one.

2. Altitude training (link TBD). I can make myself jump through hoops that I wouldn’t feel ethical asking someone to pay me to jump through. I did this recently with Sequentially; the next time I needed to simulate concurrent processes in a more serious context, it was a lot easier.

3. Encapsulating components. My answer to Steve Yegge’s problem is to refactor my code into libraries. When I write programs that run on Linux, or the JVM, or a browser, I get those features, but the code sizes of those libraries don’t really count against me. Why not do that with my own code, too.¹

This was the motivation for LzOsUtils and Fluently (both didn’t get to projects), most recently: they were part of other projects, but they were respectively large/tricky enough that I wanted to be able to compartmentalize them, and think about them separately.

1. The Golden Rule. I’ve benefitted hugely from open source projects; why not give back a little?

2. You can take it with you! I’ve written things that I want to use in more than one project; this is easier if they’re in library form. That was the motivation for LzTestKit (another didn’t get to project), most recently.

3. Fame and fortune! Just kidding. You get more fame from working on one project (if it’s the right one) for a long time. And there’s more fortune in straight consulting.

4. More days. I’m with Joel and Leo Babauta (ZenHabits:) sometimes I can only work productively for four hours a day. The trick is to have more days. If I’ve got another project I can switch to when I burn out for the day on the first one, sometimes I can get another work day out of it. (Another trick for getting another day to move from the home to the office or vice versa, or to switch cafes.)