The "long tail"? Read this:
from: http://www.nytimes.com/2010/01/31/fashion/31apps.html
A survey of iPhones, iPod Touch and Android users conducted in July 2009 by AdMob, an advertising network that helps people promote their applications on smartphones, found that people discover apps most often by browsing app stores. And even though the iTunes store is bloated with offerings, people tend to gravitate to the most popular.
“For all the tens of thousands of apps out there, the odds of being exposed to more than a thousand are very small,” said Stewart Putney, the founder and chief executive of Moblyng, a company in Redwood City, Calif., that develops applications for mobile devices.
“The top apps featured at the store do change out,” Mr. Putney said. “But most users will never see more than 1 percent of the total apps available.”
Saturday, January 30, 2010
Thursday, January 28, 2010
Obama, Jobs, jobs and The Vision Thing Vision
Q: What's Just as Good as My White 13" MacBook?
A:Except for the smaller screen, the lack of hardware extensibility, the missing keyboard, a pocket sized operating system on an attache case sized device? Give up? You know.
I hope to Job we don't have to hear much more about this. At least not like the silly opinion piece in this morning's Washington Post - SOTU for CEOs: More like Jobs, less like Obama - (oh wait, it's not an opinion piece, it a "Guest Insight") in which Jobs' vision for iPad trumps Obama's vision for jobs (and presumably everything else).
Never mind that Obama's vision has to be implemented by people who are elected, polarized and sensitive to the whims of their constituents.
Never mind that Obama's vision has to be sold over the drone of conjecture from a host of media hosts who are almost universally shallow and often nasty, while Jobs' vision has been pre-sold by a host of fawning techie press gurus who are almost universally out of their environment when it comes both technology and business.
Never mind that Obama's vision is complex and, by necessity, intertwined with many issues while Job's vision is a retail product.
Never mind that Obama's vision and the change that it entails is scary to most people while Jobs' has delivered a vision of a status symbol that no one really needs and everyone must have.
Other than that, the guest insight is very.... insightful.
I do agree with the author's observation that corporate vision is essential for success. But I disagree about the nature of the success (and failure). Most CEOs neither have nor communicate effective vision. But it's usually the company, the employees and the stockholders who suffer. The CEOs usually ride on until the company goes under (or at least until the rats are packing their little fanny packs). Corporate vision is essential for a company. But CEOs and their legions of loyal management seem to get by just fine without it.
A:Except for the smaller screen, the lack of hardware extensibility, the missing keyboard, a pocket sized operating system on an attache case sized device? Give up? You know.
I hope to Job we don't have to hear much more about this. At least not like the silly opinion piece in this morning's Washington Post - SOTU for CEOs: More like Jobs, less like Obama - (oh wait, it's not an opinion piece, it a "Guest Insight") in which Jobs' vision for iPad trumps Obama's vision for jobs (and presumably everything else).
Never mind that Obama's vision has to be implemented by people who are elected, polarized and sensitive to the whims of their constituents.
Never mind that Obama's vision has to be sold over the drone of conjecture from a host of media hosts who are almost universally shallow and often nasty, while Jobs' vision has been pre-sold by a host of fawning techie press gurus who are almost universally out of their environment when it comes both technology and business.
Never mind that Obama's vision is complex and, by necessity, intertwined with many issues while Job's vision is a retail product.
Never mind that Obama's vision and the change that it entails is scary to most people while Jobs' has delivered a vision of a status symbol that no one really needs and everyone must have.
Other than that, the guest insight is very.... insightful.
I do agree with the author's observation that corporate vision is essential for success. But I disagree about the nature of the success (and failure). Most CEOs neither have nor communicate effective vision. But it's usually the company, the employees and the stockholders who suffer. The CEOs usually ride on until the company goes under (or at least until the rats are packing their little fanny packs). Corporate vision is essential for a company. But CEOs and their legions of loyal management seem to get by just fine without it.
Friday, January 22, 2010
The Google Event Horizon
You know that it's all "in there" - assuming that it's been digitized by Google or it's available on-line for crawling. But you will not find it unless you already know exactly what you're looking for. That's unlikely if it's not a personal memory or something that you learned in history class. And history is soooo yesterday.
As what people discover becomes more and more influenced by what most people have already been able to discover through search engines, the event horizon (or maybe the fact horizon) gets closer and closer to the present.
An example. If you're millenial (hate that) you probably think that the use of cute abbreviations is owned by SMS, IM and Twitter. Let's channel through the horizon with the help of Kent Engineers, who have compiled a list of early radio abbreviations:
http://www.kent-engineers.com/abbreviations.htm
http://www.kent-engineers.com/prosigns.htm
http://www.kent-engineers.com/qcode.htm
Of course Kent seems to be in the UK, where history is still acknowledged (though perhaps only as a fetish). In addition to coveting several of Kent's Morse keys, I'm thinking about how Morse code is, by itself, neither analog nor digital. It's temporal (the dashes are longer, the dots are shorter).
Maybe Google or someone can find a way of opening the event horizon. One possibility, an algorithm that can correlate recent events with older ones and present results in an historical context. That still weights things towards the now. But it would be a start.
As what people discover becomes more and more influenced by what most people have already been able to discover through search engines, the event horizon (or maybe the fact horizon) gets closer and closer to the present.
An example. If you're millenial (hate that) you probably think that the use of cute abbreviations is owned by SMS, IM and Twitter. Let's channel through the horizon with the help of Kent Engineers, who have compiled a list of early radio abbreviations:
http://www.kent-engineers.com/abbreviations.htm
http://www.kent-engineers.com/prosigns.htm
http://www.kent-engineers.com/qcode.htm
Of course Kent seems to be in the UK, where history is still acknowledged (though perhaps only as a fetish). In addition to coveting several of Kent's Morse keys, I'm thinking about how Morse code is, by itself, neither analog nor digital. It's temporal (the dashes are longer, the dots are shorter).
Maybe Google or someone can find a way of opening the event horizon. One possibility, an algorithm that can correlate recent events with older ones and present results in an historical context. That still weights things towards the now. But it would be a start.
Tuesday, January 19, 2010
The Lost Carrot Process
This recipe came from The Chief Cook's sister, who happens to be The Chief Cook of The East. You slice some carrots (about 1 pound shown here).
And saute, stirring frequently, in butter and olive oil until they begin to caramelize. How far you go is up to you. I like them slightly blackened around the edges.
Season at the last moment. Just salt and pepper for me. You'll notice that the carrot volume has decreased considerably. I was talking with The Berkeley Daughter while I was cooking this dish and I'm sure that she would agree that a large quantity of carrot flogiston has returned to the aether.
You can squeeze a dash of lemon juice over the carrots before serving. In the original recipe, you're supposed to pulverize the carrots after cooking. But I like em like this. According to The Chief Cook, "You're not supposed to serve carrots with pasta". But I did. And the following proof is published against her wishes.
And saute, stirring frequently, in butter and olive oil until they begin to caramelize. How far you go is up to you. I like them slightly blackened around the edges.
Season at the last moment. Just salt and pepper for me. You'll notice that the carrot volume has decreased considerably. I was talking with The Berkeley Daughter while I was cooking this dish and I'm sure that she would agree that a large quantity of carrot flogiston has returned to the aether.
You can squeeze a dash of lemon juice over the carrots before serving. In the original recipe, you're supposed to pulverize the carrots after cooking. But I like em like this. According to The Chief Cook, "You're not supposed to serve carrots with pasta". But I did. And the following proof is published against her wishes.
Friday, January 15, 2010
Software Solutions, The Hard Way
Software product developers are often thoughtless (ok clueless) about how their solutions are deployed, maintained and used. That's why we have Microsoft Word and J2EE.
But this isn't about that.
Literally, the term "I.T." implies involvement and mastery of the entire computer science / information science domain. In practice, I.T. usually involves operational aspects of software solutions including the solutions themselves as well as storage, network, support, security and compliance.
I.T. organizations that are asked to develop software solutions are often managed by people who are inexperienced in product design and totally focused on operational stability and risk reduction (as they should be).
That's why you get over-budget, unfinished, eternally "enhanced" expensive systems that are very secure and often highly dysfunctional. Those systems run along side non-secure and impossible to support "stovepiped" VB and Excel solutions and "legacy platforms" that are so covered in band-aids that no one remembers what they looked like. The monsters can never be killed because they plug the functional gaps in the "real" systems.
So you end up with the least cost effective solutions on the books and the least secure, most difficult to integrate solutions on the desktops.
No amount of process will solve this problem (ok that's my opinion). ITIL, which has been very very good for ITIL consultants, authors and internal governance groups, may or may not be great for improving operational performance. But solution development?
If I.T. departments were hotbeds of innovation and magnets for the best product developers, perhaps a bit of process could tweak the bottom line. But that's not the case. The problem is not lack of process. It's lack of experience, vision and skills (for product managers even more than for developers). In most cases, I.T. organizations, because of their responsibility to focus on running long term cost effective programs to ensure operational stability and minimize risk, present the very opposite of the environment in which innovation is possible. Not just technical innovation, but innovation in the processes behind software product development. That translates into lowered expectations and solutions that are delivered at the highest cost, with the longest development cycle and the lowest probability of customer acceptance. Extensibility? Interoperability? That's a whole other post.
Even Google, as it has grown, has had to deal with this reality. Your organization delivers product as well as Google does? You can stop reading here.
If you're a business manager with a problem that needs a technical solution, you can spend a lot of money and time trying to teach your I.T. organization to cook by having them read books about dish washing. Or you can go out and hire a few guys (and or gals) in a garage. Your choice.
You can even buy the garage. But, unless you enjoy watching flowers wilt, I wouldn't recommend that.
Added 1-18:
Here's a now well known example: http://science.house.gov/Press/PRArticle.aspx?NewsID=2289
It seems as though 1/2 billion dollars and 800 contractors just wasn't enough. A more detailed account (PDF) can be found here: http://democrats.science.house.gov/Media/File/Commdocs/Staff_Memo_toBM_terror_watch_8.21.08.pdf
But this isn't about that.
Literally, the term "I.T." implies involvement and mastery of the entire computer science / information science domain. In practice, I.T. usually involves operational aspects of software solutions including the solutions themselves as well as storage, network, support, security and compliance.
I.T. organizations that are asked to develop software solutions are often managed by people who are inexperienced in product design and totally focused on operational stability and risk reduction (as they should be).
That's why you get over-budget, unfinished, eternally "enhanced" expensive systems that are very secure and often highly dysfunctional. Those systems run along side non-secure and impossible to support "stovepiped" VB and Excel solutions and "legacy platforms" that are so covered in band-aids that no one remembers what they looked like. The monsters can never be killed because they plug the functional gaps in the "real" systems.
So you end up with the least cost effective solutions on the books and the least secure, most difficult to integrate solutions on the desktops.
No amount of process will solve this problem (ok that's my opinion). ITIL, which has been very very good for ITIL consultants, authors and internal governance groups, may or may not be great for improving operational performance. But solution development?
If I.T. departments were hotbeds of innovation and magnets for the best product developers, perhaps a bit of process could tweak the bottom line. But that's not the case. The problem is not lack of process. It's lack of experience, vision and skills (for product managers even more than for developers). In most cases, I.T. organizations, because of their responsibility to focus on running long term cost effective programs to ensure operational stability and minimize risk, present the very opposite of the environment in which innovation is possible. Not just technical innovation, but innovation in the processes behind software product development. That translates into lowered expectations and solutions that are delivered at the highest cost, with the longest development cycle and the lowest probability of customer acceptance. Extensibility? Interoperability? That's a whole other post.
Even Google, as it has grown, has had to deal with this reality. Your organization delivers product as well as Google does? You can stop reading here.
If you're a business manager with a problem that needs a technical solution, you can spend a lot of money and time trying to teach your I.T. organization to cook by having them read books about dish washing. Or you can go out and hire a few guys (and or gals) in a garage. Your choice.
You can even buy the garage. But, unless you enjoy watching flowers wilt, I wouldn't recommend that.
Added 1-18:
Here's a now well known example: http://science.house.gov/Press/PRArticle.aspx?NewsID=2289
It seems as though 1/2 billion dollars and 800 contractors just wasn't enough. A more detailed account (PDF) can be found here: http://democrats.science.house.gov/Media/File/Commdocs/Staff_Memo_toBM_terror_watch_8.21.08.pdf
Thursday, January 14, 2010
And Speaking of Entropy...
Shannon wrote "A Mathematical Theory of Communication" in 1948.
Fourteen years earlier, Eliot wrote:
The endless cycle of idea and action,
Endless invention, endless experiment,
Brings knowledge of motion, but not of stillness;
Knowledge of speech, but not of silence;
Knowledge of words, and ignorance of the Word.
All our knowledge brings us nearer to our ignorance,
All our ignorance brings us nearer to death,
But nearness to death no nearer to GOD.
Where is the Life we have lost in living?
Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?
The cycles of Heaven in twenty centuries
Bring us farther from GOD and nearer to the Dust.
(from "The Rock", 1934)
Fourteen years earlier, Eliot wrote:
The endless cycle of idea and action,
Endless invention, endless experiment,
Brings knowledge of motion, but not of stillness;
Knowledge of speech, but not of silence;
Knowledge of words, and ignorance of the Word.
All our knowledge brings us nearer to our ignorance,
All our ignorance brings us nearer to death,
But nearness to death no nearer to GOD.
Where is the Life we have lost in living?
Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?
The cycles of Heaven in twenty centuries
Bring us farther from GOD and nearer to the Dust.
(from "The Rock", 1934)
Tuesday, January 12, 2010
How to Monetize AIM
"Monetize" is a ridiculous word, up there with 'hydrate" (like when you drink a - presumably way overpriced - liquid) and "strategize" (like when you sit around - at a presumably way overpriced hourly rate - trying to figure out what to do). Those words imply that some fabulous process will get you to some glorious place. Good luck.
How can AOL monetize assets like AIM? Easy, stick ads on everything and give most of the "momo" to Google. They'll invest part of it in whatever it takes to make your base product into a commodity. Don't like Google? Microsoft will be happy to take your money. That's it. Strategy 2.0.
How can AOL make money with assets like AIM? If I had a fully functional asynchronous (push) network with 10s of millions of authenticated users, I might want to explore the ways in which that network could deliver, meter and bill content and other services on behalf of publishers. That's one technical and business model that could make money for AOL.
The business and technical realities of an end to end asynchronous distribution network in which all endpoints can be authenticated, metered and billed by a single federated source while delivering content directly to conventional and mobile desktops should give companies like Google a bit of indigestion. The search gatekeeper is replaced by a content gatekeeper. And the model is actually a service to content publishers (not an awful reality that they just have to accept). Too bad AOL doesn't consider this as they hire investment bankers to sell off ICQ (and who knows if AIM will be next).
If anyone's left at AOL, give me a call.
How can AOL monetize assets like AIM? Easy, stick ads on everything and give most of the "momo" to Google. They'll invest part of it in whatever it takes to make your base product into a commodity. Don't like Google? Microsoft will be happy to take your money. That's it. Strategy 2.0.
How can AOL make money with assets like AIM? If I had a fully functional asynchronous (push) network with 10s of millions of authenticated users, I might want to explore the ways in which that network could deliver, meter and bill content and other services on behalf of publishers. That's one technical and business model that could make money for AOL.
The business and technical realities of an end to end asynchronous distribution network in which all endpoints can be authenticated, metered and billed by a single federated source while delivering content directly to conventional and mobile desktops should give companies like Google a bit of indigestion. The search gatekeeper is replaced by a content gatekeeper. And the model is actually a service to content publishers (not an awful reality that they just have to accept). Too bad AOL doesn't consider this as they hire investment bankers to sell off ICQ (and who knows if AIM will be next).
If anyone's left at AOL, give me a call.
Subscribe to:
Posts (Atom)