Teach a man to fish
And he'll bug you forever
Buy him a damn fish
Just wrapped up a really big project obstacle in my day-to-day work in lab. I finally released the new set of designs for the Yale OpenHand Project. There are plenty of open-source projects out in the wild now, especially in research. It's a nice way of publicizing your work for others in your field, especially if you work in mechanisms (and don't care for patents) or have built some sort of useful framework (usually for CS). It also provides a little bit of relief knowing that your work won't just fade away into the ether after you graduate. I sometimes get a little sad thinking about all the CAD projects and code snippets that never see the light of day after they're made. As is the case in startups and product development, hardware presents a set of challenges very different from that of software. I've released code for public use before, but never part of anything of significant size, so my perspective is a bit limited, but here's a couple of things I picked up over the past 2+ years working on the project:
Everyone's compiler is different
Unlike software, you really can't give the user a settings file or a tutorial and expect them to just push a button and get the same result every time. Even our project, which uses 3D-printing, essentially the closest thing to an easy-button we have in Meche, you'll have variance across multiple machines. Not only are the physical tools different, the ways that your users will use said tools may also be different. In our case, we tried to make the design of our printed parts as basic and minimalist as possible so that it wouldn't be dependent on nozzle diameter or layer height. We even went as far as to make the parts as parametric as possible, so that certain changes can be as easily propagated as possible. Without a universal standard, an issue I'd imagine is pretty common in nascent or small disciplines, we could only try to rely on existing, if limited, 3rd-party documentation and then just commit to having to update our procedure on the fly in the future.
Aside from the main production machines, whether it's a subtractive or additive system, we also have to acknowledge that the users will decide for themselves how strictly they'll follow our recommendations for processing our source files. No matter how many times we say "we have only tested our assembly with such-and-such parts and this-and-that processes," there will always be a user who asks whether or not they can use this other part and that other process, since it's way more convenient. Now, I've had to write code to accommodate multiple browsers on a variety of OS's and devices before, but this is more akin to someone asking a chef if they can use an ingredient the chef has never heard of or used, and still get close to the same result. There's just no way to know unless someone tries. Now, if only trying was just that easy...
Users aren't lazy. They just don't want to do anything.
Granted, I think even open-source software projects run into this issue from time to time. A a project you can just download/clone and then run "sudo make all" is probably going to gain faster adoption than something with multiple modules you need to compile individually. That's just an unavoidable consequence of human nature. I don't think I've come across any hardware projects with only a single assembly step. As much as 3D printers have been hyped in the last year or so, it's still pretty far an all-in-one replicator/maker.
I'm always a bit amused by how many people clamour for open-source, and how few of them actually take advantage of it when it's made available. As an idea or movement, open-source is pretty spectacular, but in practice, I don't know if I can name too many cases (especially outside of software) where it's made a significant impact. Makerbot got a lot of shit when they went closed-source, and Aleph Objects gets a lot of street cred in the maker community for continuing to make their designs open, but I don't see what the big deal is. There's an old interview floating around in the interwebs somewhere of Bre Pettis arguing that the Makerbot Replicator's design with the new metal sheet framing isn't something that would benefit all that much from being open-source. I don't actually think he's wrong there. Also, as is the case with a lot of hardware, there's really nothing stopping someone from reverse-engineering the machine if they really wanted to, as evidenced by the persistent proliferation of Makerbot clones and teardown guides currently available. Certainly, if open-source enables more people to participate, the relevant markets may be compelled to shift in response, as shown by the increased availability of parts/resources relevant to 3D-printing in recent years, but I'd argue those cases are pretty rare, and 3D-printing is itself a very unique case, where product can be used to make components for itself.
So, I usually try to contain my excitement nowadays whenever someone tells me they're excited to implement my project(s). It's a nice sentiment, and I appreciate it, but the build process is (seemingly) full of peril, and I've seen more than my fair share of correspondence regarding our project eventually go dark and quiet over time. If you account for time, I'm no longer sure that an open-source option is necessarily all that more cost-effective when compared to a commercial alternative. In that scenario, who wouldn't rather someone just do their work for them?
If you thought software debugging was hard...
Oh man, I'm still trying to figure this one out. The worst thing about debugging these past few years is that no one tells me anything. I know for a fact that there are iterations of my design(s) out there that have been built. I also know for a fact that even in the best scenario, users are going to struggle building our hands. I know this because I've babysat undergrads while they tried to build our hands, and every single one managed to mess something up in a unique and novel way (actually sort of impressive in a sad way). Every error case is new, aggravating, and sometimes non-repeatable. Design for assembly is difficult enough, but design for assembly by others is, in my opinion, a couple orders of magnitude harder. I think the open-source movement overall has managed to skate past this issue by just letting the projects with more complicated build dependencies die a silent death.
Now, we've recognized this potential (and now persistent) problem from the start. We've always known that to be a successful open-source project in hardware, we'd have to hold a couple of hands and drag our user-base to the finish line in whatever way possible. That's why there are assembly guides and oodles of picture and diagrams. I've gone as far as making a series of Youtube videos that detail all the assembly steps, but that's not exactly sustainable in the long run, nor do I want to put myself through that for every design iteration (nor should anyone).
You can't support everyone, nor do you want to
One of the major goals of this project was to make the assembly almost like building Ikea furniture. Now, I agree that the Ikea model is a good target to work towards, even if this is a substantially different product, but even Ikea's not suitable for everyone. As a mechanical engineer, that's really hard for me to handle. There comes a time when you just have to shake your head at a group of users and tell them that this project just isn't for them. Even toy kits have a suggested age-range. Why can't open-source projects have a suggested experience requirement? We've made a lot of sacrifices in the design to make it as approachable as possible, so much so that some of our research work that builds on my designs in this project just aren't as capable as they could be, since we've bypassed certain features that are functionally better but more difficult to implement.
I think this is why open-source is often an after-thought or add-on, rather than a key focus. It's just too difficult to target all the different users, unless you provide next to everything. It's just way easier to just commit to a limited set of options you're the most experienced with and letting others take care of alternative mods. I think we really over-reached by adding on different actuator and finger options to our project. Did we really gain that much larger of a user-base by providing these options? If users really need that much assistance or additional options to take on our project, then maybe it's just not for them. Or, (as I should probably choose to believe) maybe our efforts are exactly what similar open-source robotics projects have been missing to properly gain traction and adoption among the research community. Spend money (time and effort) to make money, y'all.
Customization is a service, not a product
One of major goals of this project, and one of the major tenets of our lab's approach to hand design in general, is that the hand's functionality can be customized by modifying the part geometries, which is very easily addressed through 3D-printing. However, we've noticed that no one wants to customize anything. All of the successful builds we've seen just used our default design parameters. I'm not even sure anyone's even bothered to dig through our actual source CAD files. Granted, I don't blame them, given what an adventure parametric Solidworks files has been for me.
That said, I still believe in customization, maybe even more so after going through this project. I think people ultimately want something very particular, not just what a 3rd-party or the overall market has decided is the best fit. There just hasn't been many projects designed specifically for the high degree of customization that I've tried to do the for Openhand project. It'll be interesting to see where this goes, but this design approach may be much more than just an extra premium option. We're already seeing things like made-to-order earphones, adaptable keyboard kits with custom layouts, switches, and keycaps. These are more than just slightly modified geometries as is the case with a lot of trinket/jewelry-related projects in 3D-printing. These projects take advantage of nearly every little option that can be modified, beyond just cosmetics, and provide it as an option. It's a really power notion (imo) that people are just now beginning to see as feasible.