About one month ago, Dan Morrill wrote about the second Android Developer Challenge (ADC), “The second ADC will definitely not be a clone of the first ADC. We expect to have all this finalized and announce rules within a couple months. The event itself will likely run in the second half of the year.”
The first ADC was focused on creating end-user applications, particularly ones that showed off many of the features of Android, such as location-based services and Internet access. In fact, one of the judging criteria was, in effect, how many Android capabilities were used by the application.
At that time, that was probably a reasonable use of the ADC. The goal, I imagine, was to help drive quality applications to the Android Market when devices became available. While I suspect the results were not quite what everyone hoped, it still helped to raise awareness and interest in developing for Android.
Now, as planning continues on ADC II, the landscape has changed. The Market now accepts paid applications, and there are a thousand or two floating around in there. While that is a far cry from the iPhone App Store, it is nothing to sneeze at. Moreover, a contest aimed at creating end-user applications is unlikely to “move the needle”, particularly with respect to high-quality applications. Contests rewarding applications may not result in that many high-quality applications entering the Market.
Instead, I would recommend ADC II focus on two other aspects of the Android ecosystem: firmware contributions and what I will call “development accelerators”.
On the firmware side, Google and the Open Handset Alliance could come up with 10 or 20 challenge projects and fund each for $50,000 or so. These projects would add key capabilities to the platform yet should be within reach of qualified Linux and mobile OS developers. A fine example is completing support for having applications run off of removable media, which is not complete as of the Cupcake/1.5 release as far as I can tell. Here, we get a “two-fer”: contributions that will help every new Android device and ones that will help give a jump-start to public contributions to the Android open source tree. In fact, the problem may be less one of having the prize money or challenge projects, but in ensuring there is sufficient assistance to help developers contribute such code and make modifications to the firmware.
The rest of the ADC II would go not towards helping end users, but towards helping developers. Face it: if we want the Android ecosystem to be considered comparable in size and scope to that of iPhone, we need to make it easier for more developers to build more applications. Contest entrants would be judged by how much a given entry (library, development tool, etc.) accelerates application development, enables application development for a new audience, or makes broad classes of applications more useful to end users (e.g., better error reporting and logging). Here you might see a new GUI editor to replace the venerable DroidDraw, or Web app frameworks like PhoneGap. It is my humble opinion that adding significant momentum to creating development accelerators will pay off better, in terms of more and better applications, than would simply trying to directly fund the application development itself.
Bringing Android applications to market is a pipeline. ADC I was focused on the output of the pipeline — the applications themselves. By increasing the flow of open source firmware contributions and accelerating and expanding application development capabilities, ADC II could focus the challenge on making a bigger pipeline.
