Is open source a good business model for robotics?
The premise of this question is that robotics companies are manufacturers and that there is choice between an open source and closed source business model. Robotics companies are best thought of as service companies (even manufacturers, especially when moving beyond early adopters) and openness is not an ‘either/or’ choice, but rather a continuum. In this day and age the question is, ‘What do you need to keep open create value for your customers?’
My company, TerrAvion, has been building a data delivery system for our robotics system on Amazon Web Services (AWS). AWS (Question for another day: is AWS a cloud services robot?) is an excellent example of how to think about handling openness. The platform is very open—the essential premise is that the customer can build any kind of web application on AWS they can imagine and code, while never having to buy or run a physical server. Almost everything that could be touched by a customer is open. There are tons of open source re-useable code and tools available freely to developers on AWS.
However, not everything is open. We collect almost a terabyte of data a day when we run our system, so we store a lot of idle data in a sub-service of AWS, called Glacier, which is one of the cheapest ways to store data in the cloud, but it has long retrieval times. Amazon publishes a lot of information about Glacier: speed, redundancy, expected loss over time, retrieval procedures — but nobody knows how Amazon really does it. A magnetic tape storage solution is the most common belief, but there is also speculation that they use retired hard drives that are generally powered off. Not to mention there are a bunch of back-end code and human procedures that remain secret.
In a sense, these tools could be open source. I’d wager that whatever tool AWS uses to run Glacier runs on Linux in an open source language. Some Glacier code may even be shared back with the community in bits and pieces. It wouldn’t be crazy to think that the open software runs with some vendor-sourced proprietary components. However, that whole side of the business is concealed from us. All we know is that AWS’s combination of technology and organization allows them to store data a price almost no one else can match.
Amazon has achieved openness Nirvana. They have a solution that functions as totally open from the customer’s perspective. Customers completely understand how to use, functionally duplicate, hack, and interface with the AWS service. However, at the same time Amazon manages to achieve secrecy and differentiation around their unique advantage, which is having the technology and processes for price leadership.
If robotics is actually a service industry, Amazon’s approach points to the correct way of thinking about the problem of openness. What openness will help your customers? What is it that your company does that is differentiated? What actually enables you to create and maintain that advantage? Robotics can be mostly open source and extract the advantages of unique and differentiated intellectual property. Try on this idea for your domain, and let me know what you think.
The IT economy has powerfully demonstrated what happens when companies can leverage open source infrastructure when they build new products and services. A company like Google would never have come into existence had they not been able to rely from the beginning on solid open source tools like Python and GCC. IBM would arguably have not been able to make its immensely successful pivot from products to services without Linux. How many startups these days begin as a cloud-hosted machine running some derivative of the venerable LAMP stack? And increasingly the underlying cloud infrastructure itself is open.
While arguing by analogy is fraught with peril, I believe that the similarities between robotics and the rest of the IT world are strong enough to justify it. In robotics, we have many shared problems to solve when developing a product or service, from low-level drivers to high-level capabilities, and all the developer libraries and tools in between. I have yet to see a successful robotics business for whom any of that stuff is the competitive advantage. Rather, success comes from the innovative composition and application of that technology in a form that somebody will pay for. The hard part is figuring out what the robot should *do*. By working together on the common underlying problems, we end up with better, more reliable solutions, and we free ourselves to spend more time at the application level, which is where we can differentiate ourselves.
In other words, I believe that open source is a great model for the robotics business as a whole. Now, is it a good model for any individual company? It certainly can be. As examples, we see small-to-medium companies, such as Clearpath Robotics, Rethink Robotics, and Yujin Robot, which use ROS directly in their products. And we see larger companies, such as Bosch and Toyota, using ROS in R&D and prototyping efforts. These are all profit-motivated companies making what is presumably a rational economic decision to rely on open source software. They’re each holding something back that is their “special sauce,” whether that’s higher level application software, configuration data, customizations to the open source code, or the designs for the hardware. And that’s expected: unless you’re in a pure consulting business (selling your time), then you need to own and control something that forms the basis of your product or service offering (to allow you to sell something other than your time).
Fortunately, open source software is entirely compatible with such business models. In fact, it was our hope to one day see such commercial users of ROS that led us to choose a permissive license (BSD, or Apache 2) for the code that we developed. We’re now witnessing, with the debut of so many new robotics companies, the fruits of those earlier labors in building a shared development platform.
To be able to choose between proprietary software packages is to be able to choose your master. Freedom means not having a master. Freedom means not using proprietary software.
– Richard Stallman, open systems advocate
Certainly robotics has its share of proprietary software and control systems. Each robot manufacturer markets their products based on the need for secure, proprietary and un-shared systems so that they can ensure stability and control. Whole industries have been set up to bridge those proprietary barriers so that multi-vendor solutions can happen.
Two prominent people in the robotics industry had a discussion on the subject last year. In a spirited cocktail party debate in Lyon, France at InnoRobo 2012, an innovation forum and trade show for service robotics, Colin Angle and Robert Bauer argued their points of view.
Angle suggested that freely providing such a key and critical component as the robotic operating and simulation system – and the extensive libraries that go with it – as the Open Source Robotics Foundation (previously Willow Garage) does with their open source and unprotected robotic operating system (ROS) – was tantamount to letting the biggest consumer giant(s) gobble up any mass market applications and re-market them globally at low cost because they already have (or could easily reverse-engineer) the hardware and could produce it cheaply, the operating system was free courtesy of ROS, and the only real cost was the acquisition of the application(s).
Angle thought that it was dangerous and led to losing a potentially American/European market to offshore commodity conglomerates, and said:
Robotics innovation represents a tremendous opportunity for economic growth akin to automobiles, aerospace and information technology. If we are to freely share our ‘intellectual capital’ on the open market we risk losing the economic engine that will advance our economies and send growth and jobs overseas.
The issue of losing trade secrets to foreign conglomerates has been a continuing focus at Bloomberg Businessweek magazine:
In November, 14 U.S. intelligence agencies issued a report describing a far-reaching industrial espionage campaign by Chinese spy agencies. This campaign has been in the works for years and targets a swath of industries: biotechnology, telecommunications, and nanotechnology, as well as clean energy. “It’s the greatest transfer of wealth in history,” said General Keith Alexander, director of the National Security Agency.
Bauer said that Willow Garage’s objectives with ROS was to stimulate the industry by enabling participants to not have to reinvent the many cross-science elements of robotics ventures; to reuse software because it saves developer time and allows researchers to focus on research. By giving them free access to the tools, libraries and simulation capabilities of ROS, and access to the PR2s that are available for testing and experimentation, Willow Garage hoped to advance the state-of-the-art in autonomous robotics technologies.
Bauer also said that, once a successful app was developed, at that point the new endeavor would likely lock down the operating system and application software in order to protect their invention.
Angle suggested that what the robotic industry needs for inspiration is successful robotics companies – profitable companies with millionaire employees selling in-demand products; not more notches on the oversized belts of big offshore conglomerates. Further, he said that unless ROS is protected and made stable and secure, it could never be used for sensitive (defense, space, security) solutions, and until it became rugged, secure and stable, it could never be used in factories, which cannot afford down time from either their robots or software.
Since that time, solutions that bridge the open vs. shut debate are showing up in many sectors:
- Willow Garage has transitioned ROS to two different non-profit foundations to continue development of ROS and ROS-Industrial: The Open Source Robotics Foundation and the ROSIndustrial.org.
- ROS-Industrial is a new effort to enable closed industrial systems to at least have a “front end” to make available the introduction of new sensors, make robot programing and simulation easier, and take advantage of the wealth of new talent exposed to ROS in academia.
- Start-up companies selling co-robots are using ROS and beginning to share application software. Danish Universal Robots and Rod Brooks’ Rethink Robotics both use ROS for software development but not for control systems. Rethink Robotics plans to offer an SDK capability with an app store for robotics applications shared by other Baxter users sometime in 2014. The SDK is already available in the academic version of Baxter.
- Industrial robot makers are beginning to provide ROS-like capabilities in the form of updated software and simulation suites, e.g., ABB Robotics recently introduced RobotStudio which is a GIS interface to ABB’s proprietary internals for robot simulation and programming.
Thus as the debate rages on, so too do the very pragmatic solutions that are necessary to make things move forward and work.
The best solutions often involve multiple vendors. Look at the Tesla factory. Integrating their software and control systems into the larger manufacturing system, or even between different systems on a line, involves serious and talented programming — a process that everyone agrees needs to be simplified and made less costly.
ROS-like products are fine for development and simulation, and because they are prevalent in most of academia, new hires are familiar with what it does and how it works. But that’s when those new hires are confronted with the complexities of proprietary software and teaching pendants. I’ve heard it said that it’s like going back to the mainframe era of computing. At the least, it involves learning old-style coding languages.
Most of the big robot manufacturers are beginning to make an effort to improve their training and programming methods, to get them onto more practical tablets, and to provide offline simulation. But the going is slow, hence the argument for open source rages on. The truth appears to be in the middle: older systems need to be updated and yet still retain their proprietary nature. Mix and match between vendors is a fact of life and needs to be accommodated either by the use of ROS-Industrial or by the robot manufacturers themselves in the form of a new set of standards and interfaces.