Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/21/2010
07:49 PM
Bob Evans
Bob Evans
Commentary
50%
50%

Global CIO: Will Steve Jobs Ban Google From AppleWorld?

An imaginative Apple investor says Steve Jobs is preparing to rock Google's world.

"The moral of the story is that Steve Jobs is not someone you want to depend on for your livelihood... I'll bet that in one of those Apple board meetings that Google CEO [Eric] Schmidt used to attend, he realized that Jobs was on the verge of building AppleWorld and he's been scared ever since." Concerned, sure--but is almighty Google "scared" of anything?

That opening quotation comes from a zealous Apple investor and money manager Jason Schwarz, who holds a long position on Apple and therefore is not exactly an unbiased source. But I've read a lot of Schwarz's analyses in the past year (you can find many of them here) and while he can sometimes be more cranked-up than a Jolt-chugging and deadline-stressed programmer, he also offers some unique and compelling perspectives on Apple and its singular CEO.

Here are the two full opening paragraphs from his blog entry yesterday on SeekingAlpha.com in which he lays out his theory for why Google is, indeed, scared:

"Steve Jobs is walking the same path as Walt Disney," writes Schwarz. "As soon as California's Disneyland was completed, Walt knew he had made a terrible mistake by not securing the surrounding real estate. He had built this wonderful destination but his oversight allowed hotel chains and restaurants to come in and make more money off his customers than he did. So Walt immediately went to Orlando, FL and built Disneyworld the right way.

"The moral of the story is that Steve Jobs is not someone you want to depend on for your livelihood. His goal is to build a closed digital neighborhood where Apple controls who makes money and who doesn't. I'll bet that in one of those Apple board meetings that Google CEO Steve [Eric] Schmidt used to attend, he realized that Jobs was on the verge of building AppleWorld and he's been scared ever since."

Now, as I said, Schwarz has a big dog in this fight via his investments in Apple. But the DisneyWorld metaphor was intriguing enough that I wanted to share it, particularly as it relates to the oncoming explosion of mobile computing that Schwarz says lies at the heart of Jobs' desire to build AppleWorld. As Schwarz puts it:

"Apple quickly realized that apps would one day overtake .coms. They knew that mobile devices would overtake PCs. And last but not least, they knew that they had a two year head start to completely control this mobile community. This did not sit well with Eric Schmidt."

Will the mobile phenomenon be powerful enough to rattle companies of the size and significance of Google? Can Steve Jobs--or any tech CEO in these days of the primacy of openness--create a business ecosystem in which that CEO determines who makes money and who doesn't? Can such a narrow construct survive in these days of near-unlimited choice?

Global CIO
Global CIOs: A Site Just For You
Visit InformationWeek's Global CIO -- our new online community and information resource for CIOs operating in the global economy.
Schwarz clearly has his opinion on that, and whether you're an Apple zealot like he is or a Google devotee, I think you'll enjoy his piece and the premise he lays out for how the next few mobile-madness years might shape up.

The significance of this for CIOs, of course, is the inexorable move toward more mobile devices and more mobile applications, and along with that the remarkable rise of the iPhone and the AppStore as the richly connected and fully capable device of choice for professionals.

In that context, if Steve Jobs is able to build the AppleWorld of Schwarz's imagination, and if Jobs is able to dictate who's in and who's out, then Google might very well have good cause to be concerned. And maybe even a little scared.

RECOMMENDED READING:

Bob Evans is senior VP and director of InformationWeek's Global CIO unit.

To find out more about Bob Evans, please visit his page.

For more Global CIO perspectives, check out Global CIO, or write to Bob at [email protected].

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16123
PUBLISHED: 2020-12-04
An Ubuntu-specific patch in PulseAudio created a race condition where the snap policy module would fail to identify a client connection from a snap as coming from a snap if SCM_CREDENTIALS were missing, allowing the snap to connect to PulseAudio without proper confinement. This could be exploited by...
CVE-2018-21270
PUBLISHED: 2020-12-03
Versions less than 0.0.6 of the Node.js stringstream module are vulnerable to an out-of-bounds read because of allocation of uninitialized buffers when a number is passed in the input stream (when using Node.js 4.x).
CVE-2020-26248
PUBLISHED: 2020-12-03
In the PrestaShop module "productcomments" before version 4.2.1, an attacker can use a Blind SQL injection to retrieve data or stop the MySQL service. The problem is fixed in 4.2.1 of the module.
CVE-2020-29529
PUBLISHED: 2020-12-03
HashiCorp go-slug before 0.5.0 does not address attempts at directory traversal involving ../ and symlinks.
CVE-2020-29534
PUBLISHED: 2020-12-03
An issue was discovered in the Linux kernel before 5.9.3. io_uring takes a non-refcounted reference to the files_struct of the process that submitted a request, causing execve() to incorrectly optimize unshare_fd(), aka CID-0f2122045b94.