The University of Iowa replaced its proprietary webmail system with an open source alternative to reduce costs. It selected the Horde IMP project for its web application suite including email, calendar, and contacts. The implementation involved a mix of open source and existing proprietary components. While there were challenges integrating the systems and initial performance issues, the new system now supports over 24,000 active users with 3 million daily requests at a lower overall cost.

1. University of Iowa Webmail:
Planning for enterprise services based on
open source software
December 6, 2004

2. Overview
 Background
 Implementation
 Evaluation
 Conclusions
 Q&A

3. Background
 Captaris WebMail discontinued
 Follow-on product more expensive,
unnecessary features
 Primary usage:
 Traveling faculty/staff
 Home users
 Students in campus buildings
 Requirements:
 IMAP mailbox access
 Comparable features

4. Selection Process
 Selection team identified alternatives
 Hands-on evaluation where possible
 Other schools
 Products in use
 Evaluation reports
 Selected IMP from the Horde Project
http://www.horde.org/

5. Horde IMP
 Web application suite
 E-mail, contact manager, calendar,
portal, task list, notepad, etc.
 University of Pennsylvania report
http://www.upenn.edu/computing/eval/2002/webmail/
 Other schools using IMP:
 MIT
 Purdue University
 Tulane University
 University of Michigan

6. Implementation Plan
 Mix of open and closed source
 Use closed source mainly to leverage
existing infrastructure
 Minimal changes to IMP source
 Use extended testing/pilot phases
 Gradual deployment
 Batch migrate personal address books
from Captaris WebMail to IMP

7. Open Source Components
 Red Hat Enterprise Linux 3 AS
 Apache HTTP Server 1.3.x
 PHP 4.x
 Horde IMP, Turba
 up-imapproxy
 Sendmail

8. Closed Source Components
 IBM LDAP Directory Server
 Oracle Database Server
 User preferences
 Personal address books
 AIX IMAP Servers
 Microsoft Active Directory
 IBM Network Dispatcher
 Load balancing, fail-over

9. Local IMP Modifications
 LDAP directory integration
 Default display name
 Default reply-to address
 Login screen design
 After initial deployment:
 Quota display
 Outlook address book export

10. Oracle Database
Server LDAP Server
http(s)
oci8
`
POP/IMAP
Servers
(Blue)
imap
Web Servers
smtp
User
Outbound SMTP
Servers
krb5
Active Directory
Servers
Network File
Servers
nfs
Network
Dispatcher
Servers
ldap
Open Source
Closed Source

11. Hardware
 3 IBM xSeries 335 servers
 Early hardware problems
 Minimized hardware vendors (IBM
RS/6000 and pSeries AIX servers)
 Little value from vendor’s cross-
platform hardware management tools
 Greater value from existing
relationship and knowledge

12. Administration
 Highly-skilled team
 Proactively monitor critical services
using open source, vendor-neutral
tools (Spong, Cricket)
 Centralized, vendor-neutral
configuration management (depot)
 Immediately test and apply security
patches
 Review and apply other patches as
needed

13. Implementation Challenges
 Mixing open and closed source (e.g.,
PHP and Oracle)
 Sizing/scaling, impact on other
systems
 up-imapproxy in early development
 Captaris refused to release WebMail
address book structure
 Early hardware problems
 Difficulty proving hardware vs. software
problem

14. Evaluation — Current State
 3M requests/day
 24K active users
 No further hardware issues
 Some performance issues (mainly
impact on other systems, esp. NFS)

15. Success Factors
 Management support
 Preview installation
 Formal project management
 Hardware vendor relationship
 Vendor-neutral management
infrastructure already in place
 Minimal changes to source
 Gradual deployment
 In-house technical expertise

16. The Bottom Line
 Support costs:
 External costs
(licensing,
contracts, etc.)
 Internal costs (staff
time, lost
productivity)
 Commercial
software promises
to lower internal
costs in exchange
for higher external
costs Closed Source
External
Costs
Internal
Costs

17. The Bottom Line
 Reality:
Commercial
software doesn’t
always deliver
 Switch to open
source:
 Internal costs may
decrease, or
increase only
slightly
 External costs may
decrease
significantly Closed
Source
Open
Source
External
Costs
Internal
Costs

18. Benefits
 Decreased operating costs (licensing,
software support)
 Able to meet unique integration
requirements
 Easy to add, modify features
 Display Blue quotas
 Outlook address book export

19. Ongoing Challenges
 Mixing open and closed source
 Simplest when based on common
libraries and standard protocols (e.g.,
imap and ldap)
 More difficult when using closed source
libraries and proprietary protocols (e.g.,
Oracle)
 Sizing/scaling
 Planning for performance
 Predicting impact of changes to current
environment

20. Conclusions
 Significant savings possible by cutting
external licensing/support costs
 Mitigate effects on internal costs:
 Local technical support expertise
 Use proven technology (applications,
libraries, protocols)
 Minimize changes to source
 Allow learning and discovery time
 Anticipate potential risks