I'm not so sure it's that unpredictable. Prediction should be based on
popular usage, market penetration, etc. Google Wave seemed like a total
bomb to me. Half the people I talked to didn't even know what it was
supposed to be, much less how to use it. The other half had half-baked
opinions that conflicted. I didn't predict the end of Google Wave; but
if I cared about that sort of thing, I might have been able to.
Android is categorically different, I think. I've used my HTC G1 (the
first android phone) the whole time, following upgrades nicely, in an
almost exact analogy to any other distribution of linux (thanks to
obsessive efforts like Cyanogenmod). The hardware evolves with its own
pattern and the software with it's pattern. I suppose I just don't see
the need for the hyper-tight coupling between hardware and software, at
least not on a general computing platform like a smart phone. Tight
couplings remain important (as Dave points out in his "arsMagna"
document) for embedded or special purpose devices. But for these little
computers we call smart phones, the hardware software decoupling we've
used for laptops and desktops all these years works very well (thanks to
obsessive efforts like GNU).
The case with Groups is interesting because on the one hand, it's well
adopted; but groups, in general, may be going out of style. Many (who
care about this sort of thing) might infer that the future lies in
things like Twitter or Facebook. Hence, Buzz. Until the dust settles,
Google will keep Groups. If the settling out demonstrates a solid place
for Groups, it will stay beyond then. If the trend really is toward
things like Buzz, it will eventually deprecate Groups.
Your larger issue, whether to _rely_ on some technology or service, is
more important. I don't think anyone should form any business decision
from an "early adopter", gadget giddy, point of view. Vendors,
including Google, have an implicit objective to put cages around their
customers. If there's any way they can "trap" you into always using
their product/service, then that's what they'll do. That's what they're
_supposed_ to do, what they must do. Otherwise, customers will jump
ship any time they want. A good customer will always maintain as much
agility as possible to jump from one of its vendors to another at any
time. That's a customer objective. The threat of customer jumping
keeps vendors effective and efficient.
Google's caging methods, however, differ from typical vendors' caging
methods because of its business model, which is based on ads, eyeballs,
and light protocols. Google cages you by (trying to be) being the most
effective, most efficient, most accessible product/service available.
They don't have the luxury of contractual lock-ins with consumers. If
they pull it off with a given product/service, it stays. If they fail,
it goes. That's what they want and that's what we (as customers) want.
More importantly, that's what the ecology wants.
Anyway, what I'm trying to say is that you _should_ build your system
with redundant storage systems, rather than lock yourself into Google
Storage. In fact, Google _expects_ you to build redundancy into your
storage systems. That way, if the market evolves so that Google Storage
isn't efficient or effective, they can abandon the service at will
without irritating any of their good customers. (Bad customers will
always, eventually, get irritated with their vendors because those
customers don't understand their vendors. Their expectations are flawed.)
Don't be wary, be happy! And use Google Storage as one of your
redundant storage solutions. When it, or S3, or IDE drives, or whatever
go away, just replace it with its nearest modern equivalent.
Owen Densmore wrote circa 10-08-05 09:33 AM:
From the sfx list, part of a discussion on The Google Way so to
speak. Basically they are pretty unpredictable, as shown by this
killing the Google Wave application.
This appears to be the Google style .. at the Google I/O conference
it was evident in the way groups at Google interact and collaborate:
they are not attempting to "fit in" to a bigger picture, rather they
are small independent efforts.
This is important to many of us who would like to use Google tech.
Google App Engine (GAE) for example is tempting, but at this point, I
think it safe to say we should not risk a project with a client
deliverable using GAE. Sad, 'cause its a good system.
I think the android world has some of this. I think the android OS
will succeed, but the individual handsets will lack the coherence
iPhone users experience. I would like to use an android hand set
that I though would evolve over time predictably, will "just get
better" not different. Not a big deal for most mobile users, but I
know moving to a new phone is often painful.
More to the point, Google Storage, a new "invite only" storage system
like amazon's S3, looks pretty nice, but after yet another death in
the Google ecology, I'm wary. Sigh.
Its a bit hard, I think, to see a list of Google projects that are
still in beta. I was surprised to see Google Groups still there:
http://groups-beta.google.com/googlegroups/overview.html
--
glen e. p. ropella, 971-222-9095, http://agent-based-modeling.com
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
