Say you're selling forks,
A man buys that fork for soup
Leaks are still your fault

Meant to write this a lot sooner, as I wanted to summarize some of the initial responses to my release of the Yale OpenHand Project in late February. Certainly many surprises and lessons along the way. Some actionable, some I guess we'll just have to deal with and possibly apologize for in the future.

Initial Response

I guess I was a little underwhelmed by the initial response, especially compared to the response we got when the project first got "accidentally" publicized (albeit briefly) about 2 years ago. Perhaps that reflects the flood of 3D-printed projects in recent years, especially many of the DIY prosthetics that (I presume) would seem more much advanced/refined to the average viewer. Also, I'd argue that even experienced researchers have always either underestimated or completely disregarded what we're doing with underactuation. Finally, I have this suspicion that the robustness of 3D-printed projects is often glazed over or ignored, especially during the initial release. It was sort of difficult to convey the work we put into making our designs especially robust for dedicated use when the majority of readers just assume that most 3D-printed parts should be functional by default (which is not true!).

On the flip side, we were fortunate to be picked up by some of the popular tech/DIY blogs: Hackaday, 3DPrint, 3Ders, OSChina, MakerDiwo, Robocraft. Our Youtube also saw a 4x increase in subscribers and views, though only to 90 and 18k, respectively (so no talk of viral hits). Unfortunately, no interest from the likes of Spectrum, but we certainly managed to get our project onto the radar of many people who had never heard of our lab's work, so that's definitely nice. I also posted to the mailing list for the Amazon Picking Challenge, and it was also pretty exciting to hear back from a couple of teams willing to give our grippers a try.

I'm really grateful we had the opportunity to get some professional pictures taken by the Yale photographer in the months prior to this release. Well structured lighting done by someone who knows what he/she's doing makes such a big difference in the final quality.

Sharing Hardware Designs

One of my biggest concerns was how to effectively get the right files to the right people in a clear way. We had originally just had sets of .zip files tucked away on our website. That limited our exposure, and it also made hot-fixes and minor changes rather cumbersome to do and document. This time around, I threw our files onto Github to try something different. Even though Github's primarily a code-sharing site, they have a really nice .stl viewer, and several DIY 3D Printer projects had been using it in favor of Thingiverse or Youmagine.

Github's been nice in terms of making small hot-fixes and documenting the minute changes I might make on a weekly basis in response to user feedback, so that's definitely an improvement. However, I think researchers aren't quite used to using something like Github for mechanical parts. From personal experience, I'll say that I've downloaded individual parts a couple of times, but I've rarely cloned entire repositories just for parts. I think the data reflects that: a single clone on Github and about 137 downloads of some .zip file on our main site. Then again, maybe that reflects exactly how users would like to use our files: just grab the exact files they need when they need it, and not any sooner.

Figuring Out User Needs

Ugh. The most difficult part of the project for me has been trying to figure out exactly what documentation the users would need to complete their builds. It was (and still is) the most boring part of the project by far. User feedback is absolutely critical, and yet it's also incredibly frustrating to deal with. I think anyone who's done QA or customer support for a small hardware company will agree: it's really hard figuring out what real problem the user is actually having. The fix itself is often quite simple and straightforward. To date, the best feedback has always been from undergrads who have tried to build hands under my supervision. I just have to turn my back for a second, and that'll usually guarantee that they'll fuck something up, and then we can directly debug the assembly process then and there.

Another issue might be that users aren't necessarily as eager to bug someone about an open-source project. I can probably count on one hand the number of times I've reached out to the creator or maintainer of an open-source project for additional help. Maybe there's a tendency to just accept the released project as is: a singular and static object, rather than what an open-source project actually is: a fluid venture that still has opportunity to warp and change.

The Grind

And now, until I graduate (I presume), I just mostly sit back and handle whatever requests we get about the project. I think most hackers/entrepeneurs will agree that the ideation/prototyping phase is the most exciting part of any project. Product refinement and debugging is boring, to say the least. Unfortunately, that's been the primary focus of the OpenHand Project, by design. Our focus has always been to take some of our early prototypes and make them more developed and user-friendly for others.

At this point, it definitely feels as if we're locked in to some of our designs, for better or for worse. With stuff that's been released, it's now easier to cause a whole bunch of confusion with our existing user-base if we want to make any major changes. I kind of like the current troubleshooting flow I have through Github, but it's still an extra burden that's probably just going to stick around for as long as I'm still in grad school.