Open vs Closed development

Open source is great, and we all know and appreciate that. Not only are open source projects (generally) free, they pave the way for thousands of developers around the world adding their personal talents to create a better solution.

However, several projects I've recently worked on have made me think about the benefits in more detail.

I've recently spent a lot of personal time working on a project for the Android mobile OS - more specifically my Battery Left Widget which is freely downloadable from the Android Market.

Getting up and running for Android development is very easy - you just install Eclipse and the Android tools on the platform of your choice (Windows, Mac or Linux) and you can start writing apps and running them on the emulator on your computer. If you want to install/test/debug on a real device, just plug it in and Eclipse will allow you to use the physical device instead of the emulator. All of this is free (apart from the hardware, of course). There's a wealth of community information out there, and if you want to know how Google have implement a specific feature in the core Android code, the source is freely available.

There are, however, some drawbacks to this apparent easy life:

Version Fragmentation

There are currently 4 major versions of Android out there in the wilds - 1.5, 1.6, 2.0 and 2.1. The earlier versions are not just around because users have not yet upgraded - they're around because carriers and manufacturers are still selling them with no current upgrade path.

The main reason is that due to the open source nature of Android, manufacturers have added their own bells and whistles such as HTC's Sense and Motorola's Motoblur. Upgrading a device to a later version means rewriting and retesting these additions which I'm guessing is not a trivial task.

Not only does this make it frustrating for developers, it's also annoying for users as well, especially when some of the most used apps such as Mail, Browser etc are built into the core.

Google have announced an attempted solution to this fragmentation problem - simply move many of the core apps out into standalone installable packages like they did with Maps. This means that as new versions of these apps come out, they can be easily installed by the user without any carrier/manufacturer intervention.

Whilst this will make users happier, it doesn't really help developers who still have to support the old APIs.

It also won't guarantee that manufacturers/carriers will be more considerate in the future - creating their customized addons as installable apps will make the upgrade path a lot less effort.

Hardware Differences

My widget works off system battery levels as reported by Android. Generally, Android sends messages whenever the battery level changes. Some phones report the battery levels coarsely such as the Motorola Droid that reports in 10% steps. Others are more fine grained, such as the Nexus One that reports in 1% steps. A few others seem to flutter - eg instead of going from 100 to 99 to 98 to 97 etc, they sometimes go 100, 99, 98, 99, 97. I can deal with this, but when I only have a single phone to test with, it's impossible to get it right first time.

Additionally, there are a host of screen resolutions available from the tiny QVGA (240 x 320) to the Droid's FWVGA (480 x 854). To enable the lower screen resolutions you have to add special attributes to the application's manifest file. Luckily the emulator lets you test on every available screen resolution and the drawing APIs let you use display independent positioning and sizing, but it's still a frustrating experience.

Market Application Quality

Anyone can upload anything to the Market. All you have to do is pay $25 once and you can upload as many as you like. Whilst I despise Apple's censorship of the iPhone app store, it does mean that it doesn't get flooded with utter crap like the Android Market does. Recently I've seen hundreds of so-called "cookie cutter" applications - eg a company creates an app to do one thing then creates many copies to do the same thing in different ways, such as unit converters and one-click website wrappers.

Google could very easily fix this by publishing a rules document and employing a certification process - every app is tested against their rules and gets a certification once the app passes. The Market could then be configured to only show certified applications.

Now, in comparison we can take a look at the cons of the closed model - so we'll go with the iPhone (yes this is looking like Android vs iPhone, but bear with me!)

App Store Censorship

This is a hot topic right now. Getting your app approved for the iPhone app store is not an easy task. It can take weeks, and there's never any guarantee it'll get through. Consider a sole developer who has spent hundreds of hours working on an app, just to get it kicked back by Apple for some stupid reason (admittedly there must be good reasons for apps getting denied as well, but we never hear about those!). All that time has been wasted.

Earlier this year Apple removed thousands of adult apps from small developers... however they left apps from major companies such as Playboy and Adult Swim. Unfortunately Apple can get away with this style of dictatorship because, let's face it, there's not much anyone can do about it. It's in Apple's interest to keep publishers happy (after all, they need them to push people into the iPad realm) but they really don't care about the small dev companies.

Limited Functionality

To the tech community, the iPhone has always had major functionality missing from it in some form.

For example, when the phone was first released there was no copy/paste functionality. It took several updates before they added this in. In contrast, Android phones have had copy/paste in there since day one.

Multitasking is also a hot topic. The iPhone still can't let you run more than one app at a time... again Android has had this in since birth.

With Android being open source, anyone can (and in the past have) modified the core codebase to add missing functionality.

So far I've only talked about iPhone vs Android, but these arguments above ring true in many situations, for example:

* Asterisk PBX - Asterisk is an open source telephony system that can (and does) compete with systems costing many tens of thousands of dollars. Initially developed by just two people, Asterisk has evolved via community input to become an incredibly powerful piece of open source software.

* HTML/CSS/JS vs Adobe Flash - Flash has for many years been the dominant protocol for rich media in websites. Flash is proprietary with the player software available only from Adobe which means that all browsers show Flash content in a similar way. Trying to provide a rich experience in HTML/CSS/JS across all browsers is a complete nightmare.

In summary there are drawbacks for both options - if you want to be on the risky bleeding edge of technology, go for the open option. However, if you want to play safe and fall in line with the rest, go closed!