Community: A Response to Bruce Perens Re: ‘What’s Going On About Open-Sourcing the OpenMail Program’

Reader Cooper
Stevenson writes:

Dear Bruce;

I read with care your Linux Today article regarding OpenMail.
You expressed some of the difficulties your corporation faced when
it struggled with whether or not to release OpenMail to the Open
Source community. You cited specific examples such as diminishing
licensing revenue and third party non-disclosure agreements as
inhibitors for releasing the code.

I empathize with your position. Clearly, your work with the
Debian project leaves me with no doubt that you are truly committed
to Open Source. At the same time, you work for a company whose
primary focus is increasing revenue for its investors. All things
considered, I appreciate your stepping forward and giving the Open
Source community an insight into HP’s decision. Keep it up!

As a Unix administrator, I administer (among others) three HP
machines for a Fortune 1000 company. It is from this viewpoint, the
enterprise customer, that I make my position known.

You suggest in your article that the main reason for not
releasing OpenMail was that it did not “benefit the end user at
all.” While I agree with you to a certain degree I think it’s
important that we not lose our perspective here. MAPI is a server
protocol. The client is not the issue from the get-go. This is
important after all, because one of your core businesses is in
servers. While making the decision to release a product, it is the
IT manager’s “mind-share” you are after, not the end user’s. Using
the potential benefits to the end-user in regards to a discussion
about messaging protocols is analogous to saying that you don’t
want to release an airplane design to airplane mechanics because it
doesn’t help motorists at all. In the end, opening the product will
not help you only to sell more Linux machines but also more HP
servers because the Enterprise is not paying high Outlook and
Exchange licensing fees. Enterprises have zero-sum issues to
contend with too.

Beyond this, we face the “nuts-and-bolts” issue of sanitizing
the code from third party involvement. You indicated that you could
not find a buyer who would keep the team intact. I find this a
little disingenuous as some of the team is quitting anyway. While
we are on the subject, how much checking has your company made to
see if some of the third parties are willing to reconsider?

Finally, I would like to give you a modern administrator’s
perspective on this issue. I am referring to the generation that
started their career during the “wild west” days of the PC era. The
ones who were first technicians/network administrators for
Microsoft networks before they “wised up” and moved to the Unix
platform.

We are acutely aware of what it is like to be locked in a
vendor. We rolled our eyes as we watched our bosses fall victim to
the “nobody got fired for buying [insert company name here]”
syndrome. We can smell a proprietary product a mile away perform an
“about-face” when we do. Many of us were burned by having to walk
into our boss’s office and tell him that the application
modifications he requested were basically impossible because the
vendor did not support the product. They were also unwilling to
release the source code. And oh, by the way, it was a product that
he (our boss) chose.

To you Bruce I say that your company sells a great product.
Their reliability in my experience is top notch. However, I urge
your continued work to release this. If your company is not willing
to release certain key technologies, then my reply to my employer’s
vendor lock-in avoidance questions will be the word
“e-machine.”

Best Regards,

Cooper Stevenson