Chapter 7 Open Hardware

A market where customers help you develop your products and then pay you for them? Sure— just give away the bits and sell the atoms.

One Sunny Friday afternoon in March 2007, I started plan­ning what Γd hoped would be a deliciously geeky weekend with the kids.

But by midmorning on Saturday, things were already going wrong. The kids were happy enough to open the Lego Mindstorms box and assemble the starter robot, a three-wheeled rover, but once we plugged in the batteries they could barely hide their disappoint­ment. Hollywood, it turns out, has ruined robotics for kids: they ex­pect laser-armed humanoid machines that can transform into trucks. Meanwhile, after an hour of assembly and programming, the Mind­storms rover could only roll forward and bounce feebly off a wall. We looked online to see what others were doing with Mindstorms, and saw that hobbyists had already made everything from robotic Rubik’s Cube solvers to working photocopiers. We wanted to invent some­thing new, but there was no way we could do that sort of thing, or anything even close to it. The kids lost interest after lunch.

Okay, there was always the plane. On Sunday we took it to a park. I tossed it in the air and promptly flew it into a tree. The kids just looked at me, equally appalled by my lack of ability and the gap be­tween my promise of how cool the plane would be (and the spectacu­lar YouTube videos of aerobatics we’d watched) and how uncool it had actually turned out to be. I threw sticks at the plane in the tree to try to dislodge it, while my mortified children pretended not to be with me.

While on the run, I started thinking more about the sensors that were available for Lego Mindstorms. There were accelerometers (“tilt sensors”), electronic gyroscope sensors, a compass sensor, and a Blue­tooth link that could connect to a wireless GPS sensor. They were actually pretty amazing, and it occurred to me that those were exactly the same sensors that you’d need to make an airplane autopilot. We could kill two birds with one stone: invent something cool with Lego that had never been done before and get the robot to fly the plane! It was sure to be a better pilot than me.

The moment I got home, I prototyped a Lego autopilot on the dining room table, and my nine-year-old helped write the software. We took some pictures, posted them, and it was on the front page of Slashdot by that evening. We put it in a plane—the world’s first Lego UAV, I think—and took it out a few weekends later. It almost kinda worked—it was definitely staying aloft and steering on its own, albeit not exactly where we had intended.

At that point I went down the rabbit hole, and resolved to improve it until it worked as Γd dreamed, a quest that Γm still on years later. (The kids, sadly, lost interest within days, and returned to their usual staple ofvideogames and YouTube, both of which offer more immedi­ate gratification.)

I worked on some improved versions of the Lego autopilot, even­tually developing one that had most of the mission-following func­tionality of a professional autopilot, if not the performance (it’s now in the official Lego museum in Billund, Denmark). But it was soon clear that Lego Mindstorms, for all its charms, was not the right way to make a real autopilot: it was too big and expensive, for starters, and didn’t then have a good way to work with radio-control systems.

What would be a better way? I decided to conduct my search for answers online in public, sharing what Γd done and found.

That distinction—a site created as a community, not a one-man news and information site like a blog—turned out to make all the difference. Like all good social networks, every participant, not just the creator, has access to the full range of authoring tools: along with the usual commenting, they can compose their own blog posts, start discussions, upload videos and pictures, and create profile pages and send messages to each other. Community members can be made moderators, to encourage good behavior and discourage bad.

What this meant was that the site wasn’t just about me or my ideas. Instead, it was about anyone who chose to participate. And right from the start, that was almost everyone. The site was soon full of people trading ideas and reports of their own projects and research. Initially, members would just post code and design files, trading ideas back and forth in a form of nerd braggadocio. But over time we set up more-organized systems of collaboration, including version con­trol systems and file repositories, wikis, mail lists, and formal team assignments.

I was blown away by what I was seeing people in our community doing with sensors from mobile phones and chips that cost less than a cup of coffee; feature-by-feature they were equaling aerospace elec­tronics that had cost millions of dollars just a decade earlier. It felt like the future of aviation: just as the PC emerged from the Homebrew Computer Club hobbyists and eventually overturned the industrial corporate computing world in the 1980s, I could imagine that the same sort of movement could be the way that robots were introduced to our skies. We were present at the creation. If there was going to be an Apple Computer of this industry, it should be us!

At this point my entrepreneur instincts kicked in. Something in my wiring forbids the notion of fun for its own sake; instead, every­thing must be building to a purpose.

My first cottage industry

I started my first aerial robot business on the proverbial dining room table. Using a blimp controller design created with a community mem­ber, I started assembling the parts necessary for a kit. I sent the cir­cuit board design files off to be fabricated, and began hunting around for good deals on other electronics parts that I could buy in volume. Weeks of sourcing followed, with the simple rule that manufacturers should never pay retail for their materials. Motors from China, Mylar blimp “envelopes” from a warehouse in Canada, propellers from Tai­wan, a big box of custom laser-cut plastic shapes for the base, and stacks of flat-packed cardboard pizza boxes to put them in. (I also got Lego to donate a big box of gears and shafts.)

The first few dozen boards I hand-soldered together, before vow­ing to Never Do That Again. Then I advertised on Craigslist for a local student to do another hundred or so, which turned out to be more trouble than it was worth. Finally I just did what I should have done from the start and contracted with an assembly firm to do a few hundred more properly, with automated pick-and-place machines. A big box of the finished boards arrived at my doorstep, and I spend an evening testing them and loading their software.

Finally it was time to pack the kits. We had all the components, and I bribed the kids to be my packing team. Piles of parts with Post-it notes specifying how many should go in each box spread over the dining room table and floor.

For the community’s next product, an airplane autopilot board, we decided to put things in the hands of professionals. The one that seemed culturally matched was Sparkfun, which designs, makes, and sells electronics for the growing open-source hardware community. Because they handled all the sourcing and manufacturing, our com­munity could spend our time working on R&D and bear no inven­tory risk.

But, over time, our community started designing products faster than Sparkfun could adopt them, and many were too niche for Spark­fun’s store. It was time to start our own factory. I started a proper company, 3D Robotics, with a partner, Jordi Munoz (of whom much more later).

In a rented Los Angeles garage, Munoz started building our own mini Sparkfun. Rather than a pick-and-place robot, we had a kid with sharp eyes and a steady hand, and for a reflow oven we used what was basically a modified toaster oven. We could do scores of boards per day this way.

As demand picked up, we outgrew the garage. Munoz moved the operation to commercial space in an industrial park in San Diego, which was nearer the low-cost labor center of Tijuana. In came real automated manufacturing tools: first a small pick-and-place machine, then a bigger one, and finally an even bigger one with automated component feeders. The toaster oven gave way to a proper automated reflow oven with a nitrogen cooling system for perfect temperature control. And for that we needed a nitrogen generator, of course. And so it went, with more and more professional tools, which Munoz and his team learned to use by finding tutorials on the Web.

By this time we had outgrown the first space and expanded to a bigger space next door. Then we outgrew that, too, and today 3D Robotics has a factory that sprawls over twelve thousand square feet.

From Maker to millions

In our first year, we did about $250,000 in revenue; by 2011, our third year, we had broken $3 million. In 2012 were on track to break $5 million in revenues. Growth continues at about 50 percent per year, which is common for open source hardware companies like ours. We’ve been profitable from the first year (it’s actually not that hard in the hardware business—just charge more than your costs!), but try to reinvest as much of the profits as possible into building new factory lines, including one in Tijuana. Because we’re online, we’re global from the start and tend to grow more quickly than traditional manu­facturing companies because of the network effects of online word of mouth. But because we’re making hardware, which costs money and takes time to make, we don’t show the hockey-stick exponential growth curve of the hottest Web companies.

So, as a business, were a hybrid: the simple business model and cash-flow advantages of traditional manufacturing, with the mar­keting and reach advantages of a Web company. We’re still a small business, but the difference between our kind of small business and the dry cleaners and corner shops that make up the majority of micro-enterprise in the country is that we’re Web-centric and global.

We’re competing in the international market from day one. The usual trap of focusing on the local market first with hopes of expand­ing internationally later leaves companies unprepared for global com­petition. Selling to the whole world on day one makes a company stronger. Today, two-thirds of our sales come from outside the United States. And with global reach comes the capacity to grow far beyond what local markets could support.

Make a profit. Really.

Profit is always a tricky question for Web companies, since they tend to put a priority on growing traffic, and charging money gets in the way of that. But for hardware, which has inherent costs and must be paid for, charging the right price is key to building a sustainable business.

One of the first mistakes budding Makers make when they start to sell their product is not charging enough. It’s easy to see why, for all sorts of reasons. They want the product to be popular, and they know the lower the price, the more it will sell. Some may even feel that if the product was created with community volunteer help, it would be unseemly to charge more than it costs.

Such thinking may be understandable, but it’s wrong. Making a reasonable profit is the only way to build a sustainable business. Let me give you an example. You make one hundred units of your de­lightful laser-cut handcrank toy Drummer Boy. Between the wood, the laser cutting, the hardware, the box and the instructions, it costs you $20 to make each one. Let’s say you price them at $25 just to cover any costs you may have missed, and start selling.

Since it’s a fun kit and pretty cheap, it sells quickly. You suddenly realize that you’ve got to do it all again, this time in a batch of one thousand. Rather than putting up a couple thousand dollars to buy the materials, you’ve got to put up tens of thousands of dollars. In­stead of packing the kits in your spare time, you’ve got to hire some­one to do it. You need to rent space to store all the boxes, and you’ve got to make daily trips to FedEx.

Now your hobby is starting to feel like a real job. Worse, the popu­larity of your kit has come to the attention of some big online retail­ers, and they’re asking about buying in batches of one hundred, with a volume wholesale discount. You’re thrilled that your kit is so popular and flattered that these retailers, who can reach many more people than your own website, want to sell it. But if you’re selling it at $25, that’s the market price—the retailers typically can’t sell it for more. The retailers ask for a lower price because they need to make their own profit on each one, usually around 50 percent. So they need to buy them at no more than $17 each. But that would mean you are selling each one at a loss! Your costs, which were once within the limits of hobby spending, are now at risk of driving you and your business into debt.

What entrepreneurs quickly learn is that they need to price their product at at least 2.3 times its cost to allow for at least one 50-percent margin for them and another 50-percent margin for their retailer (1.5 ? 1.5 = 2.25). That first 50-percent margin for the entrepreneur is really mostly covering the hidden costs of doing business at scale that they hadn’t thought of when they first started, from the employees that they didn’t think they’d have to hire to the insurance they didn’t think they’d need to take out and the customer support and returns they never expected. And the 50-percent margin for the third-party retailers is just the way the retail market works. (Most companies ac­tually base their model on a 60-percent margin, which would lead to a 2.6x multiplier, but Γm applying a bit of a discount to capture that initial Maker altruism and growth accelerant.)

In other words, that $20 kit should have been priced at $46, not $25. It may sound steep to you now, but if businesses don’t get the price right at the start, they won’t be able to keep making their prod­ucts, and everyone loses. It’s the difference between a hobby and a real, thriving, profitable business. It’s also worth bearing in mind that at this more bespoke end of the market, products can generally sup­port a higher price. Customers are both keen and savvy: they are pre­pared to spend a bit more because they know that they are getting exactly what they want. It’s an attractive business model.

Open design’s advantage

Today, we use the products of open software innovation every day: the Firefox Web browser, Android phones, the Linux Web servers that run most of the websites we go to, and countless other elements of the open-source software that the Internet is built on. Tomorrow the same may be true for hardware, too. I’ve driven in open-source cars (the Local Motors Rally Fighter, of which you’ll hear more later) and watched open-source planes fly. There are open-source rock­ets designed to reach space, as well as open-source submarines. We have open-source watches and alarm clocks, cappuccino makers, and toaster ovens.

In a sense, all these companies give away the bits and sell the atoms. All the design files, software, and other elements that can be de­scribed in digital form—the bits—are given away freely online, under a license that usually offers almost unrestricted use as long as it contin­ues to be open and shared. But the physical products themselves—the atoms—are sold, because they have real costs that must be recouped.

Every day, we see more and more examples of open-hardware busi­ness models working brilliantly. The MakerBot Ç-D printer is open hardware, as is the RepRap on which it is built. So is Arduino, and the hundreds of products from companies such as Adafruit, Seeed Stu­dio and Sparkfun. Research by Adafruifs Phillip Torrone concludes that there were more than three hundred comercial open-hardware products by the end of 2011, representing more than $50 million in annual revenues.²⁷

Openness, in fact, is exactly what Thomas Jefferson and the Founding Fathers intended when they made the Patent Act one of their first orders of business in the new United States of America in 1790, a year after the Constitution was ratified. As they saw it, the point of a patent—a guaranteed monopoly granted for a limited time—was not primarily to ensure that the inventor made money; after all, they could do that more easily by keeping the invention a trade secret. Instead, it was to encourage the inventor to share that invention publicly so that others could learn from it. The only way an inventor could license a patent was if he or she published it, ensur­ing that society as a whole could benefit from the invention. (Science works the same way, with credit and career advancement depending on publication in journals.)

Today, inventors increasingly share their innovations publicly without any patent protection at all. That is what open source, Cre­ative Commons, and all the other alternatives to traditional intellec­tual property protection are. Why do they do so? Because the creators believe they get back more in return than they give away: free help in developing their invention. People tend to join promising open proj­ects, and when those projects are shared, the contributions are auto­matically shared, too. Inventors also get feedback as well as help in promotion, marketing, and fixing bugs. And they accrue “social capi­tal,” a combination of attention and reputation (goodwill) that can be used at a future date to advance the inventor’s interests.

A product that has Successivelybeen created in an open innovation environment does not have the same legal protections of a patented invention. But one can argue it has a better chance of becoming a commercial success. Odds are that it was invented faster, better, and more cheaply than it would have been if it had been created in se­cret. It’s already been tested in the marketplace of opinion, at least, and that’s not a bad form of market research. And it’s got a built-in marketing team in its community, evangelists who are invested in its success. Any product that can build a community before launch has already proven itself in a way that few patents can match.

For the companies that are built on open innovation, the advan­tages go beyond simple access to market. A well-constructed “archi­tecture of participation,” to use the term coined by Tim O’Reilly, whose company runs Make magazine, means that hundreds of skilled people may contribute for free, for all the incentives that have been observed in everything from open-source software to Wikipedia, from being part of something they believe in to simply making some­thing that serves their own needs, but choosing to share it because of the community norms.

What that means is cheaper, faster, and better research and devel­opment, which in turn can create unbeatable economics for compa­nies whose products are developed this way. And it’s not just R&D. Product documentation, marketing, and support is often done the same way, by a community of volunteers within a community. Some of the most costly functions of traditional companies can be done for free, so long as the social incentives are tuned right.

It’s what we do for everything at 3D Robotics, and here’s why: when you release your designs on the Web, licensed so that others can use them, you build trust, community, and potentially a source of free development advice and labor. We release our electronics PCB de­signs in their native form (Cadsofts' Eagle format), under a Creative Commons Attribution ShareAlike license (“by-sa”), which allows commercial reuse. Our software and firmware, meanwhile, is all re­leased under a GPL license, which also allows for commercial reuse as long as attribution is maintained and the code stays open. The result: hundreds of people have now contributed code, bug fixes, and design ideas, and have made complementary products to enhance our own.

The simple act of going open-source has provided us with an es­sentially free R&D operation that would have cost hundreds of thou­sands of dollars if we’d been closed-source and had to hire our own engineers to do the work, to say nothing of the quality of that work. By day our volunteers are leading professionals in their own fields—the sort that would have been impossible to hire away. But by night they follow their passions and do great work for us as volunteers. They do it because we’re collectively making something they both want for themselves and want to be part of, and because it’s open-source they know that it will reach more people and attract more talent, creating a virtuous cycle that accelerates the innovation process far faster than conventional development can.

Once you seed your community with content and start attract­ing users, your job is to give them jobs. Elevate people who seem to be constructive participants to moderator status, and give especially friendly and helpful members a “noob ninja” badge. Once you pro- mote/reward enough of them for doing a good job of constructive community-building, you’ll find that members typically help each other, saving you the work.

Finally, the tricky matter of whether to pay volunteers. Γm in favor of offering key contributors to a product a royalty, but don’t be sur­prised if they decline. The reasons can be many: they’re not in it for the money; the absolute payment amounts are tiny compared to what they make in their dayjob; they feel icky taking payment when others who contributed don’t; and finally, when they realize that any royalty you pay will lead to higher prices for consumers, they decline simply because this conflicts with the real reason they contributed, which is to create something that can reach the largest audience possible, and higher prices mean fewer users.

But there are rewards short of simple payment that can be even more motivating, especially for top contributors, who tend to be equally accomplished in their professional life and thus often already well compensated by their dayjob.

Here, for example, is the reward hierarchy we came up with for the DIY Drones dev teams. It ranges from the silly but effective, such as a coffee mug for a “commit” (a commit is a code contribution of any size, which may have only taken an hour or two), to reward that could have significant monetary value, such stock options in 3D Robotics for top contributors.

How to build community

When you go open-source, you’re giving away something in hopes of getting back more in return. Is it guaranteed? No. You also need to build a community, ensure that the initial product is needed, docu­mented, and distinct enough for people to want to join in its develop­ment. And even then, managing an open-source community can be a full-time job in itself. But when it works, it can be magical: an R&D model that’s faster, better, and cheaper than that one of the biggest companies in the world.

When you’re creating a community from scratch, consider start­ing it as a social network rather than as a blog or discussion group. The best new social networking tools allow you to have it all: great blogging tools, great discussion groups, profiles, personal messaging, videos, photos, and more. Some people do this with WordPress and its plug-ins, others use Drupal, but I prefer Ning, which offers hosted tools that will let you create a full-featured social network on your niche topic in minutes.

One of the key elements of a successful community is content of broad appeal, not just discussion forums but blog posts, photo and video sharing, and news feeds. The Makers communities all have this, from the fantastic stream of daily blog posts of MakerBot, Sparkfun, and Adafruit to the video profiles of members on Kickstarter and Etsy

In a sense, such rich, engaging content is marketing—marketing for the community itself, but also the products that the community has created. Whether they think of it this way or not, the most suc­cessful Makers are also the best marketers. They’re constantly blog­ging about their progress, and tweeting, too. They take pictures and videos of every milestone, and post those. Their excitement in mak­ing is infectious, and builds excitement and anticipation for the prod­ucts they ultimately release.

Seen this way, all making in public is marketing. Community management is marketing. Tutorial posts are marketing. Facebook updates are marketing. E-mailing other Makers in related fields is marketing. Of course, it’s not just marketing: the reason why it’s so effective is that it’s also providing something of value that people ap­preciate and pay attention to. But at the end of the day, everything you do, from the naming of your product to whose coattail you decide to ride (like we chose Arduino), is at least partly a marketing deci­sion. Above all, your community is your best marketing channel. Not only is that the source for the word-of-mouth and viral marketing that you’ll need, but it’s also a safe place to talk about your own prod­ucts, as enthusiastically as you want. If you’ve given people a reason to gather that serves their needs and interests, crowing about your cool new gizmo isn’t advertising, it’s content!

Castles without walls

But how can companies built on such open-innovation grounds pro­tect themselves from competition and even piracy? After all, part of the social compact in open innovation is to return the gift, sharing everything with the community that created it. What is their defen­sible advantage?

Is it the brands? Many open-hardware projects share the design files of their products, but reserve their names and logos as propri­etary trademarks. Others can make the same product, but they can’t call it the same product (at least not legally in the countries where the trademarks are registered). Brand can indeed be a defensible advan­tage. But the legal process of fighting infringement of those brands, especially in other countries, can be ruinously expensive. And in an open-source world you can’t assume the clones will be inferior and easy to spot.

Is it the communities? Yes, as long as they’re serving early adopt­ers and other Makers. A Chinese company can make a clone of our products and maybe sell it cheaper, but it won’t have our community, and if our community can spot the clone, they will probably decline to help those who chose not to support the “home team.” But let’s be honest: our communities exist because our products are hard to use. They are mostly support communities, where members help each other navigate confusing and uncharted territory. There’s also a bit of a development community, for the one percent of users who also want to help evolve the products or take them in new directions.

Ultimately, however, the goal of open-innovation projects is to make products that are as good as or better than traditional closed­innovation products. And that means easy to use: well designed and documented. When you go to Target to buy a toaster, you don’t care if it has a community. Great products don’t need great communities. Sometimes great products speak for themselves.

In those cases, the only real defensible advantage is an ecosystem. Not a community of customers, but a community of other companies and innovators who are building products that are designed to work with and support your own. Think of the tens of thousands of apps that support and reinforce Android, an open (mostly) mobile oper­ating system. Or the hundreds of plug-ins and utilities designed to work with Wordpress, the open-source blogging platform. In each case, openness built a constituency for the product’s continued suc­cess. The fact that others could copy it didn’t matter, because that all that goodwill had created a network effect that was far harder to copy than simply code.

But what if someone wants to rip us off anyway? Well, it depends on what you mean by “rip us off.” If someone else decides to use our files, make no significant modifications or improvements, and just manufacture them and compete with us, they’ll have do so much more cheaply than we can to get traction in the marketplace. If they can do so, at the same or better quality, then that’s great: the con­sumer wins and we can stop making that product and focus on those that add more value (we don’t want to be in the commodity manufac­turing business).

But the reality is that this is unlikely. Our products are already very cheap, and the robots we use for manufacturing are the same ones they use in China, at the same price. There is little labor arbi­trage opportunity here.

And even if the products can be made cheaper, at the same quality, there is the small matter of customer support. Our community is our competitive advantage: they provide most of the customer support, in the form of discussion forums and blog tutorials and our wiki. If you bought your board from a Chinese cloner on eBay and it’s not work­ing, the community is unlikely to help—it’s seen as not supporting the team that created the product in the first place.

How will people know the difference between our products and clones allowed by our open-source license? Because the clones can’t use the same name. The only IP that we protect is our trademarks, so if people want to make the same boards, they’ll have to call them some­thing else. This is the same model used by the Arduino project. You can make a copycat board, but you can’t call it “Arduino” (although you can call it “Arduino compatible”). This goes all the way to removing the logo, name, and artwork from the PCB design files that are publicly distributed. It’s a great way to maintain some commercial control while still being committed to the core principles of open source.

Another core aspect of open source is that users can make the products themselves, if they want—no need to pay you for it. That’s great for about 0.1 percent of the user base, and they’re often the best source of new ideas and innovation around the product. But the real­ity is that the other 99.9 percent of users would rather pay someone to do it for them, guaranteeing that it will work. That’s the core of your business.

How to get your “pirates” to work for you

Here’s an example of how it works in practice: In late 2010, someone posted on the DIY Drones site that Chinese copies of our ArduPilot Mega design were for sale on Taobao, eBay, and other online market­places. And indeed they were: well-produced, fully functional clones. Not only that, but our English instruction manual had been trans­lated into Chinese, too, along with some of the software.

Our community members were shocked by this blatant “piracy” and asked what we were going to do about it.

Nothing, I said.

This is both expected and encouraged in open-source hardware. Software, which costs nothing to distribute, is free. Hardware, which is expensive to make, is priced at the minimum necessary to ensure the healthy growth of a sustainable business to ensure quality, sup­port, and availability of the products, but the designs are given away free, too. All intellectual property is open, so the community can use it, improve it, make their own variants, etc.

The possibility that others would clone the products is built into the model. It’s specifically allowed by our open-source license. Ideally, people would change/improve the products (“derivative designs”) to address market needs that they perceive and we have not addressed. That’s the sort of innovation that open source is designed to promote. But if they only clone the products and sell them at lower prices, that’s okay, too. The marketplace will decide.

By the way, the Arduino development boards have gone through exactly the same situation, with many Chinese doners. The clones were sometimes of lower quality, but even when they were good, most people continued to support the official Arduino products and the developers who created them. Today clones have a small share of the market, mostly in very price-sensitive markets such as China. And frankly, being able to reach a lower-price market is a form of innova­tion, too, and that is no bad thing.

Personally, Γm delighted to see this development, for four reasons:

1. I think it’s great that people have translated the wiki into Chi­nese, which makes it accessible to more people.

2. It’s a sign of success—you only get cloned if you’re making something people want.

3. Competition is good.

4. What starts as clones may eventually become real innovation and improvements. Remember that our license requires that any de­rivative designs must also be open-source. Thinkhowgreatwould it be if a Chinese team created a better design than ours. Then we could turn the tables and produce their design, translating the documentation into English and making them available to a mar­ket outside China. Everybodywins! (Hey, a guy can dream ;-))

Shortly after I wrote this, a member named “Hazy” responded in the comments that he had been working with the team that had made the boards, and was the one doing the translation. I complimented him on the speed at which it had been done, and then asked him if he’d consider porting to the translation to be part of our official manual, which takes the form of a wiki on Google Code, where our repository is. He agreed to do so, and so I gave him edit permission to the wiki and otherwise set it up for a parallel Chinese translation that users could select.

At the time, we were using the Subversion version-control system (were now using Git), and Google Code had a relatively basic imple­mentation of it. The wiki pages were just files in the same repository as the source code for our autopilots, and I hadn’t investigated the permissions options very well. To let people edit the wiki, I just gave them blanket “commit” access (the ability to create and edit files) to the whole repository.

When I gave community members such access, I usually asked them not to mess with the code by mistake (membership in the code development teams was more exclusive, because the danger of mess­ing things up was higher), but in the case of Hazy I forgot.

The first thing Hazy did was integrate the Chinese translation of the manual seamlessly, so users could simply click a link to switch easily between the two languages.

Then, because he was an expert in our autopilot (he had, after all, been part of the team that cloned it), he started making corrections in the English manual as well. I could see all the commits flowing by and approved them all: they were smart, correct, and written in perfect English.

Then it got interesting: Hazy started fixing bugs in the code itself. The first time this happened, I assumed he’d made a mistake and pushed a wiki file into the wrong folder. But I checked it out, and it was code and his fix was not only correct, but properly documented. Who knew that Hazywas a programmer, too?!

I thanked him for the fix, and thought little more of it. But then the code commits kept coming. Hazy was working his way through our Issues list, picking off bugs one after another that the dev team had been too busy to handle themselves.

Today he is one of our best dev team members. I’ve still never met him, but after a while I asked him a bit about himself.

His real name is Xiaojiang Huang. He lives in Beijing, and by day he is a Ph.D. student in computer science at Peking University.

He told me his story:

When I was a kid, I was fascinated by all kinds of models, and I wished I could have an RC plane. Several years later, I was able to afford an RC helicopter when I graduated from college. I also got RC trucks and planes. Sometimes I am derided as naive for playing with “toys,” but Γm happy because if s my childhood dream. I met ArduPilot by chance when I was surfing the Web, and was attracted by its powerful functions. Some friends of mine were also interested in it, but they felt a little inconvenient because of the English documents. So I tried to translate them into Chinese, hoping to reduce the difficulty of playing with ArduPilot for the Chinese fans. Thank you for the great work of DIY Drones, and I hope it will help more people make their dreams come true.

What happened there is magical. When we first got word of the cloned boards, some in our community Initiallyjumped to the conclu­sion that this was another case of blatant Chinese piracy and wanted to know when we were going to sue. But when I reminded them that this was not a “pirated” version, but instead a “derivative design” fully permitted and even encouraged by our open-source license, the tenor changed.

Because we did not demonize the Chinese team, but instead treated them as part of the community, they acted that way, too. Hazy stepped forward and, rather than just exploiting our work, contrib­uted to it as well.

So now at least some of the “pirates” work for us. Instead of just using our technology, they’re helping us to improve the technology for everyone. “Hazy” realized his dreams, and in doing so helped us realize ours, too.