Slashdot Mirror
Can We Finally Ditch Exchange?
"With new releases on the way, like Mandrake 9.0 and the new Lycoris can we who try to use Free Software in business environments hope for any change? Do the commercial Linux distros have any plans to implement a free replacement for Exchange, including a Win32 client-side bridge? If not, why not? Do you feel it is too cost prohibitive to imitate Bynari in this case, or is it a decision more along the lines of 'we'd rather you used Evolution and Mandrake/Lycoris/Whatever, rather than OutLook and Win32'? If it's the latter I'd be severely disappointed, and I don't think I'm alone. Any discussion on this topic would be appreciated; but what I'd really love is a community push to get this done. Perhaps a running Web-A-Thon to raise the money to simply purchase the technology from Bynari? I personally think it would be a great move towards grabbing market share from some of the other distributions, some of which have the technology but choose to keep it closed, as well as from the Great Dragon. What do you think?"
Formerly HP's Openmail is another Exchange replacement, but exactly like Bynari's product it still requires some licensing.
I've been surprised that there hasn't been more effort on the Linux side of things to create a replacement. I would have thought that Redhat would have come up with something. Since as the poster notes, Exchange functionality tends to be a big killer whenever you flirt with replacing in house systems. If you can't provide the integrated and shared calendaring it usually won't fly.
Give me a product, open source or not, that provides my clients (on whose interests I act) with the functionality of Exchange, and I'll get the Purchase Order ready by close of business today.
How about Centrinty FirstClass? Cross platform unified messaging and groupware. I can access my email, voicemail, calendar, contacts from any computer anywhere in the world at a fraction of the cost of Exchange. Don't laugh, it works!
It isn't free or open source...
.conf files, I might add, no GUI necessary). My users can run Outlook (with full Public Folders and shared calendar support), or any old IMAP client.
Ah, that's true, but a lot of people (like me) turn to it when the PHB's demand things like painless group calendaring. HP Openmail (Samsung Contact) is a product that does what the execs need for the company, yet runs on my *nix boxen, so I don't have to drop an Exchange server onto my network.
I've run HP Openmail for the last two years or so, and it's been as flawless as I can expect. Very flexible, configurable (all by CLI and
HP will support the product until 2006, so I have lots of time to wait for Samsung to get their act together with Contact. They're still sort of fumbling about, last time I stopped by their website. They've had a support rep contact me a few times about the switchover process, but he's not a tech guy, and just keeps telling me to be patient, which is fine with me. Detailed migration help is on the way.
So the short answer is that Openmail/Contact fills a niche that no free software does yet. People that need a mature and complex messaging backend (more than just an MTA), but don't care much for Exchange will love it.
Belloc
I got more rhymes than Jamaica got Mangoes.
I've been trying to do this for a couple of years. I wrote the Exchange Server Replacement HOWTO back in '99 when it looked like this might be possible very soon.
Essentially I talked about how to get IMAP/POP3/SMTP with a global Address Book and authentication and user accounts via LDAP. I've been watching this space with a lot of interest since then. The lack of updates to the HOWTO should give you some idea of what's changed, not much.
As far as calendaring goes, here's the skinny: CAP is the current IETF draft, and has been for some time, although when it will be finalized is anybody's guess. Why aren't there any shared calendaring servers? Cause there's no shared calendaring standard. You can get asynchronous calendaring in IMAP by having a decent IMAP client and using a Calendar folder, but that's hardly as feature rich as Outlook/Exchange. libical has kept up with the draft but has no server process. It's used in Evolution and the Mozilla Calendar client. So we have calendaring on the client side, but nothing on the server side. From what I've been able to discern, nobody wants to write a CAP based server till CAP is finalized, since it's gone through too many changes during the drafting process already.
The other problem is the outlook clients. The way Bynari and OpenMail (Contact) have gotten around the proprietary Exchange RPC call stuff, is to write a MAPI driver for Outlook that intercepts the client calls and sends them to the server in whatever proprietary method they might have. Integrating Outlook clients will either require a server side project on the level of Samba or a client side MAPI replacement that uses CAP, unless M$ has a change of heart and decides to support it.
In order to replace the functionality of Exchange you would need, a Calendar Server (none exists in the Open Source world), a searchable document share (WebDav on Apache can't index M$Office documents AFAIK), searchable email w/ public folders and mailing lists (Cyrus + majordomo or Sympa could feasibly work), a global address book (OpenLDAP).
Now,the real kicker, it has to all be integrated, single point of management and have a web interface for users to boot. There are a million and one PHP/Perl based web interfaces to one piece of this or another. However, trying to integrate all of this is impossible. Why?
For starters, everyone seems to want to do LAMP, as if these apps all live alone and users want to log into a seperate web interface for each function then cut and paste data between web pages and not be able to search everything as one data repository, if they can search at all.
LDAP has been available for years, and the guys at OpenLDAP have been there to solve a lot of these problems for years. Quit using an RDBMS for everything, for data that applications should share, use LDAP, stuff like authentication and application user information. LDAP has seemingly been ignored by a lot of open source programmers. Evolution's LDAP support has flat out been broken, everytime I've tried it. Mozilla's works but lacks some functionality. Granted LDAP takes about as much knowledge as learning an RDBMS to understand, but ther are currently about 3 decent LDAP management tools (lape, Directory Administrator and GQ). With LDAP you can essentially have a database schema that all apps can program to, cause it's standardized (inetOrgPerson, etc.)
Other apps seem to be developed without a thought to integrating with other apps. I tried to integrate Sympa, OpenCA, cyrus, sendmail and OpenLDAP with a custom web front end about a year ago. I paid the salaries of myself and 2 other developers for about 8 months, trying to do this. It was a failure, especially in the cases of the Perl pieces. The CPAN Perl libraries didn't do LDAPv3 extensions, isolating code in most of these projects to use a different front end was hopeless and providing an interface to manage the configuration files for the servers was a lot of work. We got about 80% done before I sold the company (and codebase). We had originally planned to GPL our work then sell support and customization, with a calendaring solution and MAPI driver for outlook in the 2.0 feature set.
Most of the frustration we had and was due to using other people's code that was not extensible or modularized. If I had to do it over again, I'd do it in Java on JBoss (esp considering the BEEP servlets JSR for CAP and the great LDAP support via JNDI).
I don't think that developer's of various open source projects need to have some overreaching design group (a la GNOME or KDE) to implement these projects with integration in mind. There are plenty of standards already out there. It just takes some good design and up front research (something I've done a lot of) and thinking about how other developers and users might want to use this stuff for their projects.
Now, I don't want to sound like I'm whining about my own failures, I should have made sure we had enough capital to do it all from scratch. I'm more concerned about our ability to compete with the Exchange servers and Lotus Notes of the world and have a stable, customizable platform that we own. Quit rewriting the same stuff over and over and build new stuff... innovate, be creative, push the industry forward.
There is a glimmer of hope, the Open Source Java community is doing fantastic stuff. I've never seen more modularization, code reuse, integration and faster development in any environment or community. JBoss really takes the lead, the feature list is amazing and I've used it in several corporate environments where it beat out commercial J2EE app servers. JBoss pulls from Ant, XDoclet, Jetty, Tomcat, JacORB, Axis, HyperSonic SQL and a bunch of other projects. Struts and the Java commons and taglib projects at Jakarta are another example of really cool work.
The point is, it all works together. End users don't care if you wrote it in Perl, PHP, Python, C or Java... Just that it makes their lives easier, if we want Open Source to get more places we have to make sure we can deliver on this. Considering most of us make a living programming, supporting or administering networked systems, which would you rather have, propietary crap or really good open source stuff? So next time your designing that project, or writing some more code think about how you can make integration easier. Documentation helps too... we shouldn't have to know fifteen languages and countless codebases to get stuff working together. Most of us specialize in a couple of things.
Well, that's been my experience and is currently my struggle, so hope you get something out of this... BTW, I'd loved to be proved wrong on any pessimism I may currently have.
Arrogance is Confidence which lacks integrity. -- me