True story: I once worked on a project where I was told from the outset that “we probably will not use your code”.

This was back when I worked at a big defense contractor. There were negotiations under way for an expanded contract that would obviate the work I was doing, if it were signed. But someone still had to do the work, to meet current contractual obligations and in case the negotiations fell through.

Back then I estimated that about 50% of the work I did was eventually shelved and never used. Contracts changed, or a feature went over-budget and was cut, or a management shuffle resulted in new priorities. I began to think about projects as being similar to teeth: ignore them long enough and they’ll go away. This environment lead to an interesting productivity optimization: I realized I could ignore projects for weeks on end, and focus on my self-teaching instead. Eventually half the projects would go away, and the rest I could cram out with a few over-nighters.

Later I worked for a startup, which failed. We managed to open-source a little of our work. As far as I know, most of it is still collecting dust in some VC’s cabinet of intellectual property, never to be seen again.

Over the years a lot of SAAS software I’ve used and enjoyed has gone away. Anyone remember Posterous? Or Drop.io? I invested time and content into them, then one day they posted about their incredible journey and then vanished into Facegooger. Along with their code.

Recently a service that I absolutely love went into maintenance mode and stopped accepting new sign-ups. They haven’t given me an end-of-service date, but it seems like the writing is on the wall. I’ve asked, and no: the code will not be open-sourced.

Every time I read articles about how to be a successful startup entrepreneur, I hear the same thing over and over again: fail, fail, fail. Don’t fear failure. Embrace it. Do it over and over again and learn from your mistakes.

It’s good advice, I’m sure. It’s important not to be immobilized by the fear of failure.

(Though failure isn’t always that informative. You can learn a thousand different ways to fail and never learn a single way to succeed.)

Moreover, failure has collateral. Are we OK with the idea that the only long-term benefit of these years of failure is some life experience for the founders? Code isn’t the only thing that gets cast aside in failure. Often, there are employees as well. Who may be left with little more than useless fractional stock options and a lingering sense of burnout.

This is especially vexing given that a) many employers give a great deal of weight to seeing recent code that that a prospective hire has written; and b) the work pace for early startup employees often gives them no extra time to contribute to non-proprietary code.

Life is short. We have a limited amount of time to benefit the world. Is it acceptable, the idea that benefit will only come from the “hits”?

I don’t think I want to write off [any more] years of my professional life to nothing more than “well, that was a learning experience”. I hope I can find ways to make even my failures be useful to more than just myself.

This could mean a lot of things. One concrete take-away that I’ve just started pondering is this: I’m not sure I’m comfortable with the idea of working on speculative projects which are legally constrained in such a way that the code will be archived alongside the Ark of the Covenant if the project doesn’t pan out for whatever reason.

Which makes me curious: is anyone out there actually making provisions for open-sourcing their code in case the company or project fails? Is this even a thing?

What do you think? Does it matter that we make our failures “count” for more than just personal enrichment? Are you taking any steps to ensure they do? I’m curious if anyone else is thinking about this.

Published by Avdi Grimm

7 Comments

  1. I’ve definitely been thinking about this lately. I worry about my career options if my current position goes away for whatever reason. I have over a decade of professional programming experience, yet almost nothing tangible to show for it, since most of the code I’ve written is proprietary and most of the projects I’ve worked on are either not public or have gone offline.

    Reply
  2. Avdi, you should read Chris Poole’s, aka moot, account of winding down his startup DrawQuest if you haven’t done so already:

    http://chrishateswriting.com/post/108080554943/a-pragmatists-startup-spin-down

    Very admirable account of how Chris tried to dissolve his enterprise while trying to “provide the best possible outcome for [his] employees, users, the developer community, and local community.”

    Reply
  3. I’m working on a saas product for healthcare. Our contracts state that the code is open source. For our customers this has the benefit that they could (with a degree of effort) find a way to continue using the software should we ever have to stop. For ourselves, it means we could split off our department as a new company, in case the hospital we work for ever becomes difficult to deal with in terms of regulations (since the hospital is not really in the business of producing sellable software, sometimes we have to work around limits that don’t account for our group of Mac-using, root-access needing developers).

    Reply
  4. I think any kind of experience — even if it’s a failure — should be out to public so that other people (and even ourselves, in the future) can learn from them. Certainly, open sourcing software is a very practical way to do that.

    It’s such a waste to hide (or worse: throw away) years of hard work, just like that… It must be an awful feeling when you don’t have control over your craft and somebody else those making those kinds of calls.

    I hope businesses will figure out betters ways to make money, while keeping their source open. The actual value given for a delicious meal, isn’t in the ingredients or the recipe per se, but in how those pieces are baked together and what and awesome person — or team — you are. That is (I think) why your customers would keep eating at your place instead of the next door’s.

    I would argue that any software project should be open source and credits given to their authors, but the business that the company creates from it may be proprietary, so to speak.

    Reply
  5. What’s the next best alternative?

    Demanding that your contributions be treated with special privileges no more than raises the cost of employing you. Which is, of course, anyone’s option.

    Personally, I think walking away from a project with the attitude that you learned something new – a new skill or even one of life’s painful lessons – is maturity in the face of uncertainty.

    Reply
    • You can say the same of literally any call for improvements in an industry. You could just as well say that a 40 hour work week is “demanding special privileges”. And I’m sure many did.

      I don’t want it to be a special privilege; I want it to be the norm. But that has to start somewhere, and I happen to be privileged to be in a position where if I ask for this there’s a decent chance a company that is hiring me will actually consider it. If that leads to more people demanding to work somewhere where their work has a decent chance of surviving an “exit”, well… I think the upshot of that would be positive for everyone in involved.

      Reply
  6. There’s power in failure: it forces you to reconsider what you really value. I wrote about it at http://emile.silvis.co/growth-comes-from-real-failure/.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *