10 considerations for maintaining open source in your organization

Print Friendly, PDF & Email
Rate this post

At the Open Source Business Conference (OSBC) this year I did a presentation called “Asking the hard questions about open source software.” Last week I expanded on one of the areas and discussed it in the blog entry “10 elements of open source governance in your organization.”

Today I want to talk about maintaining open source once you’ve brought it into your IT infrastructure. Here’s the slide I used at OSBC:

Who will maintain your installation of the software?

  • If you are planning for your IT staff to install and maintain your software, make sure it doesn’t get orphaned when you have personnel turnover.
  • When software updates come along, you will need a plan to decide which ones to install and when, especially if major releases come along every six months or so.
  • If you customize open source code for your organization, are you prepared to propagate those changes into newer versions of the code?

So you’ve decided to use some open source code in your organization, company, or enterprise. What’s the same or different about maintaining open source versus traditional software. Here are ten things to consider:

  1. The term “maintenance” can be considered one component of “subscription, support, and maintenance” or it can be used more generally to mean “now that’ve I’ve installed this software, how do I make it do what I want, patched, and updated?”.
  2. When you outsource your datacenter, you pay to have others manage and maintain your hardware, software, data, network, and so forth. When you do it yourself, obviously you are responsible for keeping everything running correctly. You need to ensure that your staff has the skills and the resources to keep your systems going 24/7 or at least as much as you need them. For open source, they need the skills to keep the software running and they need to know where to look or who to call when there is something they cannot handle.
  3. You probably use more open source software than you realize. Many software products from IBM, for example, include open source code from Apache, Eclipse, and other projects. Your maintenance plan for this software can therefore come from your software vendor, if that is your common practice. It’s business as usual.
  4. Similarly, if you have obtained a “pure” open source “product” from a commercial company such as Red Hat, Novell, or SugarCRM, you can purchase a subscription, support, and maintenance contract from them. Partners of such open source companies may also distribute and provide first or second line support. Make sure you know exactly what you are getting and from whom.
  5. “Open source software” is often too simple a phrase to describe the range of what it means. For example, it is much easier to maintain a straightforward 1000 line piece of open source code than a multimillion line project with many installation options and configuration settings. Therefore you need to understand the quality and complexity of the code you are thinking of maintaining for your organization. It might be trivial or it might be impossible for you to do it yourself. The word “impossible” should not be used near the phrase “mission critical.”
  6. If you bring software into your organization and then make significant changes to it, do you expect someone else to be able to fix it when something goes wrong? I discussed this earlier in the blog entry “On highly customizing that open source code.” Let me summarize by saying you should either 1) not make massive changes, or 2) if you do, contribute them back to the community so that your modifications (presumably improvements?) get incorporated into the project. It will make it easier for you to use newer versions and others will benefit from your work, just as you benefited from theirs.
  7. Be honest about your organization’s ability to maintain the code yourself. If you have the right people with the right skills, it could be a real win for you. If you don’t, or your people don’t have the ability to fix everything necessary, it could be a disaster.
  8. Your people may have the skills today, but will those people work for you tomorrow? Invest in training and pay attention to ensuring continuity of your ability to maintain the software.
  9. For some software, many questions about installation and maintenance can be resolved with a good search engine. Before you install the software, try some searches to learn of others’ experience with it and how easily they got problems resolved.
  10. Look at the forums at the websites from which you are obtaining the software. Are they vibrant? Do questions get answered or is most of the time spent in flaming “noobs”? It’s a bad sign if relatively simple questions just sit there with no one responding to them. Conversely, if the community is really driven to help people start and keep using the software, the project has great documentation, and, most important, the software is well architected and mostly bug-free, your comfort level in maintaining it yourself should be higher.

Let me summarize: know the scale and complexity of the open source software you plan to use; don’t get in over your head on maintaining mission critical, enterprise software; your least expensive option may be to pay for a maintenance contract from someone who deals with the software all day long, every day; and only maintain software yourself when it comes from helpful, dynamic communities that produce great code.


The Whole Series