[Evolution] Re: [discuss] OO - GROUPWARE - Call for concluison - was: OpenOffice: Say it isn't so.

[Lloyd Llewellyn <lloyd001 twilight-systems com>]

> It seems that there are two sorts of consensus standards around.  A bunch of
> guys can spend a load of money in meetings hammering out an agreement -
> and then pray that /someone/ will implement their brainchild.
[...]
> Or, somebody develops a real working model and makes the interfaces publicly
> available.

I guess I'm kind of advocating both <g>.  

I think it's short-sighted by looking at groupware features in the
context of one package.  The common complaints of people moving from one
e-mail/office/groupware client to another are:

- the re-entry or import of all their old data
- being locked into one client because it's the only one that works with
your server

How is that solved by working on a solution that is focused on OO?

I do think we need to "hammer out a standard" that works for *at least
more than one* client.  I'm suggesting OO and Evo.  One is an office
suite and the other is an e-mail/organizer client, so they aren't really
interchangeable, but  it would provide important perspective to getting
an open groupware standard to work with at least more than one package.
The fact that they use different component architectures is a bonus in
this respect.  

If a couple other client developers came on board, that would be good
too.  It would give the development group feedback that helps them
balance "completeness" of a service against the flexibility that
different client developers will want to differentiate their products.


> Collaborative tools are a real requirement of today's office - and likely much
> more so tomorrow.  OO is a reasonable place for them to be "at home."

I have to disagree with you.  I think having a groupware package that is
on a peer level with OO and with Evo and other projects is important.
If it's perceived to be subordinate to any one client, it will have
little more appeal as an open, pluggable standard than Exchange or
Notes.


> Allow me a simple example.  I've complained often that I now have about five
> "address book" thingies on my machine.  None work with any of the others.  No
> two have the same content.  If I ever figure out OpenLDAP, I don't know which ones 
> will be able to use the information.  And I don't like the situation much!
[...]
> SO5.2 components have a reasonably decent interface to address information.
>
> So, suppose we publish a complete disclosure of the interface -- "these are all
> the steps to retrieving address content into a letter;" and, by the way, here 
> is a real address book implementation.


I think it would be ignored outside the OO community.  It would carry
more weight if we could say "Here is a real address book implementation.
And by the way, not only does OO support it, but so does Evolution; and
Balsa and a couple other e-mail packages have endorsed the standard and
will support it in their next release."


> Until now, I don't know of one that makes such a complete disclosure at the API
> level that it can be plugged painlessly into an existing ap.  And it is that
> type of replaceability that will make real "componentware" fly.


I think we're agreed that a pluggable standard would be the ideal, but
we differ on the route to take.  You believe a project that works with
OO is more important, but let's make the API open so others can use it.
I'm saying let's give the project stand-alone legitimacy, while still
securing the blessings of OO and Ximian, and (tentative) commitments
from them to support the standard.


Imagine being able to switch clients as easily as installing the new
software and entering the server name (which could be localhost).  The
client then discovers what open groupware services are present, and
everything is just automagically there - address book, calendar, shared
calendars, projects and task management, discussions...

Imagine being able to switch the server operating system, and groupware
implementation, or even outsourcing the groupware middle and back ends -
without the users ever even knowing it or caring.

Imagine giving employees the freedom to select the groupware front-end
that happens to work best for them, on the operating system that works
best for them, while still remaining fully integrated with everyone else
in the organization.

That's how I envision an open groupware standard - as the POP or IMAP of
groupware.