[Process] Re: [Design] OSAF process mailing list

Umm, so are we allowed to disagree with Mitch? ;-)

I think that Chandler does have a legacy in the form of Mozilla's Mail
component, Outlook Express, Eudora, and other existing Mail Clients (not to
mention Outlook itself) that end up setting 70% or more of the features in
stone. Additionally, there's a quite of bit of interoperability to worry about
and general messaging standards to adhere to that force a bunch of other
implementation issues.

In the end it's going to end up being some UI niceties, iCard and iCal
integration, and the plain unencumbered Open Sourceness of Chandler that will
set it apart. If the "product" is going to compete with Outlook, it's going to
have to be an awful lot like Outlook, and excel in lots of ways as well (like
doing what Outlook can do without requiring Exchange, etc.). That's a huge
legacy burden, even if there hasn't yet been a line of code written.

In my opinion it isn't just Outlook, but the combination of Outlook and
Exchange that is the actual competition here, so however Chandler develops,
there's going to be the need for some server side component to "ride along"
with an IMAP4 server to add the server side capabilities that IMAP lacks.

-dw

b.t.w. I've noticed a bunch of discussion about Ecco, which is cool as a
history lesson, but doesn't seem like a good idea to emulate, since Ecco failed
as a product due to a complexity level the 99% of users couldn't master. In
fact I'd use it as an example of what not to do (at lease UI wise), unless, of
course, we want to have people use their Mensa ID numbers as the software
activation key ;-)

Mitch Kapor wrote:

> OSAF's process mailing list is a place to discuss the 'what' and 'how' of
> the community infrastructure for OSAF.  The first subject under discussion
> is a continuation of multiple threads from the OSAF design list about how
> best to gather and synthesize community input on the design of Chandler.
>
> Presently we are looking at examples of how other open source projects
> manage new ideas and proposals.  One difference between established
> projects and OSAF is that Chandler is still vaporware.  There is no
> software artifact such as Zope or Python which the community already knows
> and uses that is the basis of a shared understanding of the current state
> of affaris.  One of our needs is to create an evolving document (probably a
> wiki of some kind) which represents the current state of thinking, both
> internally and externally, across the spectrum of design issues.  Anther
> need which we share with other projects is to have a way for new ideas to
> be raised, discussed, and acted upon.  Part of this story has to do with
> the tools which are used to facilitate the process.  Another part has to do
> with the particular roles people play with respect to decision making.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design