Roger Binns
2004-05-14 05:34:04 UTC
If you don't know what Chandler is, read the vision here:
http://www.osafoundation.org/Chandler_Compelling_Vision.htm
Remember that a vision is a target to aim at, not necessarily
current realities.
So I met with several folks from OSAF today, including Mitch Kapor.
It was very interesting for both sides, but also highlighted a
significant gulf between what BitPim does and what Chandler intends
to do, as well as the design philosophy behind both products.
Chandler is a beautiful edifice of a design. It is this large
monolith whose internal design is capable of anything (in theory)
should someone write a plug-in (which they call parcels). This
is a classic top down design. They have not yet attempted to
write code to do with synchronization with anything else, although
they will be looking at Outlook real soon. Chandler will
handle all sorts of things (such as email, contacts, groups,
acitivity logs).
BitPim is a bottom up design. The low level stuff was written
first and then the higher level added on top. Doing more things
in the future does require updates and tweaks to the internals
since they didn't have that high level design first (*). BitPim
only handles cell phone related stuff.
This means that BitPim solves some problems today, and solves them
well, whereas Chandler solves many problems tomorrow (in theory)
and will solve them well tomorrow (in theory).
The people are OSAF are amongst the most experienced, and should
ensure what implement in practise meets their what they talk about
in theory. They do also have to walk before they can run, and are
not intending to deal with cellphones (certainly not to the level
BitPim does) for the forseeable future. (Also note that software
always takes longer to develop than you expect - Chandler is no
exception.)
Mitch also believes that the cell phones will change (&). The
current model is a cable, and some crappy protocol over it
with per phone model differences. He expects phones to
have downloadable software that then does the synchronization
for you. To a certain extent that is already possible with
BREW apps (Get It Now on Verizon) or J2ME. Today in practise that
approach is also limited by other infrastructure issues
(like the carriers wanting lots of money, how much the BREW/J2ME
environment sees, what about calendars, having access to
your desktop through your firewall to sync with it etc).
I am very skeptical of that view, even though I wish it was
true. It currently takes about a year to design a phone,
3 months to FCC certify it, another 6 to 9 months for a carrier
to offer it, plus about a year before customers buy it.
Consequently there is around a 3 year lead time from a cell
phone manufacturer getting a clue, and the average customer
possessing a device with that clue in it (!).
I have also observed that people seem to treat their cellphones
in two ways. One group of people barely have any information
in it, and use the call history to call the numbers they usually
call. The other group have up to date information in the
phone (and only in the phone). They get paranoid about syncing
with desktops because when they do, the desktop apps lose information
(for example they may remove your speed dials, turn off picture
ids, re-order numbers etc). Funnily enough, all the OSAF people
were in the latter category, with various amusing anecdotes.
There is also the possibility that the cell phone manufacturers
may try to make your cell phone the central repository of
information and all other sources subservient to it.
The good news is that software is not a zero sum game (in zero sum
games, someone has to lose for someone else to win). All the various
bits of software and practises can "win" simultaneously and end users
can pick the best tools for the job at the time.
So what does this mean for BitPim? There will be no changes in
BitPim - it will continue to work really well with as many features
of the supported cell phones as possible. It will continue to
remain relevant for cell phones and not try to solve other problems.
(ie it will do one thing and do it well).
At some point in the future, the innards of Chandler as well as
external developer functionality will be sufficient to port some
functionality from BitPim to Chandler. I expect it will be quite
a bit longer before Chandler could become the user interface for
BitPim. (Both of these will be measured in years).
My own prediction is that our cell phones will continue to be
islands of accurate information, and that BitPim will be the
only piece of software that does a good job with all their
features for the phones it supports (#).
Both BitPim and Chandler are Open Source, and even appear to
be the same license. That means that developers with time
can change the course of both. I won't be committing my own time
to BitPim - Chandler interoperability for the forseeable future
(unless someone pays me and I am available to do so
I also think Chandler is going to get bitten a few times
due to their top down design. That is why I offered my
hard learned lessons to them, although they weren't yet
ready for the real low level details.(+)
I do think it is going to be an interesting next few years,
and I think end users will continue to benefit from choice.
Just remember to tell the vendors why you did or didn't buy
products, and remind them that ultimately they are there to
serve you.
Notes:
(*) That also turns out to be the Microsoft strategy. Release
a less capable product sooner, and do several versions
while those trying to make a perfect initial product find
it irrelevant by the time they release. It also explains
why each version of Word had to have a new file format It
also coincides with the open source maxim "release early
and release often". This strategy typically leads to
far greater product takeup and closer matching of user
needs
(&) That is a typical software person's attitude. They usually
don't understand that hardware companies consider software a
necessary evil and try to have as little of it as possible.
They generally see no gain through their software, and making
it better would just delay time to market and increase
development costs.
(!) Those are the figures for Verizon as far as I can tell. I
don't think they are too different for other companies.
(#) The one curve ball is a network effect:
http://en.wikipedia.org/wiki/Network_effect
If people start demanding phones that sync with Chandler, that
could cause a rapid increase in the uptake of Chandler, and the
number of phones that do syncing with it. I think Mitch has
some expectation of this happening. We already see a mild
version of it with some people not buying phones unless
BitPim work with them.
(+) They also expect 3rd party developers to contribute a lot, and
that is how they expect the phone problem to be solved.
However the innards of Chandler will limit the exact information
that can be stored, what extra information means, and how other
plugins display them. That has chicken and egg effect -
developers won't bother with something that isn't popular, and
the people won't bother with something that doesn't have all
the features.
Bonus:
Here are some relevant articles by Joel Spolsky. He talks about
software platforms, good software, chicken and egg issues,
design and architecture. I certainly have my own thoughts about
the future, some of which I mention above. These should help
you with yours. Just remember that it is not a zero sum game
unless people have to pay money (as they won't be likely to
spend money twice to get the same thing).
Good Software Takes Ten Years. Get Used To it.
http://www.joelonsoftware.com/articles/fog0000000017.html
Chickens and eggs, software platforms:
http://www.joelonsoftware.com/articles/fog0000000054.html
Building communities with software
http://www.joelonsoftware.com/articles/BuildingCommunitieswithSo.html
How hard it is to make software platforms successful
http://www.joelonsoftware.com/articles/Platforms.html
Open source as a business strategy
http://www.joelonsoftware.com/articles/StrategyLetterV.html
You have to design before you implement
http://www.joelonsoftware.com/articles/NothingIsSimple.html
Don't Let Architecture Astronauts Scare You
http://www.joelonsoftware.com/articles/fog0000000018.html
The best way to eliminate people's objections to switching to your
product is to make it easy to switch back.
http://www.joelonsoftware.com/articles/fog0000000052.html
And a bonus from Jakob Nielsen in mid-2000 about WAP. It shows that
cell carriers didn't get it then, and still don't get it. Do you
think they will suddenly get contact synchronisation?
http://www.useit.com/alertbox/20000709.html
Roger
http://www.osafoundation.org/Chandler_Compelling_Vision.htm
Remember that a vision is a target to aim at, not necessarily
current realities.
So I met with several folks from OSAF today, including Mitch Kapor.
It was very interesting for both sides, but also highlighted a
significant gulf between what BitPim does and what Chandler intends
to do, as well as the design philosophy behind both products.
Chandler is a beautiful edifice of a design. It is this large
monolith whose internal design is capable of anything (in theory)
should someone write a plug-in (which they call parcels). This
is a classic top down design. They have not yet attempted to
write code to do with synchronization with anything else, although
they will be looking at Outlook real soon. Chandler will
handle all sorts of things (such as email, contacts, groups,
acitivity logs).
BitPim is a bottom up design. The low level stuff was written
first and then the higher level added on top. Doing more things
in the future does require updates and tweaks to the internals
since they didn't have that high level design first (*). BitPim
only handles cell phone related stuff.
This means that BitPim solves some problems today, and solves them
well, whereas Chandler solves many problems tomorrow (in theory)
and will solve them well tomorrow (in theory).
The people are OSAF are amongst the most experienced, and should
ensure what implement in practise meets their what they talk about
in theory. They do also have to walk before they can run, and are
not intending to deal with cellphones (certainly not to the level
BitPim does) for the forseeable future. (Also note that software
always takes longer to develop than you expect - Chandler is no
exception.)
Mitch also believes that the cell phones will change (&). The
current model is a cable, and some crappy protocol over it
with per phone model differences. He expects phones to
have downloadable software that then does the synchronization
for you. To a certain extent that is already possible with
BREW apps (Get It Now on Verizon) or J2ME. Today in practise that
approach is also limited by other infrastructure issues
(like the carriers wanting lots of money, how much the BREW/J2ME
environment sees, what about calendars, having access to
your desktop through your firewall to sync with it etc).
I am very skeptical of that view, even though I wish it was
true. It currently takes about a year to design a phone,
3 months to FCC certify it, another 6 to 9 months for a carrier
to offer it, plus about a year before customers buy it.
Consequently there is around a 3 year lead time from a cell
phone manufacturer getting a clue, and the average customer
possessing a device with that clue in it (!).
I have also observed that people seem to treat their cellphones
in two ways. One group of people barely have any information
in it, and use the call history to call the numbers they usually
call. The other group have up to date information in the
phone (and only in the phone). They get paranoid about syncing
with desktops because when they do, the desktop apps lose information
(for example they may remove your speed dials, turn off picture
ids, re-order numbers etc). Funnily enough, all the OSAF people
were in the latter category, with various amusing anecdotes.
There is also the possibility that the cell phone manufacturers
may try to make your cell phone the central repository of
information and all other sources subservient to it.
The good news is that software is not a zero sum game (in zero sum
games, someone has to lose for someone else to win). All the various
bits of software and practises can "win" simultaneously and end users
can pick the best tools for the job at the time.
So what does this mean for BitPim? There will be no changes in
BitPim - it will continue to work really well with as many features
of the supported cell phones as possible. It will continue to
remain relevant for cell phones and not try to solve other problems.
(ie it will do one thing and do it well).
At some point in the future, the innards of Chandler as well as
external developer functionality will be sufficient to port some
functionality from BitPim to Chandler. I expect it will be quite
a bit longer before Chandler could become the user interface for
BitPim. (Both of these will be measured in years).
My own prediction is that our cell phones will continue to be
islands of accurate information, and that BitPim will be the
only piece of software that does a good job with all their
features for the phones it supports (#).
Both BitPim and Chandler are Open Source, and even appear to
be the same license. That means that developers with time
can change the course of both. I won't be committing my own time
to BitPim - Chandler interoperability for the forseeable future
(unless someone pays me and I am available to do so
I also think Chandler is going to get bitten a few times
due to their top down design. That is why I offered my
hard learned lessons to them, although they weren't yet
ready for the real low level details.(+)
I do think it is going to be an interesting next few years,
and I think end users will continue to benefit from choice.
Just remember to tell the vendors why you did or didn't buy
products, and remind them that ultimately they are there to
serve you.
Notes:
(*) That also turns out to be the Microsoft strategy. Release
a less capable product sooner, and do several versions
while those trying to make a perfect initial product find
it irrelevant by the time they release. It also explains
why each version of Word had to have a new file format It
also coincides with the open source maxim "release early
and release often". This strategy typically leads to
far greater product takeup and closer matching of user
needs
(&) That is a typical software person's attitude. They usually
don't understand that hardware companies consider software a
necessary evil and try to have as little of it as possible.
They generally see no gain through their software, and making
it better would just delay time to market and increase
development costs.
(!) Those are the figures for Verizon as far as I can tell. I
don't think they are too different for other companies.
(#) The one curve ball is a network effect:
http://en.wikipedia.org/wiki/Network_effect
If people start demanding phones that sync with Chandler, that
could cause a rapid increase in the uptake of Chandler, and the
number of phones that do syncing with it. I think Mitch has
some expectation of this happening. We already see a mild
version of it with some people not buying phones unless
BitPim work with them.
(+) They also expect 3rd party developers to contribute a lot, and
that is how they expect the phone problem to be solved.
However the innards of Chandler will limit the exact information
that can be stored, what extra information means, and how other
plugins display them. That has chicken and egg effect -
developers won't bother with something that isn't popular, and
the people won't bother with something that doesn't have all
the features.
Bonus:
Here are some relevant articles by Joel Spolsky. He talks about
software platforms, good software, chicken and egg issues,
design and architecture. I certainly have my own thoughts about
the future, some of which I mention above. These should help
you with yours. Just remember that it is not a zero sum game
unless people have to pay money (as they won't be likely to
spend money twice to get the same thing).
Good Software Takes Ten Years. Get Used To it.
http://www.joelonsoftware.com/articles/fog0000000017.html
Chickens and eggs, software platforms:
http://www.joelonsoftware.com/articles/fog0000000054.html
Building communities with software
http://www.joelonsoftware.com/articles/BuildingCommunitieswithSo.html
How hard it is to make software platforms successful
http://www.joelonsoftware.com/articles/Platforms.html
Open source as a business strategy
http://www.joelonsoftware.com/articles/StrategyLetterV.html
You have to design before you implement
http://www.joelonsoftware.com/articles/NothingIsSimple.html
Don't Let Architecture Astronauts Scare You
http://www.joelonsoftware.com/articles/fog0000000018.html
The best way to eliminate people's objections to switching to your
product is to make it easy to switch back.
http://www.joelonsoftware.com/articles/fog0000000052.html
And a bonus from Jakob Nielsen in mid-2000 about WAP. It shows that
cell carriers didn't get it then, and still don't get it. Do you
think they will suddenly get contact synchronisation?
http://www.useit.com/alertbox/20000709.html
Roger