I'd like to examine the PC-mobile synch solution vs. the networked
standalone mobile client solution in terms of both (1) user numbers and
(2) vision. The appeal to user numbers is related to the argument that
some people can't use Chandler unless we provide a mobile synch
solution.
1a). How many users MUST have PC-mobile synch from Chandler before
they can adopt Chandler?
From the community of people who would totally use Chandler if it only
had a synch solution:
- Subtract those that don't have a device, or don't bother with a
calendar on their device.
- Subtract those that do have a device but it's just not a killer
feature for them -- they can use Chandler without it.
- Subtract those that don't have the discipline to manually synch
frequently enough for this to be useful (I'm one of these)
- Subtract those who use a device that is not compliant with the
standards for synching calendar data
Oops, that leaves nobody -- because the standards compliance for
PC-mobile synch is a really bad situation and I bet if we were total
sticklers we could rule out every device out there :) No seriously, I
don't want to engage in sophistry, but to make a point about how hard
it is to target a lot of devices with one synch solution (remember the
guy who gave a presentation about the extreme fragmentation in the
contact info synch implementations? I bet it's worse in calendaring).
So what if we do a synch solution for the Nokia 6160? Nevermind the
fact that this phone will be obsolete by the time we are done, in the
best case this handles only a few users. No, it's better for Nokia to
provide its "Phone Duplicator" software for each model they produce and
they can work out their own kinks.
So the best we could do would be to target a few models that used
mostly similar technology to synch, so rephrase that last "subtract"
to:
- Subtract those who use the wrong device -- one not supporting synch,
or only doing proprietary synch, or just too buggy, or not the models
we target.
How many are left? Remember we're *starting from* the population of
people who would otherwise adopt Chandler, and that just isn't big yet
(when we get to Firefox-millions of users, it could be a different
equation.) So it's even less of not much.
1b) How many users would become able to use Chandler if their mobile
could synch directly to a calendaring server?
Well, the question can't quite be asked the same way. In the most
limited sense, somebody who had a networked device that had any
software (not just the software we provide) that could talk to their
calendar server -- they would then be able to use Chandler without
being cut off from their calendar when they only had their mobile
device around. In a broader sense, the *total users* of a networked
mobile client could be significantly bigger, including people who can't
or won't use Chandler for other reasons.
1c) So which approach wins in terms of gaining users?
It's not clear. I don't know if we can pick on that basis -- first we'd
have to decide whether we were trying to get users period, or
specifically increased users of Chandler. Then we'd have to decide if
the numbers made it worthwhile doing any work. I suspect that either
approach won't make much of a dent in the size of the user base of
Chandler and it's a lot of work for not much difference.
2. Which approach has the best "vision thing"?
The networked mobile client could potentially do a bunch of things a
synch solution can't:
- Synch anywhere there's a connection, and *never* require you to plug
in the cradle.
- Synchronize your spouse's and boss's calendars (CalDAV allows this
-- synch operations don't).
- Work with more than one data source -- your org's calendar server
and that of your social club
- Allow you to browse a calendar online -- even one not normally
synched
- Send invitations real-time.
- Work with more than just Chandler -- work with any calendaring
server supporting the required standard, possibly RSS and/or hCalendar
as well as CalDAV
Even if we had a networked mobile client for one platform only
(possibly Palm/WinCE), this could lead the way for mobile vendors and
mobile software providers to follow. It's much more exciting to me and
some others. We can't have an absolute winner on the "vision thing"
without recourse to a dictator on the vision but I think there's a fair
argument that the networked client is cooler even if it's not an
immediately practical solution for everybody.
3. So what are we doing?
Arguments aside, the current plan is NOT to work on PC-mobile synch in
0.7, but to continue to explore a standalone networked mobile client
project. Mitch and I reconsidered that plan in the light of recent
comments on the list but did not change the current plan.
My input here is intended to explain how we're thinking about it,
comments still welcome as always. Serious suggestions about what we
attempt should involve considerations of real chances of success and
cost of investment :)
(FYI, I'd previously explored some of this at:
http://wiki.osafoundation.org/bin/view/Journal/LisaDusseault20050810,
so that's a fine place for comments or a starting point to build a
better document on the topic)
Lisa
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
