Choosing Open Source Solutions
Part of my job is finding and testing open sourced solutions for already prominent commercially available software. The concept is simple: If it's open sourced, it can be customized, be platform independent, and it can be free. In the business world, this poses two key benefits. Having software that can be customized means fewer problems and more functionality. Getting it for free means lower cost for the services we provide to our customers, and having more money to spend on employees and infrastructure. As simple as this sounds, finding the right fit can be a laborious task of trial and error. Part of my job is minimizing the trial and error.
Finding the right open source product is just as important as the decision to use an open source product to begin with. In every business software environment there are a few common components. There is the commercial product we've all used for years. There are the two or three popular open source alternatives, and there is a list of migration headaches we all experience that eventually becomes the list of reasons why we should stick with what worked before. Occasionally there is a product that inspires us to stay in the fight. A classic example we can all relate to is a product most of us use all day, every day: the email client.
Transitioning from the industry standard email server and its client software has its pros and cons. The obvious benefit is cost. Purchasing server software can get very expensive very quickly. This cost usually grows as your company grows. The client software is usually purchased with a per user license that will also continue to grow in costs as your company grows. Or it's purchased by site license which is often only slightly less expensive. The greatest challenges faced with open sourced alternatives are functional dependence and data migration.
The majority of office software users in general have been using the same solution suite for several years now. Shortcut keystrokes have been memorized and feature dependency has become ingrained. This becomes a real challenge for open source solutions. Often, when new solutions have been introduced to market, deployment was met with end-user opposition. When the first prevalent open source email clients were released, a few were championed as the replacement cure-all for the mainstream standard. It wasn't long before users began to learn that features they had become accustomed to were either moved and renamed, or missing all together. The lesson learned was that the economic benefits of a software package are lost on a user who cant get past how much they dislike using it.
In choosing an open source solution, often there will be the commercially available product that meets all of your needs, and the open source products that will meet most of your needs. Occasionally there will be an open source product that either matches the functionality that the end user has become dependent on, or that adds a function that makes the loss of a feature acceptable. When our company made the decision to begin using the Zimbra email server and client, two of the deciding factors were its platform independence and its migration ease. The email client is available for a wide range of operating systems, including the commercial ones. While migrating emails, folders, calendars and contacts can get a little tricky, depending on which client you are importing them from, they've all made it so far. After that, migrating an account from one machine to another (regardless of the operating system) is an absolute breeze.
When you're evaluating open sourced software you have to remember that there will always be two perspectives you have to keep in mind. If you're considering it from an IT/Management perspective, if you look hard enough, there will often be a program that meets your platform requirements, is easy to install, and is free. Doing your homework also means evaluating them from the end-user perspective. It's easy to say "they're just going to have to deal with it..." but this more often than not leads to a decrease in productivity in the least, and at worse a full fledged mutiny. Few things are more frustrating than pitching a change and then having to go back to the drawing board when what seemed like a good idea fails and requires reverting back to something you decided was worth leaving in the first place. A little expansion on the evaluation will usually lead to much less trial and error, and ultimately a better fit in the long run.
Chase Crum is the IT Infrastructure Manager for Voicenation and a self-proclaimed Linux FANATIC.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development