= a site for all things about amateur Unmanned Aerial Vehicles (UAVs): How-to's, videos, discussion and more
URL = http://diydrones.com/
Company for developing and selling aerial robotics technology
"DIY Drones, which has blossomed into a community of 30,000 registered members. The site gets 1.4 million page views a month, has 6,000 blog posts, 8,000 discussion threads, and 80,000 comments a year. Anderson has marshaled that community to create open-source software for all sorts of drones." (http://venturebeat.com/2012/07/27/open-source-model-disrupts-the-commercial-drone-business/)
- DIY Drones now has 30,000 members, with 1.5 million pageviews a month. (February 2014)
"In the beginning, the DIY Drones projects were simple, but as his community grew, so did its ambition. The cheapest military-grade unmanned aerial vehicle (UAV) on the market is the Raven, which retails for $35,000, with the full system for $250,000. One of DIY Drones' first major projects was an attempt to build an autonomous flying platform with 90 percent of Raven's functionality at a radically reduced price. The members wrote and tested software, designed and tested hardware, and ended up with the QuadCopter. In less than a year, and with almost no development costs, they created a homebrew drone with 90 percent of the Raven's functionality for just $300 -- literally 1 percent of the military's price.
The DIY Drones community has developed 100 different products in the same way, each in under a year, for essentially zero out-of-pocket development cost."
Why It Works?
""Bill Joy's famous quote, 'Whoever you are, the smartest people in the world don't work for you' is as valid as ever," Anderson said. "This was a paradox of 20th-century management. The reason companies were created in the first place was to minimize transaction costs through a shared vision and shared responsibility. You hire people and you put them under one roof and you give them roles and responsibilities so that you can get things done. The consequences of this approach, of course, means that you needed to first find the people, hire them, use some filter to determine whether they were sufficiently qualified. We end up focused on people's 'credentials.' The reality is that most of the world's smartest people don't have the right credentials," he said.
"They don't speak the right language. They didn't grow up in the right country. They didn't go to the right university. They don't know about you and you don't know about them. They're not available, they already have a job. All of these issues are barriers to putting them under one roof to solve the employment equation of 20th-century management," he said. "We now have an alternative to this approach. The alternative is building a team in public: If you build communities first and open source them, you don't have to find the right people. They find you."
Anderson started the DIY Drones community fueled by his enthusiasm around what he had discovered and what he hoped to do. Chief among his learning on making the community work was his willingness to be open, authentic and intimate. "I created a social network," he said, "this simple act of chronicling my journey of discovery in this field I knew nothing about, doing it in public on a site that invited other people to participate. The simple act of choosing to share my ignorance, my discoveries and be willing to be stupid in public invited other people to say, 'I've been wondering that too, and here's an answer.' If you're stupid, then people will help you, but if you act super-smart, people will be scared to help you."
This openness invites openness. "It's intimacy, it's authenticity, it's willingness to ask dumb questions in public," Anderson said. "That simple lowering of the barrier to entry along with things like Arduino [the open-source electronics prototyping platform], which was the platform we ended up choosing, allowed people to see that it was really easy to get started."
Chris built the site not by emphasizing its high-tech credentials, but by opening it up to innovation from the crowd. By choosing to work with Arduino, which offers accessibility but not the highest-tech products, Anderson was mocked at first. But in the end, he said, that accessibility was what was important. "It's easy to pick up, hard to master -- and we bet on social rather than technology," allowing the community to come back with better ideas for using it.
"We bet that the community-accessibility aspects of Arduino would ultimately overwhelm any of the kind of technical specs," he said. "That proved out to be right. Today we have one of the highest-performing autopilots out there with one of the lowest-performing hardware platforms. What does that tell you? It tells you that smart people and great algorithms at the end of the day are the most important things. It's not about your clock speed. It's about the brains and the vision and the talents that went into the crowd."
So how do you use a community to drive innovation in a new product? Here are Chris Anderson's top three lessons learned:
1. Be open in everything. "There was so much to learn, and everything I learned I'd share because I didn't have any particular pride in what I was supposed to know," Anderson said. "Everybody had permission to post, and we had guidelines. Over time, others started following the guide, the same style and format, and then people started working on projects together and posting videos of those. They shared."
2. Use version control. In other words, make it understandable. "The first thing we realized is that the secret to open source is two words: version control," Anderson said. "Sharing is necessary but not sufficient. You need to share in a way that invites other people to participate. Until you commit something to a version-control system (i.e., a format where people understand how you're documenting it, where changes can be made, tracked and reverted to if they're wrong), it never takes off."
3. Encourage participation. "We call it architecture participation," Anderson said. "Architecture participation is like a great videogame: easy to start, hard to master. Architecture participation means that everybody sees this project and says there's something for me to do, and whether that something is simple as correcting a typo in the documentation or submitting an incredible algorithm they've been working on for five years, you just find a way to plug it right into the existing architecture. It's hard," Anderson added. "It requires things that engineers don't like to do, such as documentation, clear comments, being transparent about the plan, sharing stuff before it's ready. That's the hardest thing: getting people to share stuff before it's done. Nothing good has ever happened by waiting until it's done. It happens by putting it out there when you're embarrassed about it and having people help you finish it." (https://plus.google.com/u/0/+PeterHDiamandis/posts/P2WucZU5Nud)