Jammin’ In San Diego At Uplinq—WIPJam Report
Caroline and I were in San Diego last week for Qualcomm's Uplinq developer conference, where we were invited to present one of our WIPJam unpanels on Thursday. A big thanks to Qualcomm for inviting us, and to the company's CEO, Paul Jacobs, who gave us a nice plug during the keynote session that morning! Uplinq itself was great and packed with a lot of interesting people and good conversations, but more on that later. Our unpanel drew a good crowd, but more importantly, a spirited and wide-ranging discussion.
As we were in San Diego, and since Caroline was working on Canada Day, we went with a beach theme. Caroline and yours truly were decked out in some stunning Hawaiian shirts and flip-flops, and our unpanelists and a few members of the crowd got the memo and dressed along with us as well. We also need to recognize the efforts of our unpanelists, who did an excellent job of not just talking to the audience, but talking with them and keeping the conversation going. So thanks to:
- Sean Thompson, GOSUB 60
- Nick Bicanic, Purpose Wireless (Nick's got a blog post about the Jam here)
- Greg Meyer, Aepona
- Antoine RJ Wright, Mobile Ministry Magazine
From left to right: Sean Thompson, Antoine RJ Wright, Caroline Lewko, Greg Meyer, Carlo Longino, Nick Bicanic
One major point of discussion during the session was the merits and challenges of open versus closed app stores and distribution systems. One interesting aspect of this particular Unpanel was the fact that the audience was dominated by BREW developers, who tend to have a slightly different take on this than developers on other platforms we talk to. The BREW developers in the audience weren't so bothered by it being a "closed" system, insofar as the closed nature of BREW operators' app stores (in which operators select which apps are available to customers, and curate their listings in some way) makes apps that get into the stores face less competition and stand out more easily.
But, as Sean from GOSUB 60 pointed out, that's starting to change, and some operators, like Verizon, are relaxing their requirements for BREW apps and introducing more open stores to attract more developers and more apps (for more info about Verizon's latest efforts, check out this article from ConnectedPlanet by Kevin Fitchard... in which he also has some choice quotes from the Unpanel!). As the stores start to open up, developers will face similar challenges as on other platforms -- such as standing out from the competition in a crowded market, and a need to support alternative revenue models.
The need to effectively market an app intensifies as the amount of competition increases, so developers need to look beyond the app store and placement in it to drive downloads. One member of the audience, from Smarter Agent, which makes real-estate apps, said his company has partnered with real estate agents to cobrand and market its application, and heavily relies on SMS as well.
Fragmentation remains a hot topic, even within a relatively closed ecosystem like BREW, and the addition of multiple distribution systems, as well as software and hardware platforms, adds another layer to the issue. But while many developers cite the challenge of developing for multiple handsets and platforms as a major one, an interesting counterpoint was raised by audience member who highlighted the lack of fragmentation among Windows PCs, and how it's resulted in a commoditization of hardware and what some would say a less than exciting application development scene.
Greg from Aepona pointed to a couple of different areas in which operators are trying to help out: the Wholesale Applications Community, which is something of an attempt to create a BREW-like master wholesale app catalog for developers to submit to, and then the OneAPI initiative from the GSMA (which Aepona is working on) to expose network APIs from operators around the world in a uniform and easy way for developers. The WAC is an attempt to reduce the fragmentation of distribution by letting devs reach multiple stores with a single submission; OneAPI seeks to reduce fragmentation by operator by letting devs call on network resources across multiple networks with a single API.
The discussion could have carried on all morning, but we had to cut it short to stay in our time slot! Once again, thanks to Qualcomm and our unpanelists, and of course to everybody who came out and contributed to the conversation.
Were you there? What were your thoughts on the discussion, and what did you take away from it?