Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

January 26 2012

Why the fuss about iBooks Author?

This post originally appeared on Joe Wikert's Publishing 2020 Blog ("iBooks Author: Appreciating Apple's Intent"). It's republished with permission.

iBooks AuthorApple's recent announcement and release of its iBooks Author tool was met with plenty of controversy. This HuffPost article pretty well sums things up.

My question is simply this: Why all the fuss? Apple's intent has never been to improve the book publishing industry. Just like Amazon and any other ebook vendor, Apple's goal is to capture share of this rapidly growing segment. In Apple's case, it simply decided to offer an authoring tool that's capable of creating some pretty darned cool products. If Amazon were to do the same thing and create a terrific authoring tool for mobi or KF8 format, would the industry be as upset? I don't think so.

How is this any different from the App Store model itself? Developers are creating apps for the App Store, and they know they'll only run on an iOS device. They also realize they'll have to go through Apple's approval process before getting into the App Store.

Prior to the release of iBooks Author, the content creation and distribution model looked like this:

  1. Author writes material in favorite word processor.
  2. Author/publisher edit and convert that content into mobi format for distribution on Amazon, EPUB format for distribution through iBookstore and others, etc.

The exact same model still exists today, even with the introduction of iBooks Author. That's right. Apple's EULA doesn't really lock you into its distribution channel for your content. That restriction only applies to a "book or other work you generate using [the iBooks Author] software." All Apple's really trying to do is prevent you from tweaking the output of its tool to create content for other distribution channels. OK, that's kind of annoying, but far from the lock-in nightmare so many people are describing it as. Based on my interpretation, you're able to use the same content as input to the iBooks Author tool as you'd use for a mobi-formatted product you want to sell on Amazon.

(I should also point out that I'm far from an Apple fanboy. Anyone who knows me realizes I dumped my iPhone last year for an Android-based Samsung Galaxy S II (and yes, I love it). I also tried to dump my iPad for a Kindle Fire but found the Fire user experience to be very disappointing. I'll probably make the jump to another Android tablet later this year, once key apps like Zite are available. In the meantime though, I want to make it clear I'm not here to shill for Apple. If anything, I'm currently in a stage where I'd prefer to buy devices that aren't made by the content providers. Samsung is high on my list, for example.)

Apple doesn't have an objective to move the publishing industry forward. It sees an opportunity to reinvent this industry, and it feels it can do so within its own, closed ecosystem. It's as simple as that, and it's consistent with everything it has done in the App Store up to now.

Let's also not forget that the iBooks Author tool is free. It's not like we paid Apple $50, $100 or more for some authoring tool that we thought could work for all content formats and distribution channels. If the tool's feature set is compelling enough, I'd like to think the other ebook vendors (e.g., Barnes & Noble, Amazon, Kobo, etc.) will have to come up with something at least as powerful for their own platforms. If not, they get left in the dust and Apple gains share. Seems pretty fair to me.

In the meantime, I plan to do some hands-on testing with iBooks Author. At first, I was discouraged because you can't download iBooks Author unless you're running Lion. I'm still on Snow Leopard, but an O'Reilly colleague sent me this link that shows you how to tweak a couple of settings so you can download and run iBooks Author on a Snow Leopard system. I just tried it, and it works fine. (You just have to carefully read and interpret the steps since it's a translation from French to English.)

TOC NY 2012 — O'Reilly's TOC Conference, being held Feb. 13-15, 2012, in New York City, is where the publishing and tech industries converge. Practitioners and executives from both camps will share what they've learned and join together to navigate publishing's ongoing transformation.

Register to attend TOC 2012

Related:

January 17 2012

Four short links: 17 January 2012

  1. 5 Is The New 10 -- I have limited sympathy for the "app developers can't predict their fortunes" complaint: creative arts have always been long tail hit-based businesses, possibly because hits have a large random component.
  2. Lessons for Kickstarter Creators (Mat Howie) -- great case study of a disastrous KS project. Preparation, research, and comms are what let this one down. (via Mat Howie
  3. CSV Kit -- commandline tools for working with CSV files. (via Hadley Wickham)
  4. Science of Magic -- magic tricks which help you teach students how to apply the scientific method. Magic and science both built off flaws in human perception and intuition: science tries to avoid them, magic to exploit them. (via Maria Popova)

December 09 2011

Developer Week in Review: Developers are our most important asset?

I'm about halfway through the Steve Jobs biography (currently in the middle of the NeXT years), and I am continually struck by the dissonance of Jobs' incredible insight about some things and total blindness to others. It reminds me of an observation I used to make about some people: There's a reason Wisdom and Intelligence were two different stats in Dungeons & Dragons.

Not all of us are born to ascend to such lofty heights of fame, but it's nice to know that ...

Developers: Not just nameless cogs in the machine?

People who make a living making software have had reason to be nervous over the last decade. The trend seems to have been a race to the bottom of the salary scale, with generic talent in developing countries valued on par with highly experienced developers at home. Even when companies were willing to acknowledge that an external developer might not be as productive as an experienced one who has been working for the company for many years, the argument was made that since you could hire four or five foreign developers for the price of the stateside talent, the economics still made sense.

Now, an interesting essay in Forbes makes the argument that really good developers aren't twice or three times as valuable as the average, but 10 times or more. The essay's author, Venkatesh Rao, puts forward the proposition that smart companies such as Google recognize the value of retaining their high-end talent and deliberately shower them with lavish perks to keep them from straying. Rao argues that because developers require so little support infrastructure (as opposed to a biologist, for example, who needs staff and a lab), highly productive software engineers have a direct multiplier effect on the bottom like.

I've been noticing the beginnings of a backlash against the offshoring fad, as it seems have others. The question, of course, is whether average companies are able to look past the immediate cash-flow factor and evaluate the value of their staffs based on things such as the end quality of the product and (to quote Mr. Jobs) how insanely great the results are.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

Data centers and the boonies economy

The news has been alight recently with stories of large companies (Apple, Google, Facebook, Microsoft) setting up massive data centers in out-of-the-way locations. The reasons for this are several, and they've resulted in a perfect storm of motivations for placing data centers in rural locations.

First off, data centers require a lot of square footage, and a million square feet in the greater San Francisco Bay area is obviously a lot more expensive than in the wilds of Washington state. Construction costs are likely to be lower as well. Tax rates tend to be lower, and small country towns are more likely to offer incentivized tax rates to bring in jobs.

Second, data centers don't really require a lot of high-end staffing, beyond a resident engineer or two to keep things humming. Security personnel and maintenance staff are non-skilled positions that can be hired as easily in the mountains of the Ozarks as in downtown New York. And once again, they are likely to work much cheaper because the cost of living in rural locations is so low.

Many rural locations also are close to low-cost power generation sources, such as dams. Since electricity is a major cost in data center budgets, getting your power locally can take a large bite out of operating budgets. In addition, there is a belt of climate that runs through areas such as Colorado that offers the ability to take advantage of open air cooling, rather than having to run costly air conditioning all the time.

There's also something to be said for geographic diversity. If The Big One ever hits San Francisco, it will take down pretty much any data center in the affected area. Scattering your eggs into multiple baskets is common sense.

The reason that this works for data centers, and less so for things such as manufacturing, is that all a data center needs to function is good connectivity. With so much dark fiber strung across the country, it's not that expensive to bring multiple "fat pipes" to even the most remote locations, especially when you factor in all the savings. Data centers don't need good rail infrastructure, highways, geographic centrality, or any of the other factors that drive location decisions for physical manufacturing.

Your mobile news roundup

Ignoring for the moment the continual cacophony of lawsuits and counter-suits that seem to be business as usual these days, there were actually some recent news items of note in the mobile space.

There's no publicly available API for developers to add their own mojo to Apple's Siri, but that hasn't stopped enterprising hackers from discovering a way to do a man-in-the-middle intercept and add their own functionality. Before anyone gets in a tizzy, it only works if the mobile user explicitly opts in by installing a self-signed SSL certificate so that HTTPS connections to the hacked Siri proxy succeed. It's not something that could be done behind your back. Once in place, you can insert your own Siri functionality by writing code in Ruby on the proxy server. I've tried it, and it's surprisingly easy to make Siri jump through hoops. Apple will probably close this loophole soon, but for the moment it offers a tantalizing look at how powerful general access to a voice interface could be. The word is that Apple is hiring two engineers to work on APIs for Siri. Evidently, Apple sees the potential, too.

In Android-land, Google announced that the ten billionth app had been downloaded from the Android Market. By comparison, the 15 billionth iTunes app purchase occurred this summer, as announced at WWDC. There's no question that Android's velocity is greater than iOS, due largely to the huge number of phones running Android now, most of which are significantly cheaper than an iPhone. Is it time to wonder if the iPhone is going to end up being the Betamax of phones, eventually done in by a flood of inexpensive competitors? Or will it end up being more like the MacBook, the choice of anyone who can afford them?

In Redmond, Microsoft is ramping up a developer infrastructure for its Windows 8 platform, and the company has decided to follow the app store model as well. It appears that Microsoft will be offering better terms for developers, something that shouldn't be surprising, given Microsoft's legendary loyalty to those who choose to follow the way of Windows.

Got news?

Please send tips and leads here.

Related:

July 08 2011

Four short links: 8 July 2011

  1. OpenPCR Shipping -- A PCR machine is basically a copy machine for DNA. It is essential for most work with DNA, things like exposing fraud at a sushi restaurant, diagnosing diseases including HIV and H1N1, or exploring your own genome. The guy who discovered the PCR process earned a Nobel Prize in 1993, and OpenPCR is now the first open source PCR machine. The price of a traditional PCR machine is around $3,000. This one is $512 and would go well with Ben Krasnow's Scanning Electron Microscope. Biological tools get closer to hobbyist/hacker prices. (via Gabriella Coleman)
  2. Apple App Store Figures (Fast Company) -- 1 billion apps in a month, 200M iOS users, $2.5B revshare to developers so far (implying a further $5.8B revenue kept by Apple). Another reminder of the astonishing money to be made by riding the mainstreaming of tech: as we move from dumb phones to smart phones, the market for Apple's products and App Store sales will continue to rise. We're not at the fighting-for-market-share stage yet, it's still in the boom. (via Stephen Walli)
  3. Open Hardware Repository -- open source digital hardware projects, such as a tool for generating VHDL/Verilog cores which implement Wishbone bus slaves with certain registers, memory blocks, FIFOs and interrupts. CERN just approved an open license for hardware designs. (via CERN)
  4. Wingu -- SaaS startup to help scientists manage, analyze, and share data. Recently invested by Google, it's one of several startups for scientists, such as Macmillan's Digital Science which is run by Timo Hannay who is one of the convenors of Science Foo Camp. (via Alex Butler)

June 17 2011

Four short links: 17 June 2011

  1. Don't Play Games With Me -- slides from an excellent talk about games and gamification. (via Andy Baio)
  2. All Your Bitcoins Are Ours (Symantec) -- a trojan in the wild that targets the wallet.dat file and transfers your bitcoins out. If you use Bitcoins, you have the option to encrypt your wallet and we recommend that you choose a strong password for this in the event that an attacker is attempting to brute-force your wallet open. (via Hacker News)
  3. FT Escapes the App Trap (Simon Phipps) -- Financial Times dropping their iOS app and moving to HTML5, to escape the App Store commissions. As Simon points out, they're also losing the sales channel benefits of the App Store. Facebook are doing similar. (via Tim O'Reilly)
  4. Artur Bergman on SSDs (video) -- a short sweary rant he gave at Velocity, laying out the numbers for why you're an idiot not to use SSDs.

May 31 2011

10 ways to botch a mobile app

App StoreWith the phenomenal growth of smart mobile devices, mobile apps, and their respective app stores over the last several years, just about everyone has an idea for a mobile app. And with each idea comes the belief that it may in fact be the next big thing — a million dollar app that can save its creator from the daily 9-5 grind. It's true that a fortuitous few have indeed realized their million dollar idea, but for many others their ideas remain dreams alone.

Working in the mobile app industry through these early days of the latest technological gold rush, I've seen the same app mistakes made time and time again. Failure, like success, follows a particular pattern. And so, I set out to distill the top 10 reasons why apps often falter or fail, with the hope that this list brings more reason and less emotion into the process of building mobile applications.

Mistake 1. Begin coding immediately

Many fail in the mobile space because they start developing their app as soon as they have an idea. In the extreme case, those with programming skills will actually start coding the app immediately. The first steps, however, should be focused on business and strategy aspects; pixels and design or coding and development come later in the process.

Mistake 2. Ignore competitors and alternatives

One of those business and strategy aspects that many pursuing apps ignore is to identify and use competitor apps. Understanding what competitors do well and where they've come up short will provide guidance on what features to develop and how to differentiate an app. Similarly, learning from top apps in app stores or even real-world alternatives, can reveal opportunities for innovation.

Mistake 3. Be purposeless

Wanting a million dollars shouldn't be the sole motivation for building an app. At the same time, app stores are likely one of the best places to pursue a new venture right now. Ultimately though, it is still a new venture and any new venture comes with a certain amount of risk. Outlining clear short- and long-term goals, that are aspirational yet attainable, will provide a much better foundation for success.

App Savvy: Turning Ideas into iPad and iPhone Apps Customers Really Want — While many books simply explore the technical aspects of iPad and iPhone app design and development, "App Savvy" also focuses on the business, product, and marketing elements critical to pursuing, completing, and selling your app.

Get "App Savvy" as an ebook for only $11.99. Save 50% with the code DDSVE

Mistake 4. Consider project plans useless

It's not necessary to create a Gantt chart, but having a project plan for an app is critical. A project plan will demand accountability and set expectations, especially if working in a team. It should also help with one of the biggest problems in software development: actually shipping the app to the app stores.

Mistake 5. Start marketing after the app is launched

Many begin marketing their apps after they are in app stores. Doing so will result in not taking advantage of the initial bump provided by the app store new release lists. Getting marketing moving earlier will allow interested media outlets to have reviews ready when the app hits the stores, thus providing a better opportunity for the app to rank in its category.



Mistake 6. Spend little time thinking about branding


The app name, app icon, app description, and even the app interface are often developed independently of one another. As I've written in the past, however, these elements should be considered together because they help create the branding identity of the application. And that's even more important if there are plans to eventually have more than one app.

Mistake 7. Don't talk to customers before and after the app is launched

It's amazing how often people build their apps in isolation. They may get feedback from a couple of friends or family members, but they really don't develop serious beta testing programs with potential customers. Then, they launch the app and find reviews complaining about buggy or even missing features. Increasing the number of those looking at and using an app through a beta program will result in a more solid and compelling application by the time it hits the app store.



Mistake 8. Include zero contact points within the app


Not hearing from customers can be a symptom of an unhealthy app. It also might be because customers simply don't know how to get in touch with the creators of the app. Including basic support channels such as in app email or a link to a website can ensure customers will share thoughts, feedback, or bug reports quickly and easily.

Mistake 9. Forget to install analytics

Apps often generate qualitative feedback such as customer reviews, blog posts, and emails. Unless analytics are installed, quantitative feedback is typically only available through download and sales numbers. Analytics tools can offer basic insight into usage patterns or provide very detailed data about specific actions customers are doing inside the app. In either case, hard data is extremely valuable.

Mistake 10. Never update the app

After pushing out an initial version of an app, people give up on it if it’s not a runaway hit right away. To keep customers engaged, it’s a good practice to release one or two updates per month, related to either bug fixes or new features. You can cut back on app update investements if the app continues to show no signs of life, but that decision should not happen a week or even a month after the launch of an app.



Related:


May 25 2011

Four short links: 25 May 2011

  1. OTD Lessons Learned v1 (PDF) -- Dept of Defense report on use of open technologies. Advocates against forking open source projects, and provides specific guidance for groups looking to use OSS so they can navigate the military's producement policies and procedures in a way that'll deliver the best chance of success for the project. Imagine if only the manufacturer of a rifle were allowed to clean, fix, modify or upgrade that rifle. The military often finds itself in this position with taxpayer funded, contractor developed software: one contractor with a monopoly on the knowledge of a military software system and control of the software source code. (via John Scott)
  2. depth.js -- Javascript for Chrome and Safari that lets the Kinect interact with web pages. (via Javascript Weekly)
  3. A Liberating Betrayal (Simon Phipps) -- Microsoft have told Digium (makers of Asterisk) that they can't sell their Asterisk-Skype interaction module after July 26. Simon notes that this reveals the fundamental problem with "open core" approaches to open source business. The proprietary interests hold all the cards here. The community can't just "rehost and carry on" because the crucial add-on is proprietary. Even if wasn't, the protocol it's implementing is proprietary and subject to arbitrary change - very likely to happen if anyone attempts to reverse-engineer the interface and protocol. Asterisk may be open source, but if you're dependent on this interface to connect with your customers on Skype you've no freedoms - that's the way "open core" works.
  4. Zero Install -- Zero Install is a decentralised cross-distribution software installation system. Just hit 1.0. (via James Williams)

March 23 2011

Developer Week in Review

Netflix went down over three hours ago, and everyone is on edge here. My son just started reciting the script to "Monty Python and the Holy Grail" in an attempt to keep our courage up. This may be the last thing I ever write, so — Oh, never mind, it's back up again ... Crisis averted, and on to this week's developer news.

We have an App Store Appstore for that!

Amazon AppstoreAmazon this week unleashed their own Appstore for Android devices. Apple took umbrage at the use of the (evidently trademarked) term "App Store" and fired a salvo of lawyers across Amazon's bow. Amazon responded by essentially saying "Hey, app store is a generic term." To which Apple responded "So is windows, and Microsoft gets to protect that ..."

Given that Apple gave Amazon multiple warnings not to use the App Store tag, it's unclear why Amazon decided to be the one application store to challenge Apple for use of it. And unlike nebulous patent claims, trademark claims are pretty straightforward. Amazon is going to have a hard time arguing that their use of the term "Appstore" is sufficiently different from Apple's App Store, and that there couldn't be any confusion. But however things fall out in the end, the only winners, of course, will be the lawyers.

A moment of silence for Sun.com, please

An old and venerable friend is passing away, and we should all take a moment to reflect on the long and fruitful life that it led. Oracle has announced that they will be decommissioning the sun.com domain, the 12th oldest domain name on the Internet. For those of us whose fingers can type "java.sun.com" automatically, it will be a jarring change.

I first encountered Sun way back in 1985 when Xerox AI Systems decided to port their Interlisp workstations to run on Sun hardware. The Sun 4/110 on my desktop was (to me at the time) the coolest thing on the planet. For a while, it seemed like Sun (along with Cisco) was the Internet. Now the last major vestige of Sun, their domain, will be sold off like cattle. Excuse me, I think I have something in my eye ...

O'Reilly MySQL Conference & Expo, being held April 11-14, will spread the latest and best knowledge on MySQL and related technologies to the global open source community.

Save 25% on registration with the code MYS11RAD



Bake for 20 minutes, and Drizzle liberally with SQL


One of the side-effects of Oracle acquiring Sun is that MySQL was thrown into somewhat of a turmoil. Forked versions seemed to be cropping up everywhere. Now the first of the baby-MySQLs is getting on the bus and heading off to school, as Drizzle has announced their general availability release.

For individuals and companies looking for an alternative to Oracle's MySQL offering, Drizzle offers an API-compatible replacement that aims to be a leaner, meaner database optimized for high-performance operations. For those wanting a more traditionally MySQL experience without the Oracle baggage, MariaDB is still out there, of course.

Got news?

If you have some juicy news, please send tips or leads here.



Related:




February 23 2011

Developer Week in Review

Live, via satellite from around the world, it's Developer Week in Review, with your correspondent, Buff Overflow.

Apple policies rile developers (again)

Developers certainly seem to be getting fed up with Apple's dictatorial control of the App Store, and the new subscription and in-app purchase restrictions may push them over the edge. If Apple wants to avoid appearing to play favorites, they will need to apply the policy uniformly, which could put some very popular iPhone apps in jeopardy. For example, you can purchase and download audio books with Audible's app, and I can't see them agreeing to give up 30% of their gross income to Apple for the privilege. With companies big and small screaming for blood, and the FTC threatening to take a closer look, this may be one App Store policy that needs to be put back on the shelf.

Meanwhile, Google is rolling out their own subscription model, but it's unclear who the intended audience would be. Android apps?

Oh yah, and there's evidently an announcement about something called an iPad 2 happening next week ...

Ubuntu: Distribution on the edge?

All eyes (well, some eyes ... ok, my eyes) were turned this week toward Canonical, as some reports indicate that the formerly peace-loving Linux distro may be on a path toward more business-minded actions.

Agree or disagree with the premise of the article, but it's a good jumping off point for a conversation about just where the future of Linux distributions lie. With Ubuntu and Red Hat the two most public symbols of Linux, has the "pure" roots of Linux (such as Debian) been lost? Is Linux just another commercial operating system now, with an open source development model?

Is obscenity ruining our developers?

Your twenty-something PHP developer sits alone at a terminal, reviewing git commits. Seems innocent enough, but do you really know what your programmer is looking at? The answers may shock and disturb you.

Here's an interesting analysis of git commit messages (not comments in code, as Slashdot erroneously reported), looking at swear frequency by programming language.

C++, Ruby and JavaScript all had about the same amount, roughly twice that of C and three times that of C# and Java. PHP and Python programmers evidently don't swear much at all. The results were normalized, so the popularity of the languages didn't influence the weightings. Mind you, the total percentage of commit messages with any kind of swear at all was a tiny 0.022% (210 total swears), so it's not like it was a bar full of sailors.

That was the developer week that was. Please send tips or leads here.

January 19 2011

Developer Week in Review

Having somehow found myself in the bizarro world where the Patriots lose to the Jets, I scanned the InterWebs to see what other strange things might have occurred in the past week. My report follows.

The new cat in town

Despite all the hype that mobile platforms and dynamic languages such as Python garner, a lot of the web world still runs on Java. Thus, the news that the first stable build of Apache Tomcat version 7 was released is significant.

For those who have not had the pleasure, Tomcat is a fully functional J2EE (that's Java 2 Enterprise Edition) server, but without the big (or any) price tag. Version 7 brings along with it support for the 3.0 Servlet API and JSP version 2.2, upgrades sure to bring a sparkle of delight to your local Java web guru.

Amazon knows best

Thinking about selling your Android apps through the new Amazon App store? Amazon thinks they have a better idea what that app is worth than you do. Evidently, apps submitted for sale can have a suggested retail price, but Amazon will determine the actual selling price. The developer gets 70 percent of the selling price, or 20 percent of the retail price, whichever is greater.

So, if you put your masterpiece — "Enraged Avians" — into the store with an MSRP of $20, Amazon could decide to put it on sale for as little as $5.70, netting you $4 (20% of $20 = 70% of $5.70). What this means is that if you want to make a certain amount off each sale, you'll need to set an MSRP five times that amount to make sure you actually get it. Hilarious hijinks are sure to ensue as Amazon and the developer community dance with pricing levels.

HTML5, now with 100 percent more logos

HTML5 logoThere may be a battle brewing over which video codec to use with HTML5, and people are still debating if HTML5 is a good replacement for technologies like Flash, but the biggest issue facing the new standard has clearly been settled: HTML5 now has a logo. (The logo appears to either be co-branded with the Hunter Safety program or Tropicana orange juice.)

According to the W3C, the new logo is:

... an all-purpose banner for HTML5, CSS, SVG, WOFF, and other technologies that constitute an open web platform. The logo does not have a specific meaning; it is not meant to imply conformance or validity, for example. The logo represents "the Web platform" in a very general sense.

We can all rest safe in our beds tonight, knowing that we now have a logo to represent the "Web platform, in a very general sense."

What new logos await us in the coming week, and can they possibly use a more garish color scheme? We'll find out next week, in this same space. Suggestions are always welcome, so please send tips or news here.



Related:




November 09 2010

November 05 2010

Windows Phone apps are more expensive than iPhone apps

The Windows Marketplace for Mobile now has about 1,400 apps spread across 16 categories. In this short post I'll provide some basic statistics* and compare it with the grandaddy of app stores - the U.S. iTunes store.

First let's look at the distribution of apps across categories. Like the iPhone and Android platforms, Windows Phone 6.x / 7 are rich in game apps. Given that there are far fewer Windows Phone apps, it may take some time before we see the variety of categories found in iTunes. There are large iPhone categories (medical**, education, sports ... ) that aren't part of the taxonomy for Windows Marketplace for Mobile.

pathint

More than 90% of the 280,000+ iTunes apps aren't free, compared to 78% of apps available on Windows Marketplace for Mobile. Below are the share of free/paid apps across the different categories.

pathint

At least for now, Windows Phone 6.x / 7 apps are pricier than iPhone apps. The mean price of a paid iPhone app is $3.43, compared to $6.16 for paid apps available on Windows Marketplace for Mobile. Welcome news for the many developers gearing up to produce apps for Windows Phone 7!



pathint





(*) Data for this post: U.S. iTunes store through 10/31/2010, limited to iPhone apps; Windows Marketplace for Mobile through 11/3/2010.

(**) The Medical category was added several months after the launch of the iTunes app store.


October 21 2010

Four short links: 21 October 2010

  1. Using MysQL as NoSQL -- 750,000+ qps on a commodity MySQL/InnoDB 5.1 server from remote web clients.
  2. Making an SLR Camera from Scratch -- amazing piece of hardware devotion. (via hackaday.com)
  3. Mac App Store Guidelines -- Apple announce an app store for the Macintosh, similar to its app store for iPhones and iPads. "Mac App" no longer means generic "program", it has a new and specific meaning, a program that must be installed through the App store and which has limited functionality (only one can run at a time, it's full-screen, etc.). The list of guidelines for what kinds of programs you can't sell through the App Store is interesting. Many have good reasons to be, but It creates a store inside itself for selling or distributing other software (i.e., an audio plug-in store in an audio app) is pure greed. Some are afeared that the next step is to make the App store the only way to install apps on a Mac, a move that would drive me away. It would be a sad day for Mac-lovers if Microsoft were to be the more open solution than Apple. cf the Owner's Manifesto.
  4. Privacy Aspects of Data Mining -- CFP for an IEEE workshop in December. (via jschneider on Twitter)

June 30 2010

Popular iPhone games stay highly-ranked only for a few weeks

With 40,000+ Games to choose from, the list of Top 100 free and paid games are frequently scanned by iPhone gamers. In this short post, I'll share some basic statistics on popular games sold through the U.S. iTunes app store1.

How much time does a popular game app spend ranked in the Top 100? In the chart below I calculated how many different days an app appears2 on a Top 100 list. On average (i.e., using the median), a popular Paid game appears on the Top 100 chart on 15 different calendar days3:

pathint




A related metric is the proportion of days4 a popular app is on the Top 100 charts: for every 100 days its available in iTunes, a typical popular Paid game is on the Top 100 list on 5 different days.

pathint




How long does it take to secure a spot on a Top 100 list? Judging by the median age5 at chart debut, Top 100 game apps tend to crash the charts within a few days of their appearance in iTunes.

pathint




(1) Data for this post includes all U.S. iTunes (game) apps from 7/27/2008 to 5/30/2010. Most game apps work on iphones and ipads.

(2) For each app that has ever appeared in either the Top 100 Paid/Free Games lists, I counted the number of different (and possibly non-consecutive) days that app is on the list.

(3) However, the MEDIAN number of days between an app's Top 100 chart debut and final appearance, is 20 days for paid apps and 13 days for free apps.

(4) (# of different days app is in the Top 100) / (# of different days app is in iTunes)

(5) Days between (first appearance in iTunes) and (first appearance on Top 100 list).

June 29 2010

Four short links: 29 June 2010

  1. The Diary of Samuel Pepys -- a remarkable mashup of historical information and literature in modern technology to make the Pepys diaries an experience rather than an object. It includes historical weather, glosses, maps, even an encyclopedia. (prompted by Jon Udell)
  2. The Tonido Plug Server -- one of many such wall-wart sized appliances. This caught my eye: CodeLathe, the folks behind Tonido, have developed a web interface and suite of applications. The larger goal is to get developers to build other applications for inclusion in Tonido’s own app store.
  3. Wikileaks Fails "Due Diligence" Review -- interesting criticism of Wikileaks from Federation of American Scientists. “Soon enough,” observed Raffi Khatchadourian in a long profile of WikiLeaks’ Julian Assange in The New Yorker (June 7), “Assange must confront the paradox of his creation: the thing that he seems to detest most-power without accountability-is encoded in the site’s DNA, and will only become more pronounced as WikiLeaks evolves into a real institution.” (via Hacker News)
  4. Yahoo Style Guide -- a paper book, but also a web site with lots of advice for those writing online.

June 24 2010

iPhone economics and lower barriers to entry

Tomi Ahonen at Communities Dominate Brands has an interesting analysis on iPhone economics. It's a substantial piece with a lot of good stats, and his key conclusion is:

... don't invest in [app development] today ... Put your creativity and investment into the real money opportunities, remember Pop Idol simple SMS votes earning half a billion dollars in USA this year alone ...

He comes to this conclusion after observing that the vast majority of apps will lose money, while only a tiny handful generate significant revenue. Consequently, the logical response is for developers (and businesses) to instead focus their attentions on more lucrative opportunities. In other words, the only way to win is not to play the game.

While his numbers are sobering, they're not all that surprising. Consider publishing -- people have long known that the vast majority of authors slave away on projects that will never make any money, while a very few stars (think J.K. Rowling) make a killing. Whatever you call it -- the long tail, the Pareto principle, the 80/20 rule -- this simply appears to be the brutal truth of most media industries, from publishing to movies to music.

What I think he overlooks -- or is bemoaning -- is the important role the App store is playing in lowering the barriers to market entry for developers.  He cites the big money opportunities as "SMS, MMS, and WAP" (seriously, WAP?).  But, good luck trying to get a biz dev deal there. Only a few, really well-connected organizations are going to get those. When you compare the costs of hiring some kid out of college who can't believe he's actually getting paid to write apps to the cost of building the kind of highly skilled (and highly compensated!) sales force required to put these deals together, an app investment suddenly doesn't look so bad.

No, the bigger story is that the App Store has exposed incumbents in the mobile industry to the same sort of asymmetric competition that has reshaped the media industry over the past decade. Developers are responding in droves to the economic incentives that lower barriers to entry create, as well as the fact that the App Store has generated $1 billion in royalty payments in just a few years (by Ahonen's estimates). By way of comparison, the entire US tech book market is roughly $250 million gross, and it's been around for decades.

A single developer, or a small group of two or three developers, doesn't need to make a killing. What would be a rounding error in a big development deal is a huge win for these people. Or, they may simply be in it for the fun, and the money is totally secondary. Or, it could be that they've whipped something together quickly and put it up to see if anyone bites. (If you're interested, Mac Slocum is running a poll on Answers where you can chime in on other reasons people write apps.)

What the App Store did brilliantly is create a marketplace that anyone with the appropriate skills can enter. The development tools are free, the membership dues are cheap, and Apple's 30 percent take seems pretty reasonable when you consider the frictionless access to a global marketplace they're providing. This seems like a way better deal to the average developer than trying to get a development deal with phone manufacturers.

Related:

April 21 2010

Where do developers draw the line with Apple?

Dan Grigsby, founder of Mobile Orchard, is abandoning iPhone development. The reason? Apple's "ask permission" environment doesn't work for him anymore. He explained his decision in a recent blog post:

Ask permission environments crush creativity and innovation. In healthy environments, when would-be innovators/creators identify opportunities, the only thing that stands between the idea and its realization is work. In the iPhone OS environment when you see an opportunity, you put in work first, ask Apple's permission and then, only after gaining their approval, your idea can be realized. I've always worked at the edge; it's where the interesting opportunities live. None of the startup[s] I've created would have been possible in an ask permission environment.

What's interesting here -- from an industry perspective -- is that if you get past the Apple vs. Adobe vs. OS 4.0 vs. what-have-you stuff, there's two legitimate viewpoints floating around. You've got developers like Grigsby who find Apple's model too limiting. So they get out. And then you've got devs who think the App Store opportunity outweighs the obstacles (for now). Dan Pilone, co-author of "Head First iPhone Development" and founder of Element 84, is in that second group.

After corresponding with Grigsby and Pilone, I was struck by how much they have in common. There aren't any vast philosophical differences at play here. Both dislike aspects of Apple's model and both also see lots of opportunity in the App Store. Yet one is in and one is out.

The concerns

To help me understand his fundamental problems with Apple's model, Grigsby began by outlining the series of events that led to his departure from iPhone development.

iPad Coverage

Grigsby: Very often, you would have a group of developers in some kind of social setting and one would say, "I want to give you a free copy of my app." And in one case, a guy handed me a business card that had a URL for the iTunes store. And then he gave me a dollar and said, "Just go buy my app." That's crazy. I don't want your dollar. I want you to be able to whip out your iPhone and give me a promo code.

So, I wrote a single-site browser that would interact with iTunes Connect and let iPhone developers generate a promo code. Now I knew, because I've read the terms and conditions, that would never be allowed into the App Store. There's language in there that says you can't scrape the store. I was going to distribute the source instead. But I talked to some attorneys and they said Apple could decide that bothers them and kick me out of the program.

From what I perceived as maybe a $10,000 or $20,000 opportunity, I had to make a decision as to whether I should stay in this business. That's such an uncomfortable place to be. And so that most recent experience, the "you live or you die at Apple's discretion," made me start to look at all of the other examples of places where they're treating the App Store as an extension of their brand as opposed to just a marketplace. I lost all of my enthusiasm. I made a decision that I was going to change to something else.

Pilone has his concerns as well. He's a pragmatist, not an evangelist. He noted, for example, that recent app snubs should raise red flags for all developers.

Pilone: I think there's a potentially significant risk lurking out there. That's the approval process. Not from an "Are you using undocumented APIs?" perspective. That's an easy one to avoid. But from a "No thanks, you're competing with something we've already done," or "We don't want that kind of application on our phone," perspective.

Google Voice is the poster child for this issue, and there was a lot of rumor and speculation over whether the Opera browser was going to make it into the store (it ultimately did). This now begs the question, if Google Voice was delayed (Apple never officially rejected it as far as I know) because the voice, voicemail and SMS features duplicated functionality already on the phone, on what grounds could the Opera browser possibly be accepted? The point being, there's a real business risk of investing in a product only to have it completely rejected without any real avenues to rectify the situation. I don't want to make a bigger deal out of it than it is. Obviously 180,000+ other applications have managed to get into the store. But it's a risk.

A secondary marketplace

One proposed solution to developers' concerns is for Apple to allow a secondary market to take root. This would be an open space where developers who don't want to go through Apple's process can sell their apps legitimately. I posed this alternative to both Grigsby and Pilone.

Grigsby said a secondary marketplace would be a fine addition, but he's interested in a different change: he believes markets will naturally form if users can install software on Apple devices in much the same way developers can.

Grigsby: When you give someone the fundamental ability to install software on their phone, entrepreneurs will build marketplaces and create discoverability. Obviously, that's a threat to Apple. And so I can see Apple's point in all of this. This is why when you talk to me, I'm sad. I'm not mad. But it runs against my principles.

Pilone responded with a host of big questions:

Pilone: How many "secondary" marketplaces are we talking about? One? Two? Who decides? As a consumer, do I need to worry about all of them? What's my purchasing, downloading and installation experience like? Do I get enough value in the apps in that "store" to justify the time and complexity of having to figure it out? Sure, there will be power users who would use it, and as a developer I don't want to ignore that crowd, but really, in the grand scheme of things, what apps do you want or need that aren't in the App Store now? I go back to the philosophy that if a secondary market is valuable to you (as a developer or a consumer), go with a device that has it.

In or out?

I asked Grisby what Apple would have to do to get him back. He laughed, claiming he has no say in the matter. But in the off chance Apple asked, there's only one thing he wants:

Grigsby: I'm not standing outside saying, "Apple, you will do this or else." I recognize that my voice doesn't command that kind of authority with them. But I'd be happy if they gave people the ability to distribute apps outside of the store. I love marketing. I'm a marketing hacks kind of guy. So I can get people to find the applications. Just give me the ability to freely create works and find a market for them and I'll be happy.

It's a simple enough request. Just one tweak to the model, right? But in the course of my exchange with Pilone, he hit on the fundamental problem developers face: Apple is, above all else, focused on the consumer. Anything that runs counter to that isn't debatable.

Pilone: I take a very pragmatic approach to this. I think it's important for people (read: developers) to realize that Apple is a consumer products company. At the end of the day, they're about consumers, not developers. Apple philosophically believes that by delivering a closed system they can deliver a better consumer product. The success of the iPod and iPhone strongly supports that argument.

Apple's iPhone, iPod Touch, and iPad are "closed" devices that are 100-percent targeted at the end users. Developers are welcome, but you're going to support Apple's vision of the end-user experience whether you want to or not. Ultimately, it's a gamble for Apple. They're taking a risk that if they alienate too many developers, some other platform may draw them in. But Apple's wagering that if they make the best consumer product out there, it will have the largest user base. Developers will code for it because that's where they can be paid for their work and reach the broadest audience.

April 02 2010

What brand of freedom would you like?

There's been a ton of criticism, including from me, over Apple's restrictions on the App Store. How it restricts the freedom of developers by blocking applications users definitely want to use, or yanking apps that fail to meet a changeable standard of appropriateness or legitimacy. I originally thought I would never buy an iPhone because of that policy alone, and I felt like quite a hypocrite when I decided to buy one anyway. As many people have pointed out, the iPad, if successful, will further extend Apple's control over the code its users are able to run.

iPad CoverageOne of the main pitches for Google's Android platform, in contrast, is that it is more open, freer, more consistent with the principles that the open source world (and this blog, and I) espouse. For the code, and applications running on it, that certainly seems to be true. I can go to source.android.com and download the Android source. The Apache license applied to most of the project is very liberal in the use of that code. As a developer, I can publish applications for Android at www.android.com/market, where, Google says, "developers have complete control over when and how they make their applications available to users." How much more free could you get and still call it a platform? The Android stance is nearly 180 degrees from the iPhone's. One is free and the other is closed.

And yet, I don't think the contrast is as clear as that. Freedom means different things to different people. Hence Richard Stallman's quip, "Think free as in free speech, not free beer." While there's no question the code is much more free on Android, I think Steven Levy's point in his piece on the iPad is worth repeating:

While Apple wants to move computing to a curated environment where everything adheres to a carefully honed interface, Google believes that the operating system should be nearly invisible. Good-bye to files, client apps, and onboard storage -- Chrome OS channels users directly into the cloud ...

Funneling users to the cloud means storing their data for them, on Google-owned and controlled servers. And Google is at least as restrictive about the data on its servers as Apple is about the apps in its App Store -- maybe, I think almost certainly, a lot more restrictive.

Google has long taken the stance that users should trust it with their data (famously enshrined in the company's "don't be evil" motto). And indeed, Google has taken stances I believe are favorable to users' interests, including fending off subpoenas from the U.S. government for search data when other search companies did not, and, last week, advocating for better privacy laws (meaning, privacy of Google's data from government demands).

Google often seem to take those admirable stances, though, when users' privacy interests coincide with Google's business interests. When they don't, Google sometimes argues for its business interests above users' privacy interests. For instance, see Google's arguments for the benefits of log retention, which as the AOL search data case showed, can certainly be harmful to users' interests. In these cases, the protections -- that is, the freedom offered by Google -- is limited to "trust us."

I'm not just spouting off, here. At my company, we promise users what we call the "Data Bill of Rights," which states in very plain language the control our users retain over their data. We also recently released an open source server framework that helps "cloud" applications responsibly store user data. If Google wanted to make promises to users about data that were as strong as the freedoms it offers around the Android code, it could, and it doesn't.

I have no hard evidence that Google is untrustworthy with my data, but nor do I believe that the emailed report I got from my doctor's office in my Gmail account was completely removed when I hit "delete." I've had conversations with Google engineers that have creeped me out to no end and made me reluctant to use its services, as good as they are, and I feel like quite a hypocrite when I decide to do so anyway. Likewise, I have no hard evidence that Apple wields its control any more or less responsibly than Google does.

I disagree with calls both companies have made with their respective points of control, but in general I believe both are trying to create fantastic products in a responsible way. And the guarantee I have that that is true for either company? None. Apple can and occasionally does abuse its control over the App Store to further its business interests Google can and occasionally does abuse its control over hosted data to further its business interests.

What brand of freedom do you prefer? I find myself undecided. I don't like either brand, since neither really seems free to me. I'm sure, though, that saying Apple is an overly restrictive platform and Google/Android is a free and clear platform is a false dichotomy.

March 10 2010

Four short links: 10 March 2010

  1. The Future of Book Publishing Business Models (Stephen Walli) -- some good thoughts about the book publishing industry and ebooks. When does Amazon create the iPhone/Android app and the programme that will allow bookstores to receive a cut of every Kindle edition they sell? I scan the book's in-store barcode with my smartphone, and I get the Kindle edition delivered, and the store gets its cut. Why is this different in concept than Borders on-line store being run on Amazon, or any of the independent book sellers that front through Amazon? It's not the normal book mark-up, but people already browse bookstores and buy on Amazon. This is better than no revenue. (When was the last time you went to a travel agent?)
  2. Google Apps Enterprise Marketplace -- this is sweet. It looks like the play is to become the home page for authenticated apps rather than to make commissions from selling the apps themselves. This may be the Google business model vs the Apple business model in a nutshell. (via Marc Hedlund)
  3. iPad Application Design -- some fantastic notes about the kinds of UI design that iPad encourages. I've avoided covering The Second Coming of The JesusPhone but this is interesting because of the middle ground it stakes out between phone and laptop. The primary warning about designing for the iPad is: more screen space doesn’t mean more UI. You’ll be tempted to violate that principle, and you need to resist the temptation. It’s OK to have UI available to cover your app’s functionality, but a bigger screen doesn’t mean it should all be visible at once. Hide configuration UI until needed. Look like a viewer, and behave like an editor ... There’s been a history of modes getting some bad press on the desktop. The issue is that they trade stability (things always being in exactly the same place in the UI, and not changing) for simplicity (not having too many controls to look through at once). On the iPad, it’s clear where the winning side of the balance is: simplicity. Modes are completely appropriate on this device. (via Marc Hedlund)
  4. The Howtoons Visual Creation Guide -- we teach grammar and spelling in schools but not visual communication. This short booklet is a good start to remedying that. (via BoingBoing)

March 03 2010

The implications of a money-making Android app

Android logoThere's been plenty written about the App Store gold rush, but this is the first rags-to-semi-riches piece I've seen about the Android Market. Edward Kim, creator of the Car Locator app, saw his daily revenue jump from around $100 per day to more than $400 per day when the $3.99 app claimed a featured spot in the Market.

It's only one data point, but I'm interested in the broader implications here. Those early "there's gold in iPhone apps!" stories fueled interest in the platform. And while a lot of that iPhone excitement was later tempered by the realities of a hit-driven business, that first flush of exuberance was an important step.

If similar stories pop up in the Android universe -- legit stories, I'm not advocating lies and fabrications -- I see that catalyzing more developer interest, more competition, more refinement (something that's sorely needed in the Android Market), and ultimately, a more robust Android app ecosystem. That's a lot of "mores," I know, but after three-plus months of using an Android device, my enthusiasm for this platform continues to grow. Apps like Google Goggles and Google Sky Map are amazing. What I'd like to see, however, is broader Android experimentation by companies not named Google.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl