Community: A Response to Bruce Perens Re: 'What's Going On About Open-Sourcing the OpenMail Program'Mar 05, 2001, 12:21 (9 Talkback[s])
(Other stories by Cooper Stevenson)
Reader Cooper Stevenson writes:
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."