Hi Grant,
I'd like to talk about your first question (point A).
Grant Baillie wrote:
A) What to do when
==================
1) Don't rearchitect anything: just fix bugs, incrementally add
features, except for the ones that are impossible (I'm thinking mainly
scaling to real-world email volume), until the end of 2008.
2) Attempt to develop in parallel: i.e. have some fraction of the team
work on adding relatively low-impact and desirable features, like
scripting, printing and month view, so that there are appreciable
signs of progress for end users.
3) Bite the bullet and rearchitect (whatever that means -- see below)
now, taking the position that this way we'll be better placed to Give
Users What They Want.
I suppose you consider those 3 options as either/or choices (let's call
them A-1, A-2 and A-3). In that case, I strongly oppose A-3 for an array
of reasons but the strongest one is: why rearchitecture something if
we're not even sure there are users out there who want it? I'm sure we
can come up with a much better architecture for Chandler Desktop but,
does the world wants/needs Chandler Desktop in the first place? Another
way to ask the same question: if you had to start Chandler today from
scratch using end users requirements as input, would you develop a
multiplatform desktop app? If your answer to that question is ranging
anywhere from "no" to a lukewarm "may be", if you think for instance
that, well, a web app would do, why embark on a rearchitecture project?
OK, it may sound like I'm not convinced that a desktop app has intrinsic
properties that make it more interesting, useful and powerful than a web
app. It turns out that I *do* think desktop apps have such qualities
(beyond the easy "it works off line", I'd list privacy, freedom, power
and openess) and that Chandler Desktop should exemplify them so that
it's compelling for *users* so they'll come "en masse" to adopt it. But
what I think is of little consequence if no significant poll of users
show interest in this product and its approach.
Now, one could say that to exemplify those qualities we need to
profoundly rearchitect the code. I'd argue though that the demonstration
of such qualities to an end user is already there in Chandler Desktop as
it is today. What we need to prove is that there's a demand for that set
of qualities in a PIM. That I think brings us back to "getting users" first.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
