April 2011


A recently released survey of 2,760 mobile application developers reveals challenges for Google, Microsoft and RIM around fragmentation and access to developer time and mindshare.

The survey was conducted in early April 2011 by research firm IDC, and Appcelerator, a mobile development platform provider for building cross-mobile platform applications using HTML, CSS, JavaScript, PHP, Python and Ruby. Appcelerator claims 1.5 million developers and over 20,000 applications built with its open source products.

Not surprisingly, Apple and Android phones and tablets occupy the top four spots in terms of developer interest in developing for a certain platform. There’s over a 40 percent gap between the two leaders and everyone else, including RIM, Microsoft and HP’s respective mobile platforms.

Android’s challenges with fragmentation
The survey gets interesting when developers discuss their concerns with Android. Fragmentation is overwhelming the number one concern.

A feature/function comparison versus Apple’s iOS or ability to make more money from Apple’s ecosystem are at the bottom of the Android concerns list.

IDC and Appcelerator also point out that there appears to be significant gap between interest in Android as a tablet OS and tablets that support Android.

On the software side, 71% respondents are “very interested” in the Android OS, but on the hardware side, only 52% are very interested in developing applications for the Samsung Galaxy tab. This drops to 44% for Motorola Xoom, the first Android tablet with Android’s Honeycomb OS.

This is somewhat surprising considering the relatively strong hardware specifications, especially compared to the likes of Apple’s iPad 2, that Android tablets offer. However, fragmentation concerns may be a root cause to the lack of interest in having to test with and support the various Android tablet offerings.

One can see why Google is working hard to reduce fragmentation, even if it allows outsiders call Google’s open source credentials into question.

RIM and Microsoft’s race for relevance
When asked if any other platform can catch up to Apple or Google, 62 percent of respondents said “no”.

Digging deeper, the respondents are more interested in the Microsoft & Nokia partnership versus announcements from RIM or HP surrounding their respective mobile platforms. Respondents felt that the Microsoft and Nokia partnership could position Microsoft as a more serious competitor to Apple and Google.

However, even amongst this group, when asked what poses the biggest risk to the success of Microsoft’s mobile platform, 46 percent answered, “not enough time”. The only higher ranking risk was a perception that Google and Apple are just too far ahead.

What’s troubling is that Appcelerator helps developers build native, cross-device mobile applications from a single code base for iOS, Android, and Blackberry.

These developers can’t find the time to target anything other than iOS and Android, even with a tool that addresses multi-platform support from a single code base.

These developers are saying that the marginal cost of tailoring the single code base application for RIM or Microsoft platforms is outweighed by the value of delivering the next feature for iOS and Android users of their application.

I would have expected these responses from developers tasked with building for multiple mobile platforms without the benefit of a cross-device framework or tool like Appcenerator offers.

RIM, Microsoft and others hoping to catch Apple and Google, need to dig deeper into these results and determine what can be done to keep developers interested in building for their mobile platforms.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

While RIM’s PlayBook is late to market, and is receiving a range of positive to negative reviews, RIM has the benefit of a large and loyal user base. Don’t underestimate PlayBook interest in you enterprise just yet.

Apple extends iPads beyond iPhone users
A recent comScore report suggests that over 72.7 percent of iPad owners, don’t own an iPhone. As comScore claims, “Apple iPad ownership extends beyond just fanboys”. This, of course, is a great opportunity for Apple to grow its customer base in the smartphone, and potentially even laptop or personal computer arena.

At the other end of the spectrum, RIM’s PlayBook is decidedly focused on existing RIM customers, at least initially. To say these customers are, by in large, loyal to RIM would be a huge understatement.

According to comScore’s data, 17.5 percent of iPad users have a RIM smartphone. These are customers, like me, that RIM is more likely to lose when they decide to purchase a new smartphone. As I’ve said before, the only thing that keeps me a BlackBerry customer is BlackBerry Messenger (BBM). I’m not updating my smartphone for fear that I’ll upgrade to a new BlackBerry only to have RIM announce that BBM is now available on an iPhone or Android device.

Excluding turncoats like myself, one can extrapolate from the comScore data that upwards of 80 percent of RIM smartphone customers have yet to make a tablet purchase decision, and could be swayed by the PlayBook or a future version of the device. Yes, some within this 80 percent have the option of selecting an Android tablet. But, there’s little in an Android tablet that would convince a RIM smartphone user to choose an Android tablet over an iPad. Said differently, if a RIM smartphone user is going to select a non-RIM tablet, chances are they’ll select an iPad.

RIM selling into the loyal 80 percent
So, for argument sake, let’s talk about this 80 percent of existing RIM smartphone customers and their future plans for a tablet.

A friend of mine won a PlayBook through RIM’s launch party contest in Toronto, Canada. She was able to bring three friends to the party, and I was one of them. Of the approximately 200 to 250 attendees at the event, I counted two non RIM smartphones over the course of the 3 hours we were at the event. Everyone else had a BlackBerry, and was feverishly BBMing, on Facebook or updating their twitter status throughout the night.

After using several PlayBook devices throughout the night, in case one was a lemon, and comparing with my iPad 2, I would say that the PlayBook software needs a little more time. This is not to suggest that the OS or browser is poor quality. However, both are lacking the fit and finish that a few more weeks of development would have afforded.

I am purposely not describing the issues I found. Why? Well, this is not a review of the PlayBook, and I’d expect them to be resolved in the next few software updates.

What’s more important is that my friends at the event, others using the device at the event, and even BlackBerry toting friends and colleagues who had yet to touch the PlayBook appear willing to look past the issues. Luckily enough for RIM, these prospective buyers aren’t drawn to the iPad 2 either.

Trust me; I’ve tried to preach the virtues of the iPad to my RIM loving friends and colleagues, to little avail.

The reality distortion field that RIM co-CEO, Jim Balsillie, once described around Apple and Apple products may in fact be occurring around RIM and the PlayBook.

At the Toronto PlayBook launch event, one user was wowed by the HD video capture and playback, which frankly put the iPad 2 to utter shame. Another couldn’t get over how fast the browser was. Another colleague used the recent revelation of iOS tracking a user’s location as, “just another reason I’m more likely to buy a PlayBook than an iPad”. Finally, to my surprise, many existing RIM smartphone users I’ve spoken to prefer the smaller size of the PlayBook.

For all the reviews about the PlayBook, existing BlackBerry smartphone users are still quite impressed with the device.

Whether they’ll purchase version 1.0 or wait for a future release is an open question. And yes, it’s unlikely that the PlayBook will draw in new customers to the RIM franchise, at least initially. However, keep in mind that RIM enjoys well over 60 million smartphone subscribers.

Don’t count the PlayBook out, just yet
Talking with several RIM staff, from their development team and developer outreach program, I left the event much more confident in RIM’s future than when I arrived at the event. They are also doing more with open source, which I’ll cover in a follow up post or interview.

While nobody said it in so many words, there’s a real sense of pride and scrappiness in what they’ve delivered and what’s coming, whether in the form of software updates or PlayBook v2.

The vast majority of RIM’s 60 million plus subscribers are eagerly waiting as well. Some will surely purchase the PlayBook v1 and want to bring it into the enterprise, especially if travelling.

Enterprises may be reluctant to adopt PlayBook v1. However, the great hardware specs mean that the PlayBook v1, with updated software, will be a great tablet for some time to come.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Devops, a term coined to describe the expanding reach of developers into areas typically considered operations tasks, is still viewed as a trend impacting early adopter enterprises – but for how long? What can you do to prepare what should you look for in technology that enables the devops model?

The developer land grab that is devops
The desire to release new functionality faster to end users is high on every developer’s wish list. However, most enterprises have multiple layers of processes, assigned to separate roles, which often increase the time between a new feature being developed and made available to users. However, most IT managers would agree that these processes and separation of roles were instituted to increase the quality and uptime of IT environments, and ultimately the quality of the end user experience.

The growing access to automated, self service, provisioning of IT resources and environments is enabling developers to flatten the roles, if not processes, between a developer and the end user.

RedMonk’s Michael Cote suggests that devops can be viewed as a land grab by developers. Cote writes, “after ejecting every function except writing code, development teams have been bringing those roles back to the core team, starting with QA, then product management, and now operations.”

Not surprisingly, devops is taking hold primarily in startups or smaller companies where the separation of developer versus operations roles is ill-defined by necessity.

The changing role of operations in a devops world
In larger enterprises with established separation of roles between developers and operations teams, the devops term may in fact be counter productive. It can suggest that as developers undertake tasks previously owned by the operations team, operations staff become less critical to the IT organization.

In fact, the reality underlying devops is far from that mistaken belief. Cote describes the changing role of operations staff in a cloud-driven devops world:

Rather, it means that as with QA and product management, their role moves from “keeping the lights green” to “delivering good, productive experiences.” Operations becomes one of the product owners, not just the “monkeys” who hook up wires to servers and increase disk-space.

The451 Group’s Jay Lyman shares a similar view in his research on devops, concluding:

However, in the larger picture and in the long run, particularly at greater scale, there is undoubtedly need for system administrators. One of the bottom line findings of my research on devops is that the trend is very much about a dramatically changed purpose and role for system administrators, who are typically freed up of mundane OS maintenance and other tasks, but who must also embrace openness and transparency in their operations and scripts, which can be very foreign.

Far from developers replacing operations staff, and thereby accepting some of the manual tasks required to keep an environment up and running, new cloud technology removes the need for these manual, and at times mundane, tasks in the first place. As these tasks are removed, operations teams are able to better contribute to the value that their business and end users perceive to be coming from IT.

Transitioning towards a devops model
Much of the transition required by the devops model involves changes to organizational design, processes and a revised definition of roles. These types of transitions can be lengthy in duration and often face resistance initially.

It is for exactly this reason that vendors must offer both an evolutionary and revolutionary option in their cloud and PaaS offerings targeted at enterprises.

An evolutionary approach is required to help IT organizations gain value while they transition to tomorrow’s more responsive and productive IT organization. Without this evolutionary step, the desire to protect one’s sphere of influence in the overall IT process will encourage IT staff to resist change before they can see the benefit of a cloud-enabled devops model.

A revolutionary approach also needs to be delivered in the same cloud-focused tool or product. This choice enables enterprises to shift gears between evolution and revolution in their IT processes without having to acquire separate products with separate skills requirements. More importantly, this choice allows enterprises to shift between evolution and revolution in their IT processes at their own rate and pace.

VMware’s open source-based Cloud Foundry beta and IBM’s Workload Deployer are two PaaS offering that attack the devops opportunity from two ends of the spectrum.

VMware’s beta offering appears targeted at enterprises ready for revolution, with a developer in control of the overall development to deployment process. It’s too early to tell if this is by design, or simply didn’t make it into the developer targeted marketing surrounding the beta. Knowing VMware’s long history with enterprises, one would expect VMware to address the spectrum of stakeholders whose roles are impacted by cloud and PaaS in a devops model.

IBM’s offering assumes that enterprises want to select between both evolution and revolution in their IT processes on a project by project basis while. This choice enables IT organizations to secure buy in from IT employees after proving out the benefits of more closely aligned developer and operations functions in a given project.

Preparing for a devops future
Like any major change in processes or role definition, IT decision makers need to allocate sufficient time for the shift to occur.

Successful transitions will most likely occur if there are proof points, relevant not only to the business, but to developers and operations staff, from a handful of smaller projects. Selecting projects, developers and operations staff that would be best suited for a new way of doing things would be a good fist step.

Additionally, determine the degree to which your IT organization can accept the revolutionary changes to roles and processes as codified by the cloud and PaaS tools you consider. Select your cloud and PaaS tools based on your organization’s unique needs.

Whatever you do, starting to think about devops models sooner rather than later, is the right approach for building tomorrow’s IT department.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

A high profile VC and a well-known mobile application developer were recently involved in a debate about whether to build for Android or Apple mobile platforms. The answer it turns out is, it depends, or both, or simply build for the mobile browser.

App developers and companies have different goals, so why follow the same advice
Well respected VC, Fred Wilson, principal of Union Square Ventures, has previously suggested that developers interested in the largest user base should invest as much, if not more, in developing for Android as they do for iOS. Wilson justifies his recommendation by looking back at the desktop operating system market. Wilson writes, “I believe the mobile OS market will play out very similarly to Windows and Macintosh, with Android in the role of Windows.”

Countering Wilson’s advice is Marco Arment, founder of Instapaper and former lead developer of Tumblr. Marco suggests developers need to keep a closer eye on development economics, degree of fragmentation, payment integration, and the willingness of users to pay for applications or extensions on a given mobile OS platform.

Marco’s advice is likely to resonate with individual developers hoping to directly monetize their mobile application either through selling the application or through in-application purchases. Over time however, one shouldn’t bet against Android closing the gap versus Apple along the lines of development economics, payment ease of use and fragmentation.

It remains to be seen whether Apple’s platform can continue to generate higher application and in-application purchase revenue for developers even while Android boasts the #1 mobile OS by unit share. Today, the App Store revenue gap between Apple and all other mobile platforms is striking.

On the other hand, a company that sells goods or services which are exposed through the mobile application, but does not monetize the application itself, needs to pay more attention to Wilson’s advice. If the vast majority of a bank or retailer’s prospective users are going to use an Android device, the company had better offer a compelling user experience on that platform.

But why choose between developing for Android or Apple?

Build mobile web browser applications
It’s somewhat amazing to watch companies that don’t rely on directly monetizing their mobile application invest in native mobile applications for iOS or Android. In a rush to be the first to market, companies optimized for a device rather than following the cross-platform and cross-browser web application strategy they’ve used for the better part of a decade.

Not surprisingly, this will change thanks to HTML 5, CSS 3 and JavaScript.

For instance, if TweetDeck, which is best known for its thick-desktop client, can see the light and deliver the same user experience in a web-browser across desktop and mobile devices, chances are your company’s web application can evolve into a mobile web browser application without paying the cost of device-specific implementations.

The key element of TweetDeck’s announcement is that “TweetDeck Web, however, is a standalone web site and requires no downloads, no App Stores and is not limited to any one brand of web browser.”

No App Stores is a win for the browser
The “no App Stores” angle obviously has its pros and cons. However, unlike individual developers, companies that aren’t monetizing the mobile app itself don’t need to rely on an App Store to attract users. They already have users and other processes to attract new users. Their users simply want to interact with these companies through mobile devices. Putting the company’s web application into an App Store adds extra hurdles for users and for the company when it comes to fixing defects or updating the application with new features.

If users begin to rely more on App Stores and less on the Internet itself for finding new vendors of goods or services, being in the App Store of choice will become as important as being listed in Google’s web index. But we’re years away from this scenario becoming reality, if ever. In the short to medium term, established companies can well address new and existing customers through a mobile web browser application.

It’s strange that Google hasn’t recognized the mobile browser-based application opportunity and is instead attempting to replicate Apple’s App Store strategy. The browser undermines the value of the underlying OS.  And since Google doesn’t much care to profit from the underlying OS or the device, unlike Apple, they should be encouraging companies to build mobile web applications, not device-native applications. Google should be indexing and promoting these mobile web browser-based applications.

Consider cross-device frameworks as a step towards standard browser applications
For individual developers and companies that need to be an App Store, or want to access more of the device native capabilities, such as the camera or GPS, then evaluate the various cross-device frameworks previously covered on Open Sources. For instance, PhoneGap already has an impressive list of cross-device native feature support. Using a framework such as PhoneGap, and their build service could make it easier, faster and cheaper to build applications for Android and iOS, instead of having to decide which platform to prioritize.

Over time, standards will emerge to access core mobile device capabilities, such as the camera or contact list, in a cross-device fashion. Whether this occurs through defacto standards around a framework such as PhoneGap, or a formal standards body efforts is unclear. Maybe Google will smarten up and realize they have more to gain by spearheading this initiative than trying to play Apple’s App Store game.

If the past decade has taught us anything, it’s that the browser is the application runtime that matters most. Build for the browser.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Google’s recent announcement that Android Honeycomb will remain closed to outside developers, while partners have access to the code isn’t sitting well with open source proponents. However, the stark reality is that Android’s growing mobile maretshare has little to do with how open the operating system truly is.

Android a bait and switch to open source developers?
In a BusinessWeek interview, Google’s Andy Rubin, vice president of Android engineering, explained that Google had to make some design tradeoffs to ship a tablet-optimized version of Android, dubbed Honeycomb. Rubin explains, “we didn’t want to think about what it would take for the same software to run on phones.” To prevent developers from trying to run Honeycomb on phones, a scenario that Google didn’t plan or test for, Google has decided to keep the source code for Honeycomb private “for the foreseeable future”.

While Android is often referred to as an open source mobile platform, the development approach is far from open. Google develops Android behind closed doors and makes the source code available when, and as it now appears, if, Google feels is appropriate.

Not surprisingly, some open source developers are taking an exception to the Honeycomb news. Linux developer Adam Drew writes:

In hindsight Android was a bit of a bait and switch with a dash of divide and conquer. Most of the open-source folks are fine with Android being closed up so long as it is opened up later and that means that we lose a large portion of the potential community to Android. This has translated to lower participation in projects like MeeGo and little demand on manufacturers to provide devices that we can easily install other operating systems on. If Android were fully closed we’d have a large base of support waiting to come over to freer pastures but with Android existing in this quasi-open state enough of the open source crowd will stick with it to make it hard for critical mass to grow behind projects like MeeGo.

Openness is often trumped by other stakeholder concerns
RedMonk’s Stephen O’Grady tackles the question of whether it matters if Android is open or not. O’Grady writes:

But while developers are unquestionably and understandably disappointed, there is little evidence to suggest that a less than open Android will have a material cost in developer traction associated with it. Apple’s iOS, a platform that is not open source, has immense developer traction with over three hundred and fifty thousand applications available at the moment.

Based on market share of mobile devices shipped or number of applications for a particular mobile platform, it’s abundantly clear that mobile operating system success has little to do with openness.

In fact, O’Grady concludes that while Google may have felt that openness would turn out to be a differentiator in the market, that hypothesis simply hasn’t been proven out.

If openness isn’t driving Android’s growth, then what is?

Benchmark Capital general partner Bill Gurley’s great post titled “The Freight Train That Is Android” provides some clues.

Gurley argues that Google is attempting to “take any layer that lives between themselves and the consumer and make it free (or even less than free).” This is incredibly important to handset vendors and carriers who have an incentive to use and promote Android over alternatives. The fact that Google shares mobile search revenue with its handset partners makes Android not just free, but a profit center, which is hard for a vendor to ignore regardless of the openness of the platform itself.

As mobile handset alliance members, these vendors have access to Android source code well ahead of third party developers. As such, the openness of Android is a distant secondary issue, if at all. These vendors are however concerned with developers building applications for the platform and end user adoption.

Application developers may care about Android’s openness. However, a large user base and the ease with which the platform enables developers to deliver applications that end users will value, and pay for directly or indirectly, are much larger concerns. The market reach of Android through the ever growing number of vendors supporting Android and Google’s investments to close the feature/function gap to Apple iOS can’t be ignored. These two facts render the question of Android’s openness into the background for the vast majority of developers.

Finally, end users, who should arguably care the most about the openness of their mobile devices, continue to vote with their wallets and select products that optimize user experience over openness. This is an interesting observation considering that their traditional PC environments allows for a highly customizable environment with the flexibility to mix and match hardware with operating systems. One would have expected mobile buyers to seek this same level of hardware and software flexibility in their “post PC” device purchases.

Continue preparing for increased Android usage in your enterprise
Handset vendors, carriers, application developers and end users continue to select other priorities over openness when making a mobile device decision. These stakeholder actions have surely made it easier for Google to minimize its focus on openness with an eye on delivering the functional and non-functional requirements of key stakeholders.

Whether openness ever truly mattered to the potential success of Android is anyone’s guess. The question becomes increasingly irrelevant with each day and each market share percentage that Android captures. As an IT decision maker, your best bet is to continue to prepare for an influx of Android-based devices, personal and company-purchased, in your network; sooner than you may have hoped.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”