At 11:26 AM 9/6/2007 -1000, Brian Kirsch wrote:
Well the discussion is based on Risk. Do we risk re-architecting for a long term goal at the potential expense of features, losing early adopters, and reaching the end of funding.
Well, if it's based on risk, I'd say something more like, do we risk having all our years of work fade into obscurity as it rapidly succumbs to a lack of maintenance. :)
To me, that looms as a bigger risk. I spent about 15 years on an application suite that vanished off the net shortly thereafter, and 7 years on an enterprise system that's still running 3 years later. I imagine you can guess which one I feel better about. :)
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.
Now on to what I would like to see by the end of 2008. Month View, Contacts, Printing, Rich text editing, Localizations, Cleaner UI experience, Better UI menu verbiage and tool tips, enhanced detail view experience, better Triage capabilities, and incorporation of additional feedback from the community. Can we accomplish these and do a major re-architect by the end of 2008?
The only honest answer is: "it depends". It depends on what specific features are meant under each of those things. How many localizations? Printing of what, how? (E.g., do we just want to generate PDFs using one of the Python reporting libraries?)
What features for contacts? What's an "enhanced detail view experience"? Depending on the specific definitions of those features, the answer ranges from "sure, why not!" to "are you kidding?" But of course that's true whether we refactor or not -- which is why I don't think it's a particularly fruitful path for evaluating the decision.
It's important to recognize, by the way, that refactoring doesn't mean new features stop being developed -- it just means they can't be *shipped* until the refactoring is complete. For example, there is no reason to wait until the entire app is ported to start work on implementing contacts, unless there are other pieces that have to be there first.
Again though, I want to back up and say, I'm not *advocating* this approach. If folks suddenly turn around and start being enthusiastic about it, I'm going to be the first one to start chiming in about the detailed risks and issues that *I'm* aware of. I explicitly *don't* want us to take this path if the organization isn't 100% committed to it, because if we take this path we absolutely won't be able to afford any time bickering about it along the way.
But I'm nonetheless speaking of the merits so that if the other path is taken, it will not be taken blindly. No matter which choice is made, we should know what we're giving up by *not* taking the other one, and be okay with that, as the price of what we want most.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
