The infamous 580-pound, 105-speed BEHEMOTH, with Mac, SPARC, and DOS environments as well as satellite datacomm, HF/VHF/UHF ham radio, heads-up display, head mouse, handlebar keyboard, 6-level security system, speech synthesis, 72 watt solar array, and deployable landing gear to keep the monster upright on killer hills. The bike now resides in The Computer History Museum in Mountain View, California.
This is the fifth and final installment in a series of articles unlike anything we’ve ever published. Steven K. Roberts has figured out how to live passionately, pursuing crazy dreams and building fantastic machines (like BEHEMOTH and Microship, both of which are pictured and briefly described here) and going on amazing adventures. He calls what he does Gonzo Engineering, and in this series he tells you everything you need to know in order to pursue your own crazy gonzo engineering dream. Links to previous articles in the series appear at the end of this article.
If you’re at all normal (which I cannot assume, but hey, we’re talking statistics here), you can only work in isolation for a limited time before reaching burnout—whether from loneliness, overload, or a lack of constructive feedback. It’s analogous to music: I’ve played the flute all of my adult life and have a familiar set of ruts that I fall into when jamming by myself. But shove me in front of a microphone with other musicians, and after a few fumbling minutes of feeling like an incompetent klutz, I find myself playing fresh material. I recently started the piano, just to keep my lazy old wetware on its toes in new territory.
It’s like this with the design process, and not just for the practical reason of distributing workload. Everybody brings ideas and experience to the party, and when you’re in the envelope-pushing business you need all the inspiration you can get. Even for those rare folks who indeed know it all, proceeding indefinitely without intelligent company is just plain difficult. The trick is recognizing and attracting the kinds of people who have a lot to offer, and it’s no accident that those are the very folks who are already overloaded and unlikely to list “volunteerism” as a hobby. Just as with sponsor relationships, this has to be a win-win, and that can take a lot of unconventional forms. (It can also be based on money or barter; we’ll get to that in a moment.)
Attracting a Volunteer Community
What can a gonzo engineering project offer potential co-conspirators, assuming there’s not a big pot of cash available for hiring first-class talent? In my projects over the years, there have been a few “perks,” some accidental, that have kept me surrounded with interesting people:
For the Glory!
Perhaps the most obvious benefit that a volunteer crew can derive from pouring creative energy into a project is the resume?-enhancing halo effect of association with something exciting. It is thus exceedingly important that you don’t greedily hold on to all the credit, but instead share the spotlight with those who have made contributions. In my own case, I actually get a lot of pleasure from this: when I kick back with a beer and contemplate the bike or boat, I see decades of intelligent friends, mad marathons of midnight machining, student teams working with rising panic as the end of a quarter nears, and pivotal moments of insight contributed by people who haven’t been blinded (as I often am) by staring at the same problem for months. In articles, interviews, and speeches, I give credit where it’s due.
Of course, offering this as a sort of barter is a bit iffy; if a project is just getting started, promises of fame come off a bit like overly ambitious hand-waving, like a startup promising founders’ pool to someone who helps cobble together the “About Us” HTML. It takes a bit of time for this to become as attractive as it sounds.
The Bottom Line is Fun
All that seductive fame ’n glory aside, I have found over the years that the best motivation happens to be the most pure: fun. This is, after all, why most techies do what they do, and one of the best compliments I ever received on the project was from a fellow who dropped by for an afternoon of brainstorming: “Thanks for reminding me why I became an engineer.”
I am convinced that the best way to build a team is to simply do something so cool, so exciting, that people jump at the chance to participate. This is the kind of energy that gets creative juices pumping, and feeds the project... I dunno about you, but after a few years of pushing toward the same goal I tend to get a bit jaded. There’s nothing like the arrival of someone who’s turned on by the Microship fantasy to get fresh ideas percolating and knock a few jobs off the list (especially TBDWLs). (Editor’s helpful gloss: To Be Dealt With Later.)
It occurred to me a few years ago that I could carry this amusement theme to the next level by formalizing a “geek’s vacation program.” It’s simple: we invite clever folks to come stay with us for a week or so, taking a break from their normal jobs to do design or fabrication work for the pure pleasure of it. We provide food, beverages, a frolicsome atmosphere, and a few outings of playing tourist here in the Pacific Northwest. In exchange, we get the focused intellectual energy of some truly amazing people, and always manage to learn something.
It didn’t occur to me in the Early Days, but another one of the most alluring features of these projects, from the perspective of our volunteers, has been purely social. Once it reached critical mass, with enough participants to make overlap likely, a new component entered the picture: folks would come by the lab to help, then meet each other and form new friendships. This has led to businesses, lasting relationships, and uncountable pizza nights... I’m not the only one who tires of working alone, it seems. If you make your Gonzo Engineering project entertaining enough to lure clever people, you’ll find that it might take on a life of its own. That’s where the real magic begins.
A skunkworks-like microculture developed around my projects, attracting programmers and machinists, hams and cyclists, human-powered vehicle gurus and chip designers. I recall one night a few weeks before the long-awaited launch of BEHEMOTH back in 1990... the stereo jamming, the windowless lab at Sun Microsystems a sea of fluorescent-lit clutter, the SPARC beeping every few minutes with incoming mail as I worked to nail down the logistics of the tour. Michael Perry was writing FORTH code to drive the audio crossbar, Steve Sergeant was chasing a noise problem, Steve desJardins was working on the landing gear 4-bar linkage, and Zonker Harris was squinting into a dense matrix of Lemo connector pins with a soldering iron in his hand. Over at the Rockwell milling machine named Cecil (Cecil be da Mill), David Berkstresser was standing in a sea of aluminum chips, conjuring a piece of structural artwork for the bike’s trailer hitch. I heard the mill spin down, then David hollered, “Hey! Does it ever make you feel funny that so many people are working so hard to get you out of town?”
The Microship, the result of an 8-year development project involving extensive sponsorship, students, and volunteer teams. This is an amphibian pedal/solar/sail micro-trimaran with retractable wheels, hydraulic systems, 480 watts of peak-power-tracked solar panels, and zippy performance under sail. BEHEMOTH, the Microship, and the later Nomadness project are all documented at microship.com.
There is yet one more “intangible” motivation before we get to some of the more traditional methods of luring people into your lair. If you’re doing something that’s pushing envelopes and is exciting to media and sponsors, it’s a fair bet that it represents a very real learning opportunity. We’ve had people offer to help with “anything at all, even sanding,” just for the chance to hang around the lab and absorb techniques or arcane knowledge. The irony here is that this is one of my main motives as well, and is perhaps the source of my greatest pleasure in working with volunteers. In the process of grappling with interesting problems, everybody brings something to the party and the educational opportunities are endless.
Sharing the Wealth
And then there’s the stuff that really makes a geek’s eyes light up: new toys. In the midst of all your rhapsodizing to a potential volunteer about education, networking, and fun, it never hurts to mention that there may be excess goodies to share. I’ve had leftover antennas, computers, radios, nautical components, and more—much of which has found a new home with some of our star volunteers as an extra “thank you” for all the help. There’s an ethical component here as well: quite a bit of this is sponsored, and it feels a bit weird to take donated stuff and hawk it on eBay (I’ve done it a few times, but only with explicit approval from the sponsor or in cases where the company no longer exists). Passing along a few extras to people who have participated in the project feels reasonably consistent with the spirit of the gifts, and certainly generates a lot of smiles. So do team T-shirts.
Paying for It
Despite all the motivations folks might have for hanging around and helping you for free, however, we still have to accept the annoying truth that people have other things to do with their time. This translates into having to find more traditional ways to get help... and if you’re anything like me, your dream project probably doesn’t include a budget for full-time employees. For a while during the dotcom boom, I was able to make enough from corporate speaking gigs to keep a composites guru on-site, but even that was a non-traditional deal that included room and marginal board (in an old camper) as part of the consultancy package. Actual employees are another matter entirely, opening up regulatory cans o’ worms, workman’s comp insurance, and the expectation of timely paychecks.
But there are alternatives.
First, if the associated business model we discussed earlier is generating cash flow, you can “share the wealth” by giving someone a piece of the action to take an active role. Given that the project itself is coupled synergistically with the nickel-generator, this may translate into on-site help that can keep you moving through the creative doldrums.
Second, if you have a tight relationship with a sponsor and are in the process of conjuring something that the company might be interested in leveraging, then you might be able to bargain for time from one of their employees. This is great, as you don’t have to play business-owner any more than necessary, and if the project doesn’t reach escape velocity you haven’t thrown a wrench into anyone else’s career.
I would be careful with bartering a vague “partnership” unless the project has a very real deliverable and corresponding business model. This is usually not the case with the kinds of passionate pursuits we are considering, and things can change a lot between concept and execution. If someone has been faithfully putting in the hours with the promise of residuals from future patent or book royalties, and instead gets to watch you getting Slashdotted and BoingBoing’d all by yourself, you could have anything from a lost friendship to a lawsuit on your hands (depending on how close your understanding was to a “legal contract”). Seriously, be careful with this. Don’t get into that kind of debt. Or any kind, if you can help it.
There is one other way. Lemme tell you a tale of Microship development...
In the Spring of ’93, I arrived in San Diego to speak at Qualcomm, one of my favorite sponsors—the creators of the bike’s satellite communication system and gurus of CDMA and other DSP-flavored wizardry, a company managed by engineers instead of MBAs. A friend there pointed me to nearby Scripps Institution of Oceanography, where I might have a chance to pick up a few tricks from guys who know how to keep electronics working at sea (a non-trivial problem, with delicate high-impedance circuitry surrounded by conductive aqua regia). Armed with an introduction, I wandered over and did a casual bike show ’n tell for a Friday afternoon Scripps cookout.
As I was standing by the keg nursing a pint, my bike parked a few feet away and the surf pounding just beyond, a classic Hollywood stereotype of the brilliant young PhD walked over and said, “Fascinating. Have you gotten any results yet?”
“Well, I’ve fallen in love a few times,” I answered.
He looked at me blankly for a moment and then cracked up. “No, seriously...”
This was my introduction to academia. I hung around a few days, seeking space at the Scripps facilities, eventually managing to arrange a secure place to park the diesel Mothership and stash my gear in a run-down storage facility in a desolate nearby canyon... but with no net connection, phone, or actual workspace. It was an excellent toehold, though, and the chain of contacts kept growing as I explored the couch circuit. A few days later I met with a professor in the Electronic & Control Engineering department at UCSD (University of California at San Diego).
Almost immediately a potential win-win emerged. Although it wasn’t widely viewed as a problem among the academics, there was a serious shortage of hands-on engineering opportunity for students: they could actually make it through four years and get an undergraduate degree without ever picking up a soldering iron. I found this shocking, and had a solution to offer: “Hey, give me some lab space and I’ll teach a senior projects class.”
I stumbled into university culture with naivete? and an utter disregard for hierarchies—to me, there was no essential difference between deans, chancellors, TAs, and professors. Only much later did I understand that there is a pervasive caste system, which explained my tendency to ruffle feathers. Other than holding on to lab space long enough to get the Microship built, however, I had no pretensions of a career, publishing in refereed journals, or chasing the holy grail of tenure.
Nor did I anticipate the complex politics of space wars. My first lab was an abandoned bookstore... but the day after I installed a monitored security system and set up a working facility, a construction crew hacked straight through the drywall, knocked down shelving, looked around in annoyance at my stuff, and asked me what the hell I was doing there. “We’re tearing out this end of the building and you gotta get this crap outta here NOW, before our contract penalty clause kicks in and costs us a thousand bucks a day. Which is what it’s gonna cost you.” But this disaster was tantamount to a back door from the institution-hacking perspective: now that finding space for me could be defined as an emergency, I landed within a few hours in the Microwave Lab, vacant for the quarter and perfect for my needs.
I moved out two years later.
Occasionally real professors wondered aloud what some rube without a degree was doing with 800 square feet of prime lab space, complete with a dozen benches, adjoining office, and Faraday cage. “I hear he’s having those kids build circuit boards. “What the hell does he think this is, a vo-tech school?” But I was fortunate to have three faculty members solidly on my side (the only ones who had worked in industry), and was buffered by a well-publicized program that gave students the chance to design and build real systems, not just run simulations as an antidote to the textbook world of lumped constants and zero-rise time pulses (much .edu about nothing).
The experience did cure me of any lingering wistful regret about having missed those idyllic college years, despite the daily consumption of epicurean cafeteria fare. All around me, students were undergoing a sort of extended agony of uncertainty and stress, many of them deep into engineering school without any notion of what real engineers actually do. But what mattered most was assembling an effective student team every quarter, learning how to be a manager, and getting on with the project. My job was to identify and attract folks on the fringe, give them interesting design challenges, and leverage their work to propel myself into the next adventure.
Within a few months we had about ten FORTH nodes scattered around the lab on benches arranged like finger piers in a marina, all chained to a Hub and forming a classroom-scale Microship emulator by a braided 6-wire bus and running a protocol designed by one of our wizard volunteers (giving us pier-to-pier networking).
Nodes were assigned to any task that could be clearly defined, and some of the student teams produced decent work. Audio, serial, and video crossbar networks flickered to life, collectively forming Grand Central Station. A couple of shy fellows managed with a little coaching to decode the communications between a Sony DAT recorder and its remote control, then replicate it to allow software to drive the unit. (“This is the happiest moment of my life,” one said as they arrived, newly confident, to give their final report in suits and ties.) After a couple of failed attempts, we found two guys to design the controller for the boat’s video turret with its steerable high-quality camera: Working with a wizard student from the Mechanical Engineering department who designed the mechanics, they conjured a beautiful piece of work that survived all the technological attrition of the ensuing years and became part of the final system. These were the exceptions, and they made it all worthwhile.
Other projects weren’t so successful. The first attempt to write a GUI for the crossbars took two guys two quarters, yielding a fat listing of impenetrable C code for a ’286 that talked directly to the display drivers. It never really worked, but the fault lay with my vague specifications; exasperated one afternoon, I learned HyperTalk and wrote a Mac-based front end in about six hours. Some teams never got past their initial learning curves, and one pair working on power management turned their final report into an explanation of the FET, complete with characteristic curves and massive amounts of replicated library material, counting on the ancient tradition of BS to carry the day. One fried the fuse in my beautiful new Fluke multimeter trying to measure the current capacity of a power supply by measuring across it; I sent him downtown on a quest for a replacement with the explanation that one of the first requirements of engineering is knowing how to track down parts. Someone power-cycled my Tektronix scope with every measurement; someone else cut a live multi-conductor power cable with diagonal cutters and made the sparks fly; yet another wired a fully populated DB-25 with about a half-inch stripping on each wire, rendering it virtually untouchable without causing a short. And I’ll never forget, “Steve, do these colors on the resistors really mean anything?”
But you know, it was worth it. I relate all this to give a realistic view of the Gaussian distribution curve, which has to be taken into account when accepting free help in a classroom setting. In sum, I consider it a win-win.
Making the Academic Connection
Now that I have either teased you or frightened you with visions of naive students poking with sharpened sticks at your delicate labor of love, I should add that this is not an easy relationship to initiate, nor is it always something you want. Only a small number of engineering schools offer the quality of education that is likely to return more value than it costs you to deploy... if you want to be a volunteer teacher, that’s fine, but if you are hoping a team of bright-eyed young geeklets will speed your dream on its way to reality, you’ll need to be willing to take charge of a few things. Choose the institution carefully, be sure you are able to drive the project-definition and ongoing assessment processes, maintain close faculty alliances, and put serious time into fine-tuning all the associated relationships.
One more caveat: student project energy is viewed as a scarce resource in the very places where the quality is likely to be highest, and I have run into places where a savvy faculty member is already guarding it jealously with no shortage of pet projects in reserve. Such people will make it highly difficult for you to get a foot in the door, necessitating a higher level of institution-hacking (or, more likely, looking elsewhere entirely).
If your nearby school looks promising and goes well beyond textbooks (or wants to, and sees you as a resource to that end), spend some time making connections among students, professors, and alumni. What do they want? PR? IP rights to anything invented on-site? Leveraged corporate sponsorship with the companies you already have on board? Curriculum development? Or just a lighter workload for their own lazy or inexperienced teachers? The latter can make for easy entry, but can also backfire if it is an indicator of overall academic sloppiness... whether the result of incompetent faculty, or tenured people more interested in publication and funding than undergraduate engineering education. This is more common than one might hope, alas.
I hope I have given you some useful tools in this little series. Every gonzo engineering project depends most obviously upon whatever flavor of geek expressionism lies at its core, yet it is excruciatingly vulnerable to the realities of human limitation. The basic rule is to just keep moving in the same direction for a long time, but that isn’t enough... even if you are of the Wizard class, eventually you still need stuff, exposure, cash flow, and help.
The tips I have presented here are not theoretical. In 1983 I fled the suburban lifestyle and took off across the US on a recumbent bicycle. 17,000 miles later, I was on the third version of the bike and had a book under my belt as well as relentless media coverage, a team of volunteers, and enough corporate sponsors to make the massive undertaking possible. A crazy dream had turned into a career; now, over 25 years later, I am still reaping the benefits of this process when working on my new projects. I mentioned at the beginning that I was about to reveal all my “trade secrets,” things I’ve never publicly discussed before.
This is true, and the reason is that it is kind of a zero-sum game. In the heat of the BEHEMOTH bicycle era, I was not only careful about inviting competition into my odd little niche, but also conscious of the delicacy involved in the intertwined mesh of relationships... all critical to the ongoing operation. It would not have felt right to publicly explain how to schmooze for goodies or gently manipulate the media into helping build a consistent image when I was dependent upon such relationships for my very existence.
But this is valuable information, as timely as ever, and as I make the transition to a full-time life aboard a voyaging sailboat I find that I’m willing to share now. Enjoy. And good luck!
Steven Roberts was the original “technomad,” covering 17,000 miles around the US on a computerized recumbent bicycle from 1983-1991 while publishing tales via CompuServe and GEnie, then extending the same design objectives to water with an amphibian pedal/solar/sail micro-trimaran that consumed all available resources until 2002. As is typical of homebuilt boat projects, however, by the time it was finished he didn’t really want to do that anymore... so he has since made the transition to a full-time life aboard a 44-foot steel pilothouse sailboat, and is now based in the San Juan Islands north of Seattle.
The ship is extensively networked with embedded data collection and control systems, streaming telemetry, and a user-interface layer reminiscent of the Enterprise... with a wrap-around console that includes communications, R&D lab, audio production studio, and a piano. Roberts has published six books ranging from travel and adventure to microprocessor design, and prior to becoming a technomad spent a decade developing custom industrial control systems, early home computers, and other paleo-geekery. More on his technomadic projects can be found at microship.com (with the new boat at nomadness.com). He is publishing the ongoing technical narrative of the new project as a monthly PDF Nomadness Report, as well as a series of Boat Hacking design packages detailing the subsystems.