February 23, 2004
By: Con Zymaris
The story thus far. Linux and Open Source are tearing up the interest charts for most IT professionals. The common question has switched from 'What is this Linux thing anyway?' to 'How do I develop a Linux and Open Source strategy for my organisation?' In an attempt to answer the latter question, others often cascade into view. Where does deploying Linux and Open Source make sense? What about the TCO and ROI story? How do I go about preparing a business case tailored to Linux? How do I develop Open Source procurement and risk mitigation guidelines? How do I plan for a Linux server or desktop deployment? Real-world questions call for real-world answers. This article is intended to deliver such answers.
Before we do that however, let's do a quick recap so that we're all on the same page. Linux, or more correctly a Linux distribution, is a combination of around 5000 Open Source software packages. Open Source software like Linux (and Apache et al) is available free of licence costs. Don't let anybody befuddle you into believing otherwise. Vendors which sell Linux solutions, such as Novell, Red Hat and Sun, package their product and sell it as a combination of physical goods and support. You pay for the physical goods and support, not Open Source software licences. Further, deploying Linux costs money for the act of deployment, but then, so does deploying proprietary software. At least with the former you save on the licence costs component of a rollout.
Let's ruminate on why we even bother to look at Linux; what's the high-level business case for even considering it? One particularly pertinent reason to look at Linux in the coming 12 months is the fact that some widely used Microsoft platforms are reaching their end-of-life points. If you have Windows NT deployed within your organisation, you will need to decide what to migrate to once support for that platform stops. Additionally, if you haven't signed up for Microsoft's Software Assurance program, upgrading to newer versions of Windows may not be economically feasible. Linux, therefore, is worth considering as a replacement platform. Specifically, Linux delivers numerous business advantages, such as:
Scalability. Linux can now scale from the smallest devices to the biggest n-way systems and mainframes, certainly more than enough to meet the needs of any Australian organisation. No other platform can give you this breadth of coverage.
Leverage. Linux is the only platform which allows you any real leverage with your vendors. It's a powerful stick that you can beat them up with when they are not behaving to your satisfaction.
Futureproof. The global platform of the 21st century will be decided by a price war of attrition between Linux/Open Source and Microsoft. Linux cannot lose in any such war. Microsoft, no matter how large its current war chest, can. Remember, most Open Source developers weren't expecting to make money from selling software anyway. Who wants to be stuck on a legacy Windows platform in 10 years' time?
ROI. Take the longer-term view, and Linux wins, everytime. When you consider the cost of migrating from Windows to Linux and it seems high, remember that you will claw back savings from every subsequent Linux platform upgrade you do. Most analysts don't go beyond the first migration when they do their sums. You should.
Now let's look at some quotes from industry sources, to further bolster our reasons to adopt a Linux/Open Source strategy.
“This shift will limit Windows' market opportunity in the data center for both its OS and its applications that run on that platform,”
(Source: Goldman Sachs: Analysis of Linux in the Enterprise, NewsFactor Network 15 Jan 2003 )
“Samba 3 runs rings around Windows Server 2003 in file serving performance. 250% faster.” (Source: ITWeek Labs: http://www.itweek.co.uk/news/1144289)
“Linux will be the dominant operating system by 2009”
(The Butler Group: Source:
http://australianit.news.com.au/articles/0,7204,5465838%5E15344%5E%5Enbv%5E15306-15321,00.html)
“Linux will emerge as the dominant operating system in corporate data centers.”
(Source: Goldman Sachs, NewsFactor Network 15 Jan 2003 )
What about fitness for Purpose? When does Linux and Open Source make sense?
The enterprise-ready 2.6 version of the Linux core (kernel) is now ready. Vendors are shipping this technology. You can use this platform anywhere were you previously used vendor-Unix or Windows, if your applications run on it. There are no limitations. Targets include database servers; edge-of-network servers; firewalls; intrusion-detection-systems; application servers (J2EE, PHP, ZOPE); web-servers; terminal servers; compute and number crunching servers; NAS, SAN; remote archiving; email servers; file-print servers, ERP, CRM and financials. Furthermore, for most organisations, between 20% and 80% of desktop PCs can be comfortably converted over to Linux too. Yes, it means that you will have more than one 'Standard Operating Environment' (SOE), but few organisations run a totally homogeneous ship anyway.
Where doesn't Linux make sense? At present, Linux doesn't make sense in the following scenarios: as the sole PC operating system for most home users; in situations where extensive use is made of heavyweight Windows-based graphics applications whose performance would suffer under emulation; on power-user workstations and laptops, as these users often run esoteric applications for which there are no Linux equivalents, or may want maximal freedom in changing their application and system settings.
We also need to look at the recent efforts from Microsoft casting some doubt about the capabilities and cost effectiveness of Linux and Open Source. Linux has become such a serious threat to Microsoft, that in recent times that the vendor has established a major effort to try and compete more effectively. Part of this effort is the 'Get the Facts' web portal. This portal cites numerous studies, mostly financed by Microsoft, aimed at convincing CIOs that Linux costs more than Microsoft and that Microsoft is more secure and reliable than Linux. Refuting these reports individually takes more space than we have here, so let's just look at what one of the proclaimed study's authors told a BusinessWeek reporter about this Microsoft-funded 'independent research', and recall that it would be judicious to hold any such research with suspicion:
“Yet even this tactic seems to be backfiring. One of the study's authors accuses Microsoft of stacking the deck. IDC analyst Dan Kusnetzky says the company selected scenarios that would inevitably be more costly using Linux.”
(Source: http://www.businessweek.com/magazine/content/03_09/b3822610_tc102.htm)
Rather than follow the Microsoft or the Linux camp on the topic of best cost containment, let's do a lightweight overview of Total Cost of Ownership (TCO) models and choose a path for ourselves. TCO is a rather fuzzy idea whose definition and application differs from one firm to another. The standard models include the cost of acquiring and integrating technology. (licences, hardware, support contracts) as well as system operational costs over a number of years years (power, network, infrastructure.), staffing costs to oversee that operation (including external consultants.) Strangely, the standard model often does not include the costs of mopping up after virus infestations and security breaches nor of system downtime.
The first point to make about Linux and TCO is don't trust anyone else's. No analyst's nor any other firm's TCO study is going to be valid for your organisation. The only way to get a realistic appraisal of what a particular solution may cost to deploy and operate is to construct your own, based on some of the templates presently available, customised to reflect the particular attributes your organisation has.
You also need to look at the costs of migrating to Linux in the first place. Whilst these costs are non-trivial for many organisations, there are also migration costs in going from one version of Windows to the next. Also, remember the additional cost of moving from Windows to Linux is a once-off; it will not have to be borne again. You will however reap the benefits of not having to pay for software assurance nor software upgrade fees in future.
What about staffing? Wont we have to re-train our IT staff to support Linux? Perhaps, but most IT professionals in Australia are now familiar with and use Linux. (source: http://www.zdnet.com.au/news/software/0,2000061733,39116120,00.htm)
Also, many organisations re-train their staff with each new Windows refresh they undertake anyway, and bootstrapping them onto Linux is a once-off process.
Before you can seriously consider any non-trivial platform migration, you need to sit down and do some longer-term strategic planning. There may be potential roadblocks on the path towards deploying Linux into your environment. Care and planning can remove these. Lets consider a few by way of example.
Problem: You have an intrinsically Microsoft-oriented application stack.
Remedy: Try and move to relying on commodity APIs and communication protocols wherever possible for any current or future application project work. This makes migration easier. Plan to write (or adopt) Web or Java based line-of-business applications as these are easy to run on Linux as well as Windows. Use Windows Terminal Services, Citrix or CrossOver Office short-term, to deploy legacy Windows applications on Linux.
Problem: Document format lock-in. Much of your data or documents can only be read by proprietary software.
Remedy: Map out a strategy of moving to an open standard XML document format for archives and perhaps live documents (Source: http://www.oasis-open.org/committees/office/)
\Also keep in mind that end-of-life migration costs do affect TCO . When you do your whole-of-life cost calculations for any product line, factor in the costs of eventually migrating away from that technology platform or application, i.e end-of-lifecycle decommissioning . Closed-platforms have a substantial cost associated with migrating away from (due to proprietary document formats, non-commodity protocols and data-lock-in.) Open platforms are just that, totally open, meaning a relatively friction-free ride from the open platform to any other platform when it comes time to migrate. This is also a strategic consideration; will the costs involved in moving away from the proprietary platform in future mean that you are forever tied to that platform, reducing your bargaining leverage with that platform's vendor? To their discredit, most organisations do not have an associated line-item cost for this in their TCO calculations.
Beyond TCO, you need to show that there is a sound business reason for this investment . How quickly can you get a return on investment (ROI) your time and money? ROI is perhaps a more useful tool as measure of the worth and efficacy of Linux projects. Take this example scenario. According to Gartner, locked-down Linux has 15% lower TCO than Windows XP and lower still than Windows 98. You can use such a figure to determine, for a certain class of user within your organisation, how quickly that organisation can save money by migrating that class of user to Linux. It might be something like 15 months for your Windows 98 users. This may be enough to justify the project to upper management.
How do you develop an Open Source risk mitigation policy? Your organisation probably already has an IT or Software Risk Management (or Mitigation) Policy. In fact, all software utilised within the organisation needs a risk policy, not just Open Source. Recently, Mark Webbink from Red Hat compiled a reasonably example which you might consider using for your organisation. Let's take a look at it.
Do not permit the uncontrolled importation of software onto company computers. Correspondingly, bar the use of proprietary software except to the extent that the company can account for the permitted licenses. If you are doing development extending Open Source software, then some effort needs to be made in licence compliance tracking. Build a catalog of (and track) all the software (and versions) your organisation is using.
There has been plenty of discussion this past year about Open Source warranties and indemnification. Open Source software generally is made available on a no-warranty and no-indemnification basis. However, you also need to be aware these constraints apply to offerings from many proprietary vendors as well. If you do want warranties and indemnification for Open Source software, then don't acquire it via download, but through a local solution provider. Ensure that this provider has indemnity and product warranty insurance to cover your organisation's risk policy requirements. Australia has several hundred such providers, some of which are listed here: http://www.osia.net.au/
So, you're going to deploy Open Source solutions within your organisation? Great. How are you going to decide what to deploy? Developing an Open Source best practice procurement guideline is relatively simple. Long-term Linux/Open Source practitioners have honed various intuitive processes for determining whether an Open Source project is worthwhile and long-term viable, so let's start with these. Locate the main repositories which list Open Source projects by user ranking, project-lifesigns and popularity. These sites include freshmeat.net and sourceforge.net. Perform all obvious due-diligence steps such as checking the short-listed Open Source projects' development activity levels; checking the user-support mailing lists; checking the support responsiveness from the developer community; talking with existing users; determining if local technical support is available from a solution provider and finally checking the project development roadmap. Most worthwhile and well-run projects have a well thought out plan for functional deliverables, timeliness and milestones. Use these to determine when to adopt such technology if features you require aren't in the current stable builds, but are on the horizon.
Moving beyond procurement, migrations to Linux and Open Source software should follow the same procedures as with any other migration or rollout, As a guide, here are some lightweight procedures to get you started. We will assume that most of the technical staff in your organisation are not Linux-savvy, so we will add extra measures to cater to their situation.
Select the first systems which will be migrated; it's often easier to start with low-key infrastructure services, such as DNS & web proxy server. Prepare a business case for the migration: what are you going to be doing; what are you trying to achieve? (better security, lower cost, etc.) Audit the existing systems you plan to change (hardware, software, protocols, network architecture, services etc.) and how they inter-operate with other systems. Specify how things will look like after a migration. Write a migration plan (both rollout and rollback) ; trial it with a test network. If you do not enough hardware on hand, consider building pilot migration scenarios using tools such as VMWare virtual machine technology to simulate a complete test-rig on a single computer. Do whatever you can do to grow the confidence of the organisation's non-Linux techs.
If all test runs look OK, then do it for real. After 3 months, measure the success against the business case baseline expectation. Present the post-migration report to management
Solicit feedback from the non-Linux techs. Ask them what they would like to try next; web-application server? Database server? Firewall? VPN? Provide background research papers and informational material. Select the next line of systems to migrate. Go back to previous paragraph and repeat.
An excellent resource on this topic is the the European Community's IDA Open Source Migration Guidelines. These suggest that before starting, have a clear understanding of the reasons to migrate; ensure that there is active support for the change from IT staff and users; make sure that there is a champion for change - the higher up in the organisation the better; build up expertise and relationships with the OSS movement; start with non critical systems; ensure that each step in the migration is manageable.
Additionally, IDA recommends that you consider the following questions for your more advanced migrations: how to ensure the interoperability of systems; how to support mobile users; how to securely identify remote users; how to build systems that are manageable; how to ensure that security is designed in from the start and not tacked on as an after thought.
It can be argued that migrating to Linux servers is an easier task than for desktops. Yet, here too, a solid business case can be made. Linux desktops deliver lower TCO than any versions of Windows (according to Gartner); future upgrade licence costs are removed; there are fewer security problems; there are facilities for better workstation lockdown and there are far fewer virus and malware problems.
Additionally, there is a perceived wisdom that migrating users to Linux desktops is just too hard a mountain to climb. This isn't reality. Due to the rapid pace of development in the Linux development world this problem has been rectified. Linux desktops deliver essentially the same form and features that Windows users expect A recently published report by Relevantive, testing two groups of new users, one on Windows XP and the other Linux, showed that the time difference taken to undertake the stipulated tasks was a mere 8%, in XP's favour. Considering that most of the users would have been experienced with previous versions of Windows, this result is a good one for Linux. More importantly, the report concluded with:
"80 percent of the Linux users believed that they needed only one week to become as competent with the new system as with their existing (presumably Windows ) one"
(Source: http://www.pcworld.com/news/article/0,aid,111871,00.asp)
Regardless of all the recent improvements in desktop Linux, unless you have a trivial site (handful of simple users) there is no simple way to undertake a desktop migration. Part of the problem is that there are more personalities ('stakeholders') involved than with server migrations. You will have to undertake any desktop migration in a planned, phased approach, which may take anywhere from 6 to 36 months, depending on your target organisation's complexity. Consider the migration a long-term strategic process that the target organisation undertakes, in a safe, gradual manner, where and when it makes sense. Ensure everyone within the organisation knows you mean this. Accept that even after several years of gradual migration, you may not be able to move the last 20% of the users off Windows.
To proceed, seek out the lowest barrier-to-migrate group within the organisation. It might be the call center. It might be admin staff. It should demonstrate specific attributes which make this group a viable migration pilot. For instance, this group will need to use applications for which there are functional equivalents within Linux and their documents, data and macros can be moved across to Linux-based applications. Post migration, this group should be able to continue to interoperate effectively with the rest of the organisation.
Here are a few tools and procedures of the desktop migration trade: massage your office suite templates so that they can be shared between Microsoft Office and OpenOffice,org. Use tools like Win4Lin and CrossOver Office to bring these users' Windows applications across to Linux (as a indicator, CrossOver Office Server Edition costs circa $5000 for 50 concurrent users. Source: http://www.codeweavers.com/site/products/cxserver/)
The desktop migration process itself is similar to the one undertaken for servers. Plan and document everything; it makes everyone less anxious. Write both rollout and rollback plans. Give timelines with plenty of time. Include a pilot phase. Select one or two keen users to trial the desktop migration on first. Provide primer training for these people. Solicit feedback from them. Pass this on to management. Discuss this feedback with the next target-group users to assuage any fears. Plan for granular phased migration; rather than change the users' whole desktop, change some of the main applications to products that run on both Windows and Linux, i.e keep their Windows desktop intact, but shift them to Mozilla (Web, Email) first, then 3 months later, to OpenOffice.org then 3 months later when there have been no insurmountable complaints, switch the underlying desktop to Linux, ensuring that the icons are all in the same place as with Windows.
As with any change which directly impacts end-users, there is resistance. Here are a few coping strategies which may help ameliorate this resistance. If an inter-departmental billing system operates, offer the department/group a yearly cost discount once they move to Linux. Offer users training and 'certification' on this new platform. Users love such accreditation. Determine how much money you would save per-desktop in the first year post-migration, and offer half of it to each and every user involved. “If you agree to an upgrade, we will give you a $500 bonus!” or “Once your system has been upgraded, you will get 2 days off as a holiday for your help in this exercise”. Another trivial-sounding inducement which has proven to be effective, is handing out Linux Tux t-shirts and caps. One reported approach taken by an IT manager in a German city who moved his desktops to Linux, was to select the organisation's manager (a woman) as the first training candidate. During a presentation, she then demonstrated to the rest of the organisation (of mostly men) just how easy this Linux thing was. Gender politics being what they are, not one of the men shirked the challenge of adopting a Linux desktop from that point on.
Regardless of what tactics you adopt or what path you decide to follow, know this. Linux is here to stay and its growth is outstripping all other platforms. Your organisation must adopt a policy on Linux and Open Source sooner or later. The technology pieces are all in place to make Linux a reality for most server work and for many desktops. The work remaining is in the procurement, policy and management sphere. Your sphere. Good luck.