From myriad spectacular failures, a winning talk

Josh Simmons is speaking at Texas Linux Fest 2015, delivering this talk: Fail Early, Fail Often, Fail Well.

In this interview, Simmons explains the meaning and value of failure for good.

How did you get involved with open source?

I had my first brush with FLOSS when I was 12. I'd been dabbling with QBasic when, much to my surprise, a MUD let me join the team and muck around in their codebase. I had a vague awareness that the code we ran was in use elsewhere too. That wasn't novel to me at the time; it just seemed sensible.

I ended up using FLOSS heavily throughout my web development career, though I have only recently been able to start contributing back to the community. I made my my first commit in 2013 in the form of a Drupal module, after my freelance and startup career came to an unceremonious end.

But really, what I've come to learn about myself is that I am a middling technologist and an excellent organizer. So, as you might imagine, I was thrilled to be installed as the community manager of OSCON.

I now contribute to the commons through my stewardship of OSCON, and I discover new opportunities to give back all the time. Being who and what I am, my contributions tend toward knowledge transfer and advocacy. My pet project? Learning about and spreading the wisdom of inclusive communities.

What are your favorite open source tools to use?

I have a deep and abiding love of Eclipse, and the Apache HTTP Server is near and dear to my heart. Also, being as I now use a MacBook Air for work, I owe a debt of gratitude to the FreeBSD community.

Can you think of an open source project or a situation that you would use as an example of failing well?

As someone who has failed spectacularly, my focus has been on individuals—though increasingly it's on organizations. Drupal 8 and the Backdrop fork come to mind, but perhaps the best example I have is the kerfuffle between Node.js and the io.js fork.

From what I can tell, there was frustration with Node's release cycle and corporate stewardship. When talks with Joyent broke down, the community took matters into its own hands, forked the codebase, and moved governance into the open.

Things could have ended there and that would have been fine, if only a bit confusing—after all, open source culture encourages forking. But the community didn't stop there; people kept talking. Eventually, Joyent backed down as Node's steward and, with the help of The Linux Foundation, Node.js and io.js merged under the auspices of the new Node Foundation.

This, to me, is an example of an open source project failing well. The community, rightly, took things into its own hands when it found Joyent unresponsive, but it didn't stop trying to patch things up. In the end, both the io.js community and Joyent demonstrated flexibility by ceding control. The result is a more robust technology, a less fragmented community, and responsive governance. Everyone wins.

Your talk is going to mention some real-life examples of your own of failure. Can you share one of those examples with us?

Ahh, where do I begin? I failed as a freelancer and as a startup CEO, and each of those failures decomposes into dozens of others. I guess my greatest failure was my failure to measure, so let's talk about that.

I was a freelance web developer for 10 years. I produced estimates, billed clients, paid bills, paid subcontractors, and occasionally paid myself. Obviously, I dealt with a lot of numbers—so what do I mean when I say I failed to measure? What I mean is that I failed to properly understand my business. I saw myself as a craftsman and approached business with reluctance, so while I measured some things, an accountant or CFO could plainly see that I was operating in the dark.

I was never great at tracking my time. Despite 10 years of freelancing, my estimates were never accurate. I was financially illiterate and had no budget for myself or for my business. Because I didn't track my time well and I didn't have a budget, I did not know what my capacity was, or, at any given time, my utilization of that capacity.

I knew I was constantly falling behind, but I didn't know why. In an effort to save myself, I took on more and more work. I existed in a state of near constant panic. My health suffered, as did my relationships. The quality of my work was abysmal. All the while, I rationalized my failure to quantify by telling myself I didn't have time for that, and that any time not spent on development or sales was time wasted.

If I'd tracked my time, I could have produced more reliable estimates, which would have put an end to my terrible habit of lowballing to win bids. If I'd had a budget, I would have recognized that more of the same was not going to cut it. No matter how many bids I won, unless I charged higher rates or signed on to larger projects, there was no way to make my business work. It was unsustainable and that should have been obvious, but it wasn't.

The house of cards came tumbling down in 2012. I hadn't learned my lesson and I was using deposits for new projects to pay my subcontractors for past projects. I knew the jig was up when I could no longer pay rent.

Did I learn my lesson then? Unfortunately, no. I ran from my problems and founded a startup that didn't last long. I was fired from the startup I founded in 2013. It's only in retrospect that I've begun to understand my myriad failures.

I never actually failed well. I failed spectacularly and, too often, without learning my lesson—which, of course, is why I am now giving a presentation on failure! Failure is inevitable, but there are gotchas we can avoid and, when we do fail, there's a way to do it well. I hope to serve as a cautionary tale for other developers and entrepreneurs.

Do you have any tools, reading materials, etc. you'd recommend for people looking to learn more about this topic?

I'm willing to bet there are great books on failure, but I'm deeply skeptical of the self-help genre and anything that resembles it. Instead, I encourage people to break things down and learn about constituent parts, so that we can apply them in context of our own lives (rather than trying to squeeze into someone else's monolithic framework).

I do recommend people read up on a few subjects germane to failure. For starters: grit and resilience. Andrew Zolli and Ann Marie Healy's book, Resilience: Why Things Bounce Back, is gold. And I find learning about neuroscience to be incredibly edifying. I have found no better way to cultivate empathy and skepticism than to get acquainted with our own fallibility. To that end, I recommend Daniel Kahneman's Thinking, Fast and Slow and John Medina's Brain Rules.

And I offer a simple checklist in my talk for making sure you cover your bases when you fail: Manage yourself, manage your relationships, and manage your reputation. I leave it to the individual to fill in the details, but I offer my thoughts in a blog post I wrote on the subject and in a podcast interview I did with The Naked Freelancer.

This article is part of the Speaker Interview Series for Texas Linux Fest. Texas Linux Fest is the first state-wide, annual, community-run conference for Linux and open source software users and enthusiasts from around the Lone Star State.