Android is a cool example of benefits and challenges of developing with open source

As discussed in my last posting, Android is a particularly visible and broadly used project, and for that reason is drawing a fair amount of legal attention. There are aspects of the project that demonstrate the two-edged sword nature of open source: Developing with open source components provides a huge productivity gain, but companies need to be smart about it.

Android is a classic example of the way open source can support coopetition in a market. Every phone needs an operating system and developing one is an enormous investment. On top of the operating system there is plenty of room for differentiation. So, it makes good economic sense for competitors to contribute to a common core, and then compete with customization, hardware, services and brand. Just look at the variety of implementations, this common core has spawned. Many will argue that today iPhones are better, but no one can doubt that the Android approach has proved viable.

On the scale of open source projects, Android certainly resides at the large and complex end. Its comprehensiveness is what makes it such a valuable asset to device makers. At the same time, the broad scope brings with it a level of complexity that demands particular attention with regard to licensing.

The whole system actually comprises nearly 100,000 files and near 200 sub-components from hundreds of Git repositories. This list of Git repositories will give you a sense of the scope. Many of the components are "upstream" meaning they are not being developed for Android. A number of repos contain tools not intended for redistribution (and therefore may not be licensed in a way that is conducive). Each component is developed at its own rate with many changing daily. Major releases seem to be issuing forth every few months.

The project overall is licensed under Apache 2.0, though it includes the Linux kernel which is, of course, under GPLv2. But that's just the beginning of the story. The different components reference 19 different licenses in all, not all even OSI approved licenses. In addition to the kernel, there are about 30 components under reciprocal licenses.

So lots of code, distributed about, unique configurations and customizations, lots of licenses, each with a unique set of obligations...and a fast moving target. Device manufacturers are assembling all the pieces and, when they distribute the phone (or pad, or car), own the responsibility for compliance with the obligations. This requires clear strategies, policies, and solid processes to manage the complexity. The downside of a mistake is, at minimum, having to fix a lot of problems in the field, which is orders of magnitude more hassle than addressing before shipment.

This is all very doable with some planning and smarts. And the industry is responding to help companies automate their governance processes. Standardization efforts like SPDX are helping participants in a supply chain to collaborate on compliance, communicate more efficiently and avoid rework. Governance platforms like the Black Duck Suite (from my employer) automate the process. In fact, Black Duck judged the popularity and complexity of the Android to be such that the company has developed and Android-specific offering called "Fast Start," a product and service bundle optimized and services bundle optimized for Android development teams. Essentially, Black Duck has done a lot of the work that otherwise each Android development team needs to do, and has packaged it up so it can be leveraged across organizations working with Android.

Android is hot and with good reason...it's so cool! Developers of numerous device types are benefiting from the work of the community around it. There's certainly complexity to be managed with the licensing aspects of this expansive project, but with a little planning and automation, the companies distributing those devices can do so responsibly with minimum overhead.