A quick plug for one of my work based projects I'm most proud of. Like any good marketer I spend a lot of time understanding the market and what my prospective customers want and need. Historically this investment in insight was proprietary and used solely internally. I had a "light bulb" moment about two and a half years ago and thought why don't we effectively open source our market research and share the same data we use internally with anyone that wants it. Next step was to find the right partner, and I have had a blast working with Andreas Constantinou and the team at Vision Mobile ever since. The 2010 edition of the report received wide spread praise and achieved over 10,000 downloads. I'm confident that 2011's edition is bigger, and better. We have doubled the number of respondents, and for the first time we have interviewed over 20 leading brands to understand their attitudes and apps strategies. You can listen to Andreas and I discussing the report here: Introducing Developer Economics 2011 from BlueVia on Vimeo. To download your free copy visit www.developereconomics.com Enjoy! edit: thanks to @adamcohenrose for pointing out the download link was broken! Now fixed

On Friday I swung by The Business of API's Conference at The Guardian's offices near King Cross station in London. Unfortunately some fires were burning back at the office which mean't that I couldn't stay for the entire event, however I caught the first three speakers and Q&A so here are my notes / thoughts from the first half of the afternoon... First up was Oren Michels, CEO of the event organisers Mashery. Oren took the crowd of about 40 through a whistle stop tour of "A complete history of API's (abridged)". Oren initially spent some time exploring the conceptual business concepts behind API's like opening up your company, and embracing collaborative working with partners. The first case study was a delve back into business history, looking at US retailer Sears, and how they embraced an expansion opportunity by partnering with logistic's companies & manufacturers to launch their mail order catalogue business. Moving into the pure play online world, eBay was singled out as an early pioneer in the field. Very early on the management team realised they were great at handling transactions, had developed a trust system based on ratings and feedback, but they were lousy at starting and running the auctions. They began to increasingly expose their internal building blocks to allow 3rd parties to offer a variety of complementary products to assist with the creation and management of eBay auctions. This ecosystem grew organically, until eBay's officially began developer marketing in 2004. The next important  innovation, after the exposure of previously hidden internal capabilities, was taking one of these capabilities and mixing it together with a capability from another company to create a new service, giving birth to the "mash-up". An early example of an API mash-up was 2005's housingmaps.com. The creator, Paul Rademacher, took real estate data from craigslist and combined it with Google Maps to plot properties for sale on a map. Rademacher achieved this before Google had actually exposed an official mapping API by reverse engineering their code, ultimately earning him a job at Google! Oren than described the common components or layers of an application:

1. Data (e.g. photo's, video, user information)
2. Logic (The things that happen & how the data is processed e.g. searching, buying, adding)
3. Presentation (The user interface e.g. the web site or mobile app)

By adding an API layer your company can expose the data layer to encourage 3rd party innovation and mash-up's. Oren made the point that a great app doesn't have to do everything. It should be simple and focused, "granting wishes". A great example of this keep it simple mantra is The Guardian's Eye Witness app, where The Guardian can "re-use" existing photo content to create a compelling new service offer. Oren closed by touching on the cookery analogy of API's. Historically companies have wanted to create new products behind locked doors. Now companies should think about API's as ingredients. No longer do companies have to control the end to end creation process (the ingredients, recipe, creation, and the baking). Just put your ingredients out there and see what other people can create with them. I've used this analogy a numbers of times inside my company. Once you can get your head around the concept, it is immemesily liberating for anyone that has been in charge of product development inside a large organisation. The internal pressures of resource & capex scarcity, risk aversion, process complexity, time to market, and the weight of creative expectation suddenly disappear. Like the example of the individual app, the focus for modern Corporate product development should be to analyse the core capabilities of your company and expose them in a secure and scalable way. If you can wrap those capabilities in an attractive business model, then you can tap into the hundreds of thousands of developers out there who will invent imagative ways to utilise and monitise those capabilities for you. A recent blog post by Alan Quayle notes that Google and Facebook now have 5 billion API calls a day. Twitter has 3 billion calls a day, which amounts to 75% of its traffic. The second speaker was Sam Lowe from Capgemini. Sam spoke about the use of API's in their Enterprise customers, naming it "3rd generation eBusiness" Sam set the context for enterprises - they are "under siege". They are having to figure out how they adapt to changing customer behaviour (e.g. Facebook), disruptive innovation (internet models rather than enterprise IT models), and new business opportunities (pure play online). The Enterprise generations of eBusiness were defined by Sam as: 1.0 - Initially getting online to match early pure play etailers like Amazon & eBay. 2.0 - Developing the online channel for transactions, customer self care, plus seamless multi channel experiences like online order & reserve with physical in store order collection 3.0 - Opening up and becoming inter-dependant on other organisations. Taking your services to where customers already are. In this 3.0 phase web sites can now automatically interact with each other to create new service bundles or offers in real time. Sam cited Dell's Idea Storm as an example of an Enterprise opening up both technically and philosophically to improve it's products and services, along side Apple's Developer Community, and O2 Uk's GiffGaff virtual mobile network brand where the GiffGaff community is incentivised via service credits to provide customer support to each other. API's represent a more cost effective and flexible solution vs. traditional IT integration, and can be used as a foundation to create ecosystems or platforms to generate new business opportunities that didn't previously exist in the old world closed model. These platforms allow other (external) people to create services that the Enterprise would have either never thought of, or backed. The API model seems to be well established; Programmable Web's API directory now lists nearly 2,200 individual API's, including API's from companies you may not expect to be playing in this space like Tesco. Expanding your companies relationships and connections via API's and mash-up's creates new business opportunity, as per Metcalfe's Law. [caption id="" align="alignleft" width="200" caption="Metcalf's Law - Network Effect. Image from Wikipedia.org"] [/caption] Sam touched on the challenges facing Enterprises looking to invest in creating API's, including how to pay, security, operational support, and dependencies on others. It would have been nice to get some deeper insight into the business case challenges. By definition, because your organisation is dependant on the creativity of others to develop new services by using your API, it is almost impossible to predict the return on investment for an API. It can become a science vs. religion debate. To help the business case debate the "eating your own dog food" or the more polite "drinking your own champagne" argument can be made. As well as exposing these API's for external developers, many companies also use the same API's to power their own internal services. This delivers a much more efficient and flexible reuse approach vs. traditional stove piped Enterprise IT delivery projects. During the Q&A session the GiffGaff case study was mentioned again, leading to a discussion on how "power users" are willing to offer their personal time to create and maintain online communities based around the products and brands they love. The conference moderator, Quentin Hardy, National Editor, Forbes threw in an interesting stat; In the USA 40,000 people spend 4 hours a week posting on company forums. The final speaker I caught was Emer Coleman from the Greater London Authority. Emer acts as an advocate for the London Datastore which is focused on opening up various public sector data in the London area via API's. Examples of the data in action are the live tube train map on TFL and a feed for the new London cycle hire service is next on the list. Other examples were Oyster card outlets, council tax bands, and they are looking into crime maps but of course that kind of data presents a number of privacy and social issues. Emer gave some interesting insights into the speed of development using their API's, with apps now being created in "an afternoon" vs. the traditional public sector procurement process which is measured in months & years. I'm sure many of us in the private sector can relate to that as well! Also interesting was the challenge around working with more sensitive data, like crime statistics. Perhaps an unforeseen benefit of opening up access to the data via API's, was that teenagers who would never visit an official government website, are now exposed and interacting with the same government data via brands they are willing to associate with. With heavy public sector spending cuts looming, I asked the question if this would lead to a national roll out, but there didn't seem to be a strategic plan. Surely allowing 3rd party developers to create compelling public services from this data would allow the government to innovate and improve services for citizens at the fraction of the cost....? Anyone interested in learning more about API's has to watch this video:

Darwin's Finches, 20th Century Business, and APIs: Evolve your Business Model from Apigee on Vimeo.

Following hot on the heels of the new blog launch last week, I'm delighted to announce that another project we have been beavering away on since last year goes live today; Developer Economics 2010 investigates the  migration of developer mindshare that is taking place in mobile software today and the drivers behind it. The project was really challenging to pull together with our friends at Vision Mobile, so we hope you agree with our view that this is a ground breaking piece of developer research that plugs a real gap in the market. Let us know what you think. If you want to discuss on Twitter or help us promote the report (pretty please!) then use hash tag #devecon Enjoy!

First published on o2litmus.co.uk Over the coming months we’re talking to different stakeholders in Litmus to pick their brains and listen. First up is Noel (aka Kontraband on the litmus forum). Noel’s an app fanatic and early adopter who’s been working in technology for over 10 years.  Alongside the day-job he’s been a major contributor to allaboutsymbian.com, the world’s biggest portal for Symbian smartphones. Interview by Adam, the O2 Litmus Community Manager. Here's what he's got to say: A: In a nutshell, why do you like apps? N: Well, handsets are such a part of people’s lives these days, and apps give them the ability to mould them to do what they need them to. In fact, certain handsets have almost become a platform for self-expression, rather than just functional devices. A: And why do you get involved? N: Several reasons, really. Firstly it means I know what’s new and with Litmus I can actually get apps before anyone else. Secondly I enjoy giving my feedback and helping developers evolve their app successfully. After all, there’s nothing like a fresh pair of eyes to spot something you’ve missed because you’ve been looking at it for weeks on end! A: Interesting point, so why else do you think that collaboration between developer and user is useful? N: Working in-between clients and developers I know the worth of collaboration. Developers understandably develop in the way they see as the best method of going forward. However, that's not necessarily the way the end user would want it to go though. Without collaboration there's no way of sharing that information. Equally, a user may want the application to do x, y and z, but when a developer looks at it, they can see that there is no true requirement for x, y and z in the development of the app. Collaboratively, any issues with the applications should come out if there is a shared thought process, which is better obtained with more brains. A: True, but that only works if a developer gets that sort of quality feedback, right? N: Yes, absolutely. I imagine there’s nothing more frustrating for a developer than to put their app out for testing only to receive feedback such as “it’s ok” or “this app sucks”. So I think one of the challenges for Litmus is to make the quality of people’s feedback more visible. A: Agreed, we have some ideas in the pipeline that’ll help with this. Do you think better profiling of testers would help with this? N: That’s part of it, yeah. Quality feedback from one tester who’s representative of the app’s target audience is infinitely more valuable than comments from 100 anonymous people. I’d like to be able to profile myself a bit better; age, sex, location, interests… so developers know whether my feedback will be useful. A: Almost a match-making service? N: Possibly, yeah. It would be good for me to have that too, something that helps me find apps I may be interested in testing, based on criteria I determine and can change. A: I’d imagine an important factor for you is knowing that your feedback will be received, that you’re being heard? N: Definitely. There’s no use my efforts falling on deaf ears! I think this is something that could be improved with Litmus. At the moment apps and their feedback seem a million miles apart, we need to make them one and the same, almost a constant stream of everything that’s happening with an app, and the app in the middle of it all.

New survey on mobile operator developer communities . Let us know what you think http://bit.ly/Lw2gR