I wonder if this is too stark a way to frame the situation.
I think we all want Chandler-the-code to be easy to maintain.
*And* we all want to have users for Chandler-the-product so that
Chandler-the-code will be worth maintaining.
(I think the concern people have is that without a real user-base, no
one will bother to maintain / add onto Chandler, even if it's the
easiest code to work with in the world.)
The question in my mind is more: How should we balance rearchitecture
with user-driven improvements to Chandler-the-product?
I'm about to post a response to this thread on the design list which
hopefully addresses this very issue. Looking at the bug list,
deferred feature list and user feedback, I'm not sure we need to
decide between users (features) and code (rearchitecture). I'm hoping
we can be responsive to users with a 'FIX WHAT'S BROKEN' approach and
defer major feature work until after 1.0. Anyway, I will leave you to
read the design list email for a more coherent framing.
Mimi
On Sep 6, 2007, at 4:20 PM, Phillip J. Eby wrote:
That having been said, I don't have as much invested in Chandler as
I did in either of those projects. The first I was a minority
shareholder in the company, and for the second I was creator/auteur
and project manager. On Chandler I'm just "hired help", so it's
not my money and it's not my vision. But I'd *still* like to see
it around 5 years from now, and from that perspective I don't see
the end-of-'08 functional requirements being nearly as important as
non-functional requirements like performance and maintainability.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
