Bruce Perens: What’s Going On About Open-Sourcing the OpenMail Program

Bruce Perens
Senior Strategist, Linux and Open Source
Hewlett-Packard Corporation
bruce@perens.com
Permission is granted to republish this letter in
its entirety, without alteration of the text. You may change
formatting to fit this letter in your
presentation.

There’s been a lot of talk in the Open Source community about
HP’s recently-cancelled OpenMail product. OpenMail is a server for
a few dozen different email protocols, many of them proprietary,
most of them obsolete. The most important of these protocols is
Microsoft’s MAPI (Mail API) which is used by Microsoft Outlook.
That makes OpenMail capable of serving as a replacement for
Microsoft’s Exchange Mail Server, and thus OpenMail might have been
used to serve a large network of Microsoft groupware clients with a
Linux system. OpenMail is also useful because it can support an
extremely large number of mailboxes efficiently.

OpenMail contains a lot of internal knowledge about how
Microsoft groupware works, and that’s a good reason for Open Source
people to want the program.  With it, we could more quickly
figure out how to get groupware programs like Ximian’s Evolution
working with Microsoft Outlook. Then, Linux users would work more
comfortably in environments that have already standardised on
Microsoft groupware products. It’s interesting to note that
OpenMail already uses free software in its implementation –
sendmail provides its SMTP support. So, we might not have
much trouble integrating it into our systems.

I got involved in the decision-making process for OpenMail
shortly after I joined HP in January. I was asked directly whether
we should Open Source the product. This question came from two HP
General Managers, the one for Linux and the one for OpenMail.

My recommendation was not to Open Source the product
until we were ready to throw it away, but instead to sell the
OpenMail division and continue OpenMail as a proprietary
product.

My main reason for this was that OpenMail did not benefit the
average Linux developer or user at all. That user supports
Microsoft mail clients via open protocols, and can use open
groupware products such as Evolution. Instead, OpenMail was mostly
interesting to enterprise users who needed to interface
Linux to MS Outlook and could afford to pay to support the
continued development of OpenMail. I did not feel that we could
support the OpenMail development team with an Open Source product –
licensing income would probably diminish, they were not breaking
even, and they are a very expensive group. Because they are so
expensive, it did not make sense to support the product at a loss
simply to sell more Linux systems.

My philosophy about Open Source and proprietary products is that
the two should share the market in harmony. That means there are a
few things that proprietary products should not do. Proprietary
products should not block Open Source competitors by using patents,
closed protocols, or restrictive law. Proprietary products don’t
belong in the infrastructure of free systems like Linux – they are
more appropriate as applications on those systems. Given a few
rules like that, we should be able to achieve “peaceful
co-existence”. Thus, it made sense for OpenMail to retain its
proprietary role to support Microsoft Outlook, while the Open
Source community continued to reverse-engineer Microsoft Outlook
and Exchange for purposes of compatibility.

An important point about my relationship with HP is that the
decisions I make can’t drive the company into bankruptcy. I have to
find the balance between promoting free software and making money.
Thus, I was loath to say “just give OpenMail away” until
we were ready to throw the product away. HP attempted to follow my
advice and was not able to find a buyer who would keep the team
intact.

Linux Journal author Don Marti questions whether I am
“just a pretty face” for Open Source in this matter, or whether I
have the ear of the executive team. Sometimes I wish I was
less involved with the executive team, because the
decisions that come with my job are not easy ones. I
(unfortunately) took part in killing the OpenMail division, because
I could not justify keeping the team together for an Open Source
product. So, here’s Mr. Open Source Evangelist making a decision
that causes developers to be transferred off of a product that runs
on Linux, and some of them will quit as a result, and this will not
do good things to their lives. Welcome to the realities of
interfacing Open Source and the corporation.

So, now we have announced that we’re going to make one more
OpenMail release and then support the product for 5 years. 5 years
is forever for a computer product, so OpenMail isn’t going
away for its installed base. But obviously, there is now a
legitimate desire for the product to be Open Sourced, or at least
continued as a proprietary product outside of HP.

When a company decides to release existing proprietary code as
Open Source, the show-stopper is almost always the other parties
outside of that company who are involved. Such parties
become involved through patents that have been licensed,
proprietary code that has been produced by a third party and
embedded into the product, and existing contracts relating to the
product that have been entered into with customers or other
vendors. These sorts of factors complicate the release of every
piece of Open Source software I’ve consulted on at HP so far, no
matter what division it comes from.

So, if OpenMail is released as Open Source, we will have to
first sanitise it: remove software that is connected with
non-disclosure agreements that we entered, patents that we
licensed, proprietary code that we bought but can’t relicense, and
so on. And we must make sure that the result doesn’t bring us into
violation of contracts we made with customers and vendors, such as
the agreements we made with customers when they licensed the
OpenMail product. We don’t know how big this sanitisation project
is yet, if it’s bad, it could cost Millions.

So, this should make it clear that the decision to Open Source
OpenMail isn’t a no-brainer. One of the biggest problems is: if we
spend the money ourselves, what do we not spend it on?
Many of the other projects that we might consider are of more
direct benefit to Linux, and benefit the average Linux user rather
than only the enterprise. So, if we do OpenMail as Open Source, do
we not offer Linux support for some laptop or palmtop? Do we
release fewer HP device drivers for Linux? Does a Win-Modem never
become a Lin-Modem because of this? It may not be necessary for
this to come out of HP’s Linux budget, however. Perhaps we could
get another company involved. After all, we did want to sell the
product off, and perhaps someone else could help us Open Source
it.

We have at least 4 plans for OpenMail circulating in top
management, several of which involve Open Source. It’ll take time
for this to work out, so I’m going to have to urge patience. Don’t
write HP management asking for OpenMail to be Open Sourced, they
already know, so that will only annoy them. Another thing I’ll urge
is that you don’t allow the prospect of OpenMail being released
someday to block other projects – continue the present
reverse-engineering effort and continue to develop open groupware
protocols. I’ll keep working on this for you.

Thanks

Bruce Perens