What Open Source Gadgets Can Learn From Corporate Toys

Over the past couple weeks, I’ve written about the concept of the open source hardware gadget: what it is, and why the world needs something like it. So I spent some time thinking about the “how” of creating open source gadgets. It appears to comprise two parts, planning, and executing, and I’ll try to outline the former here.

Looking across the variety of open source gadgets that have “made it”, so to speak, there are a couple trends that appear:

1. For those with a specific purpose in mind, open source gadgets tend to fit the bill much better…though it’s a chicken and egg question due to post-purchase customizations
2. Because it’s hardware, the notion of open source being “free as in speech” rather than “free as in beer” is prevalent. In fact, one might even argue that free as in speech is more valuable than free as in beer, and even worth a premium
3. They seem to be almost always spearheaded by an ambitious, determined core group of engineers or hardware hackers (who have thought clearly about the value of open source)
4. Project progress is usually slower/more likely to become vaporware than with corporate, commercial products, though those experience delays as well

It may make sense, then to take a look at the corporate counterparts for open source gadgets, and make comparisons to see what we can learn from how corporate products are created.

Organization in Open Source

Software development provides the most examples for drawing parallels. In open source, collaboration occurs with a shared repository for ongoing code development that’s decentralized (Github is a great example of such a tool), and there’s also a place where the projects are posted for public use like SourceForge. This virtual system works nicely only if there is someone who takes some responsibility for the project. It may not be explicit organization, but the “hub” is critical to organizing all the bits and pieces into cohesive updates. The reason, of course, is that for many projects, it’s a volunteer labor pool and a labor of love.

Commercially, however, software development teams are organized into many different schools of operation, like agile, scrum, or lean. The teams are budgeted and designated for the task, the product requirements are clearly specified, and a timeline is set in place. Development is far more centralized and predictable. Because product requirements are clearly specified, however, there’s less flexibility in customization, and the decisions of what to include and what not to include are far more gated than the forking style of open source software projects.

In hardware, the models don’t quite hold the same, largely because of the requirement of tangible prototyping. Within both corporate and open source hardware development, there’s a modularity or “chunking” of tasks that exists.

With open source hardware, though collaboration may occur, smaller teams tend to work together in a more direct or centralized way- be it passing schematics and gerbers back and forth. It’s less likely to open up a work-in-progress schematic or gerber to a larger group for small contributions; rather, these changes occur in turns and revisions of production, with each revision resulting in real tangible hardware being built.

Project Management and Likelihood of Success

This leads to a question of project management, and how different approaches may enhance or detract from its likelihood of completion.

Within a company, there are designated tasks, accountability, and typically much more time and financial resources devoted to a specific project plan, all essential when considering hardware development given non-trivial prototyping and production costs.

So despite delays between concept pieces at CES and an actual retailed device, there’s still a higher hit-rate of successful commercial gadgets to open source gadgets. That may not be a fair statement, though, since the open source hardware development model is relatively new and still materializing.

There’s a difference between having a group of engineers building a piece of hardware that is open source, and having it built in a decentralized way that derives its collaboration model from open source software.

Michael Arrington’s notorious Crunchpad project was launched under idealistic overtones of open source hardware, both of design and use. The call to “help us build it” signified a crowdsourced effort initiated at TechCrunch IT, similar to how a piece of open source software might be developed. While Arrington also suggested that the designs themselves might be open sourced after development, that’s consistent with a turn or revision-based model of hardware development. While Arrington gets credit for spearheading the idea and getting some prototypes together, what killed the Crunchpad project? After doing some research, a big part of it seems like the project was a little heavy on the pie-in-the-sky, and not enough on managing how to get the open source device out on the playing field.

The Numbers Game: Costing, Pricing and Volume

There’s something beyond project management and development style that explains why there’s an iPad but still no Crunchpad (now JooJoo). And in its altered re-incarnation that is still in pre-order stage, it now feels like just another venture-backed, slick, company-built device…no longer with the open source hardware element.

The JooJoo concept

The iPad

There’s a populist expectation that open source is cheap and “dead simple”…if it’s built by the people for the people, it should also be people-pocket friendly. What many fail to see is that open source hardware can become expensive primarily because it lacks the economies of scale that a multi-billion dollar market leader like Apple can attain.

And Arrington made his case (and the news) by setting the bar very very low. Of course, as costs crept up, so did the expected price, from the original $200 to $300 to “$300-$400” to JooJoo’s $499. And it’s not open source. And it’s not hackable. So what’s the point?

All the while, Apple built what it built, closed source, which even at scale quantities, costs about an estimated $230. They never made any promises about costs or pricing (it ranges from $499 to a whopping $829!), but with resources in tow and devoid of undue, and somewhat contrived public price pressure, the iPad became a reality, largely on schedule.

Perhaps Ismael Ghalimi, who led the similar Redux Model 1 project, says it best:

“First, the announced pricing of $200 is pure wishful thinking. If an established company like Asus cannot sell a subnotebook for less than $300 while manufacturing millions of them, it’s unlikely that a custom-built tablet sporting a thinner case and expensive multi-touch screen could retail for anything less than $400…

This takes us back to the Redux Model 1, and the critical lessons we learned in developing its concept: bringing a new form factor to market is immensely difficult. It takes a lot of effort, costs a lot of money, and usually fails, for largely unforeseen reasons. At the end of the day, usability is the result of complex interactions between hardware, software, user interfaces, and you won’t know whether your design works or not until it’s done and millions (or tens, or even hundreds of them) have been spent.”

And in light of the Crunchpad failure, his words, written within days of the project’s launch, carry an echo of clairvoyance. It may seem like deja vu, but most likely a case of Arrington not being aware of the experiences of others.

Not to suggest that open source hardware should then be exceptionally overpriced and enclosed in typical Apple design, but making the price a focal point too early in the project may be a bad idea.

After all, it doesn’t matter how much the device costs, how much it is sold for, or even whether it’s open source, if it’s never built.