Presented at the University of Iowa Open Source Day on December 6, 2004.

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