Transparency Means Sharing Failures and Successes

Maureen and I had lunch with Jerry from Maui Makers and the Hackerspace Space Program a couple of weeks ago.  We talked about a number of things including Open Design Engine, Makerspaces (which led to a brief tour of Dayton Diode), and Open Source Hardware.

It was our conversation around open source hardware which had me thinking back to our meeting days later.  We started off talking about the usual stuff:  licensing, the new Open Source Hardware Association, and of course we talked about open source spaceflight.

But then, sitting there in a Panera Bread over coffee and snacks, the conversation turned toward questions we don’t always address when talking about open source hardware.  Questions like:

  • What should happen to abandoned projects on sites like Open Design Engine?” – Well, we should keep them up for others to learn from or fork into new projects, which is what Source Forge does.
  • But won’t that eventually lead to lots of incomplete projects?” – Probably, which on the surface sounds like a “bad thing”, especially if there are many more abandoned projects than completed or active ones.
  • And what if the reason the project was abandoned was it just didn’t work?  What if it was a failure???” – People really don’t like to share their failures…
  • But, wouldn’t you want to know about the things that didn’t work so you don’t have to discover that for yourself?” – Well, yes. . . Of course. . .

And then it happened:  the light bulb flashed on, and we started talking very excitedly about science, engineering, publishing, and how hardly anyone writes about their failures.  They only share their successes.  In fact, if someone were to publish one of their failures, their peers would stare at them with bewildered expressions and ask “What are you thinking?”

It was Maureen who put it best, pointing out that we need to change the culture so people’s reaction becomes “What do you mean you didn’t share your failure?!?!

In that spirit, allow me to present an update on Mach 30’s first open source hardware project, including the good with the bad, so we can all learn from the progress Mach 30 has made.

Shepard Test Stand Update

One concept for the Shepard Test Stand

Things have been very busy at the Shepard Test Stand.  Since announcing the project in May, we have completed the requirements analysis, the block diagram, and are working steadily through Shepard’s design.  That’s pretty good news.  We also submitted two Shepard related presentation proposals to the Open Hardware Summit.

The first submission was a plenary session presentation looking at the engineering process used to develop Shepard and the instrumental role Open Design Engine played in the process.  The second submission was a demo of the Shepard Test Stand.   We were disappointed when our plenary presentation was not accepted, but were pleased to be included as one of the demo projects.

So Shepard has had its share of successes, but what about the failures?  Where have things not gone as planned?  The most significant challenge for Shepard is our schedule.  We are more than a month behind, and we now have a confirmed deadline of September 27, 2012 to conduct a public demonstration of the test stand.  This gives us just short of two months to complete the design (which is mercifully nearing completion), assemble, test, and document Shepard.  That is a tight time frame, especially given our work to date.

So, how did we get so far behind schedule?

I see two driving factors.  First, we were probably a little aggressive in the scope of Shepard, and in the time we allotted ourselves to complete the project–especially when you consider this was our first open source hardware project.   Second, we split our focus between Shepard and our work on the Far Horizons Project High Altitude Balloon.  Our group of volunteers is still pretty small, and many ended up working on both projects.  With limited time, something had to give.  At the time, the deadlines associated with the High Altitude Balloon (HAB) launch meant that Shepard’s timeline that had to give.

Still, with the current round of development work on the HAB basically wrapped up, we will be turning our full attention to the Shepard Test Stand.  Hopefully, we can find a way to get caught back up and be ready for the Open Hardware Summit.

Only time will tell.

[mc4wp-form id="2814"]

4 thoughts on “Transparency Means Sharing Failures and Successes

  1. Michael Turner

    This is a beautiful and excellent idea. I’d qualify it only slightly: you need to make sure the failures get clearly characterized as such. I don’t know how you’d enforce such a policy, except perhaps by sending projects to a “graveyard” section of the site by default, if nobody could make a convincing “success story” for an apparently moribund and abortive project. I’m willing to take arrows in my back on this myself, since my own project’s chances of success are admittedly not great. I don’t want it to fail, but being recognized as an *instructive* failure would be some consolation.

  2. J. Simmons

    This reminds me of a concept from a friend of mine. He calls it optimal failure. The idea is to structure projects such that when they fail, and they will, to get the most learning for the lowest cost from the failure.

    In terms of implementation, what about a two level system: 1) an attic where projects go after some period of inactivity (say three to six months) which projects would automatically leave once activity resumed, 2) a graveyard where users can voluntarily place their projects when they feel the project has not worked out (with some encouragement to share reflections on why the project did not work during the process to move to the graveyard).


Leave a Reply

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