zimbra development goals

[holycow]

hello.

i am currently testing out zimbra on debian, as well as looking at some alternatives like openxchange, opengroupware, and a few other projects.

QUESTION: what is the overall goal for zimbra ... are you guys tightly focused on a messaging server solution (like hula-project for example) or will you be trying to expand into the 'groupware/collaboration' and 'application server' problem domains?

the reason i ask is that as i watch a lot of these projects, i am noticing one of two things:

a) the problem the project is trying to solve is not well understood by its developers, so they start out with a scope that seems well defined like 'messaging server', but then ms exchange envy sets in and they quickly bolt on 'groupware applications' and end up reinventing their applications server.

or

b) the core developers understand that a mail frontend is just another 'application' and end up not picking an established application framework but reinventing their own (like opengroupware for example).

there are a whole other set of questions that either observation poses (namely along the lines that if either option has been chosen, it is the wrong one usually), but i'm just curious where we are starting from and what we are aiming for with zimbra.

any input on this topic would be greatly appreciated.

[Richard]

I also would like to hear Zimbra's position, and I wouldn't presume to answer for them, but

It seems to me they believe email is broken - I happen to agree. Their goal is to fix it. This means a better email server (and possibly other communication related servers) and the means to integrate with other programs via mashups (zimlets). They don't want to build the best ERP or CRM, but they do want to be able to integrate with it. This sounds focused, but with a rather broad range of possible impact. My 2 cents.

[KevinH]

Sorry I thought I replied to this already. Maybe I just forgot to hit submit in and killed off the tab.

The team here at Zimbra *knows* mail. We've been working on the problem from both a consumer and ISP point of view for years. Companies like Onebox (acquired by Openwave), Openwave, Sun, BEA, etc. We also have some of the original Java/Servlet team represented here and of course Scott (ex CTO BEA) has a good view on the enterprise space. Our investors all have invested in messaging/mail and open source for most of their careers so we are backed by people who 'get it'.

Richard's post is right on. We will start with mail and that will always be core but there are going to be some very compelling options and integrations to make enterprise messaging and collaboration better.

Happy to answer more if need be.

[holycow]

that is good to hear.

if i can make some points that you might find usefull from somenone who soon will be spending money:

- don't turn ZIMBRA into an application server. EVER. it should never become that, people should never be able to take ZIMBRA and create accounting, project management and other types of nonsense applications on it.

- instead, allow for easy integration between the ZIMBRA messaging server other application servers, where things like accounting, project management properly belong. I already noticed some posts on the boards here about extending ZIMBRA to do project management and the hair on my back immediately stood up.

there is nothing worse than hybrid (and usually proprietary) monstrosities such as AD, Exchange or Lotus Notes/Domino. keep it totaly modular and give those that need the one step ./install and your golden.

we are still investigating various solutions and it will take us some time to come to a decision but i am keenly interested in what Zimbra has to offer, especially if you guys keep your selves tightly focused on messaging.

[lfarkas]

that is good to hear.

if i can make some points that you might find usefull from somenone who soon will be spending money:

- don't turn ZIMBRA into an application server. EVER. it should never become that, people should never be able to take ZIMBRA and create accounting, project management and other types of nonsense applications on it.

- instead, allow for easy integration between the ZIMBRA messaging server other application servers, where things like accounting, project management properly belong. I already noticed some posts on the boards here about extending ZIMBRA to do project management and the hair on my back immediately stood up.

there is nothing worse than hybrid (and usually proprietary) monstrosities such as AD, Exchange or Lotus Notes/Domino. keep it totaly modular and give those that need the one step ./install and your golden.

what do you mean by zimbra server? eg. the openldap server inside zimbra is the zimbra server or ...?
what do you mean by accounting? eg. imho it'd be nice to be use zimbra admin interface to edit zimbra's openldap server's account's samba attrib too.

[holycow]

your questions indicates that you are not familiar with the categorization of various software components.

it is beyond the scope of this post for me to explain all of that, anyone that writes web "enabled" applications knows what an 'application server' and a 'framework' is.

please feel free to start another thread so that you guys can flesh out how zimbra works there.

[phoenix]

your questions indicates that you are not familiar with the categorization of various software components.

Why? Perhaps his understanding of the words you used isn't the same as yours.

it is beyond the scope of this post for me to explain all of that

Why? You could at least be courteous enough to quickly explain what you meant.

[holycow]

it's not that at all.

it's because if i start explaining my self this thread will turn into one long argument over semantics about what is a server, what isn't, etc.

but since you asked i guess we will go down this road anyway. so roughly what i mean is:

application server == something like jboss, ror, openacs, etc.

ldap == server =! application server. yes zimbra is just packaging up a bunch of servers together that do various things that gives us 'collaboration' as you will. the ldap component is not an application server but it is a server. the java application framework/server (tomcat is it?) that they are using to run the interface between the user and all the backend components is what i am referring to.

these types of projects have a nasty habit of going beyond their original scope and loosing track and focus. they usually start off with a simple calendaring app, or in these guys case to solve the messaging server issue, and then look around and want to tack on accounting (as in accpac), project management, and other nonsense applications that have no business being wedged into a a messaging server.

my hope is that, if zimbra wants our business, is to never ever stray from what they have here. instead they should work on allowing us to bridge their messaging server(s) and various application servers out there such as ror, jboss, openacs, etc. ... simply because its the right way to do it.

at least thats how we see it.