What's Going on about Open-Sourcing the OpenMail Program?
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 five years. Five 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 four 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.
Bruce Perens is Senior Strategist for Linux and Open Source at Hewlett-Packard Corporation.
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide