Why OSS and Hardware Release Cycles Impede Contributions
The Symbian Foundation keeps kicking off developer-focused initiatives. One of the more recent is the Symbian Bug Squad, an attempt to convince developers to help test and fix bugs in the Symbian platform via structured events. For example, just yesterday, they held a “test day” focused on the Homescreen app.
The comments to the blog post about the Bug Squad highlighted some problems that Symbian has that will also affect Android and Meego, to varying extents. Specifically, while open source is designed to allow developers to “scratch their own itch”, the nature of mobile devices make that much more difficult, at least for production.
Courtesy of a couple of decades of fairly open systems, open source developers are used to being able to truly “scratch their own itch”. If there is something about an app you don’t like, download the code, make the change, use the changed version yourself, and contribute the change upstream in hopes it is accepted and mainstreamed for future public releases. While there are frequently rocks that cause problems with upstream contributions, the overall approach works fairly well.
It does, however, assume that the developer can use their own changed version. It also somewhat assumes that the contribution has a good chance of being visible to others in a reasonable period of time, on the order of a few months. For example, a contribution to Ubuntu today, as Lucid Lynx is near completion, might still be visible in the form of an alpha of Ubuntu 10.10 that comes out this summer.
However, production hardware makes that timeframe unlikely.
Take Symbian, for example. They do a fine job of detailing their intended release schedule. Development of S^3 — the current iteration of Symbian — is wrapping up now (hence, the Bug Squad), and S^3 handsets will be available in the second half of 2010. S^4 work will then begin, wrapping up in ~6 months, for handsets that will appear in the first half of 2011. Given your typical operating system code freeze and testing late in a development cycle, it could easily be 6-9 months before a contribution reaches the public, and possibly longer than that.
The issue is hardware. Without an iPhone-style “every device gets every update” model, and with only a few devices supporting replacement firmware, everyone is held hostage waiting for new hardware to ship with the new operating system. Hardware manufacturers have to deal with incredible volumes of devices and have low tolerance for problems. Hence, they need 3-6 months to be able to take on an operating system update and get it onto new hardware.
This time gap between a contribution and having that contribution be visible to the world will be a problem, at least for some developers – it makes the open source mobile OS more “scratch-resistant”, in that an itch cannot be scratched as easily as with a desktop OS or other forms of open source.
Now, having devices that support replacement firmware helps, as developers can run their own version with their own fixes. Hence, Meego may be less prone to “scratch resistance” than are Symbian and Android. This is one of the reasons why having more devices allowing replacement firmware can be of benefit. And perhaps we can come up with other innovations that help in this area, or simply reset expectation. Until then, though, fewer developers will contribute, simply because the feedback loop between their labor and the fruits of that labor is too great.
Meanwhile, though, I will watch with interest to see how Symbian’s developer outreach programs and projects, like Symbian-related events on Towel Day and the Wild Ducks hardware project and Software Freedom Fighters pan out.
