Approaching the Linux Desktop

Novell Linux Desktop Cool Solutions Article

by The Novell Solution Creation and Marketing - Linux Team

November 17 2004

Table of Contents

• Introduction
• Evaluating Enterprise-Readiness

  Analyze the organizational structure of your enterprise

  Evaluate and prioritize selected environments

  Evaluate application alternatives

  Is there a Linux version of the existing application?

  If not, is there a comparable Linux alternative?

  If neither, is there another viable option?

  Evaluate Linux desktop distributions

  Create a road map for Linux desktop adoption

  Putting a plan together

• Conclusion
• Additional Reading

Approaching the Linux Desktop: Enterprise Ready or Not?

Introduction

Is Linux* enterprise ready? Does this sound familiar? We've been asking the same question about Linux for almost a decade.

When Linux first started making its way into the enterprise as early as 1997, many organizations and market analysts were skeptical. They watched as early adopters made the move. Google (1998) created its own Linux distribution to run its search engine-the core of the Google enterprise-in a 4,000 PC-node cluster (currently up to 100,000+ servers). Burlington Coat Factory (1999) began with 1,000 Linux PCs and now has 7,000 across 350 stores. Other early adopters included the United States Postal Service, Amazon.com, Morgan Stanley, and Siemens Business Services.

Where Linux was once relegated to supporting the edge of the network (DNS, FTP, file, print, and Web servers), it is increasingly used to support mission-critical applications. Now that Linux is receiving such positive mainstream attention, chances are good-that even if you are a late comer to the Linux movement-your organization is beginning to recognize the value of Linux in the data center. You may even be among those organizations taking advantage of Linux as an enterprise platform. In fact, Linux has become so accepted in the data center, even as the core operating system, that we are now asking the obvious companion question: The Linux Desktop-is it enterprise ready or not?

Currently, most market analysts advise caution in making a wholesale move to Linux on the desktop: caution in making a move just to spite proprietary vendors; caution in too generously estimating ROI and underestimating TCO; caution in assuming that all desktop environments can be, or should be, moved to Linux; and caution in assuming that switching operating systems will automatically resolve desktop security and management problems.

But even against this thoughtful advice, there are early adopters who are using Linux-including the Linux desktop-across the enterprise: the City of Munich, Ernie Ball, Novell-and don't forget that both Google and Burlington Coat Factory included PCs in their original Linux deployments.

And other companies are considering a Linux desktop; for example, according to a Forrester survey, 45% of respondents who use or plan to use open source say that they are either already using Linux on some desktops or they plan to use or evaluate Linux desktops within the year.1

The organizations cited above as well as other organizations that are currently reaping the benefits of open source didn't wait for the market to tell them when the Linux desktop might be ready for their enterprise. They evaluated-for themselves-what benefits the Linux desktop might bring to their organizations and then acted.

The purpose of this paper is to help organizations do just that-evaluate the Linux desktop against their own enterprise needs-market hype aside.

Evaluating Enterprise - Readiness

Just as Linux began its tenure in the data center by filling specific roles, the Linux desktop has begun to move into segments of the desktop environment that are particularly well-suited to its enterprise-class strengths: task-oriented workstations, help desks and call centers, developer environments, and point-of-sale terminals. But some organizations, such as Ernie Ball and Novell, have also found the Linux desktop to be a viable solution in their general corporate environment-on every desktop-with a few exceptions (but only a few).

Because each organization's desktop needs and requirements are unique, it's important to approach a Linux desktop evaluation openly-by considering a wide variety of adoption opportunities. Gartner has encouraged organizations to "fight the temptation to make Linux desktops an 'all or none' decision, and to select the right users to migrate."

A thorough evaluation of the organizational structure of your enterprise will ensure that you have indeed selected "the right users to migrate." Use the guidelines outlined in this paper to help you evaluate the fit between your enterprise environments and the Linux desktop:

• Analyze the organizational structure of your enterprise
• Evaluate and prioritize selected environments
• Evaluate application alternatives
• Evaluate Linux desktop distributions
• Create a road map for Linux desktop adoption

Analyze the organizational structure of your enterprise

Begin your evaluation by analyzing the organizational structure of your enterprise from various angles so that you can get a holistic view of the desktop environment. For example, you might create a graphical representation of your organization based on clear dividing lines, such as business units, geographical location, or LAN or WAN topology.

This view will be useful for segmenting users according to functional job roles, but it may be insufficient for understanding how user groups interact with each other. It's probably best to base your analysis on several organizational views of your desktop environments.

It's often useful to take a three-tiered approach to the analysis, starting first with processes, particularly processes that cross organizational (business unit) boundaries; then the applications that support those processes; and finally the application data that needs to be exchanged. Completing such an analysis will help illuminate and isolate dependencies that will impact, limit, or hinder your migration.

Much of the data you need may already exist if your help desk (or other) group is responsible for maintaining default desktop images for your organization.

Other views that might be useful in your evaluation include the following:

• Work roles: Segment users according to the type of work they perform (e.g., knowledge workers, transactional employees, financial staff, developers, and so on). For example, analyzing the application needs of a call center staff member compared to those of a financial analyst who uses and depends on advanced financial application features can help in segmenting potential migration candidates. you'll also want to compare the levels of specialization for a knowledge worker who uses many applications to create specific, but unique, output to satisfy a variety of job requirements versus a transactional employee or point-of-sales clerk whose job function is driven by a single-purpose application. In addition, account for the fact that each application can have very different platform requirements (see "Workstation environments" below).
  
   
• Application usage: Segment your organization based on the applications each group uses. It is particularly important to understand whether users need all the applications (and all of the functionality) they have installed or only a subset. For example, nurses may only be using Microsoft* Office* from a nursing station to view documents sent as e-mail attachments. In this case, they'd have an almost identical experience using OpenOffice.org on a Linux desktop. If, however, they are using applications with interdependencies on Microsoft Office* or home-grown applications based on Microsoft development tools, then the issue is much more complex.
  
   
• Interaction among groups: Identify user groups according to the way they interact with other groups taking particular note of the software used in the interaction. Some groups have significant interoperability requirements with other groups, either internal or external; other groups may have almost none. The fewer interdependencies, the easier the group is to migrate.
  
   
• Browser-based desktop environments: Highlight desktop environments that are mostly browser-based. Users who access all or most of their applications via a browser or thin client are excellent candidates for Linux adoption.
  
   
• Critical job roles: Identify any environments that may need special attention (the finance department, for example, may require software that runs only on Windows*). While it may still be possible to migrate these special-interest groups, you'll need to be aware of and plan for special circumstances; these are not usually the first groups you'll want to migrate to a Linux desktop.
  
   
• Technical ability: Classify users according to their technical abilities. When adapting to a new desktop environment, users with greater technical abilities, such as power users and self-starters, generally need less attention than others. It's good to understand who your power users are early in the evaluation process because they can be invaluable as early-adopters and in helping roll out the desktop to others.
  
  *Be careful not to confuse a power user with someone who has become very familiar with the advanced features of a single application. Often these individuals are less receptive to change because they have become dependent on tools they know.
  
   
• Workstation environments: Pay special attention to environments that focus more on the functionality of the workstations, rather than the users: manufacturing kiosks, point-of-sale terminals, lab environments, call centers, customer service desks, and other single-purpose workstations. Single purpose workstations–running a single or limited set of applications–are often among the easiest to migrate.
  
   
• Hardware and operating systems: Document workstation environments according to when the hardware or operating systems will lose vendor support. Note particularly the environments that are already or soon will be out of date. These are environments that should already be slated for migration, but often times are not because organizations do not need the new features of the latest releases and find it difficult to justify the cost of upgrading. This often provides an opportunity for a phased migration approach-taking advantage of the natural expense associated with hardware and operating system upgrades.

There may be other ways to organize and analyze the various groups within your enterprise that will become apparent as you work with the suggestions above. Having this holistic view of your desktop environment helps you make sure your decisions are based on real-life business processes and the day-to-day activities of your user communities. It also provides the foundation for the rest of your evaluation process.

Evaluate and prioritize selected environments

Begin evaluating your user and desktop environments by focusing first on environments that other organizations have found to be well-suited for Linux–namely, task-oriented workstations, help desks and call centers, developer environments, and point-of-sale terminals. One of the next logical groups to consider is workgroups that are self-contained (don't have significant interaction with other groups who may be using different processes and applications). But just because adopting Linux desktops in these environments proved beneficial for other organizations does not guarantee they will be beneficial for yours. Pay careful attention to the needs and priorities of your own enterprise and how well Linux meets your requirements.

The same recommendation applies when considering Linux as an alternative for knowledge workers. While only a few organizations have embraced Linux desktops across their entire user environment, this does not automatically mean that your enterprise will come to the same conclusion. Even if you decide that now is not a good time for a wholesale migration for your entire user population, you'll have a clearer understanding of your future requirements.

Priorities will, of course, differ from enterprise to enterprise. Consider the suggestions below in identifying your priorities for ranking user and desktop environments:

• Potential benefits: Each of your desktop environments will offer a different set of potential benefits. These may include direct savings in licensing costs (don't forget to apply this benefit to environments that are currently out of compliance or in need of an upgrade), increased user productivity, lower maintenance costs because of virus avoidance, simplified management, better uptime, or better development tools.
  
   
• Adoption groups: Some groups within your company may be better positioned or more willing to lead a desktop migration. Leverage such groups as thought leaders in adopting an overall approach. Use these early adopters in pilot programs and as a sounding board throughout the migration process. They can help you identify and avoid many potential problems.
  
   
• Appropriateness of current platform: The one-size-fits-all desktop model has worked for the past ten years mostly because there were not any other sizes. The Linux desktop is changing this by allowing enterprises to create desktop environments that are fit for purpose.
  
  You may even find it useful to carry your analysis to the application functionality level by analyzing whether all the applications-and all of the application functionality-currently installed on a given desktop are actually being used or whether less expensive, open source software running on Linux can provide a more suitable environment. For example, contact center, call center, retail point-of-sale, and other fit-for-purpose environments can possibly be delivered via the Web or terminal services to provide only the tools needed for the task at hand rather than the full contingent of desktop tools you provide for other desktops.
  
  Having too many applications, or providing applications with more functionality than needed, can be just as detrimental to user productivity as not having the right applications, not to mention the cost incurred in paying for licenses that aren't fully being used.
  
  Don't forget to evaluate appropriateness in terms of missing functionality in the current desktop platform, as well. The current platform may have limitations that Linux doesn't have, particularly in developer or task-oriented environments.
  
   
• Application dependencies: Groups that are dependent on Windows-based applications will likely have a more difficult time migrating to Linux. This does not always mean that migration is impossible; it just means that finding a solution may take more effort and creativity.
  
  In your evaluation, be clear about what constitutes a dependency and what does not. Users may only be using subset of an application's features that can easily by replaced with another, Linux-friendly application. For example, a user may need a particular application solely to read reports produced by another group, a dependency that can be eliminated by producing Web- or XML-based reports.
  
  Make sure you account for application dependencies that result from interaction with another user group; for example, regulatory, governmental, and financial agencies may require standard Microsoft Office formats. Or, an application that can run on Linux may depend on Microsoft Office formats for importing and exporting data. And even if a user group has no dependencies on Windows applications within the group, the group may need to work with other groups that do.
  
   
• Impact on the user community: You can expect each user community to be impacted differently. When setting the order of migration, it's important to anticipate and manage the potential impact for each group.
  
  Important factors to consider include the following:
  • The user's skill level (power users are often more adept at learning new tools, but they are also more likely to use advanced tool features)
  • How much of the user's day is spent using desktop tools
  • Outside factors that might come into play (demanding accounting or sales time constraints, ongoing departmental workloads, and other projects currently in progress)
  
  Consider using surveys or interviewing key user group personnel to help you pinpoint a "best" time to migrate a particular user group.
  
   
• Support contracts: Your enterprise may have some environments that are (according to vendors) long overdue for operating system or application upgrades. On the other hand, these environments may still be using the older software because it meets requirements for required tasks. In such environments, you may find it more valuable long-term to consider open source or less expensive proprietary alternatives running on Linux instead of continuing on your current vendor's specified upgrade path.
  
   
• Level of effort: Evaluate and prioritize environments based on how much upfront effort it will require to introduce the Linux desktop. Include testing, training, and support estimates as well as application migrations or replacements. Approximately the same level of effort in providing training and support is required whether upgrading to a new version or switching to a Linux-friendly application.
  
  In completing this evaluation, don't limit your options to all-at-once migrations.migrating all users in one giant leap. And consider the possibility of introducing Linux as part of the hardware refresh cycle, as the standard for new employees, or in soon-to-be-created environments such as a new regional office.
  
   
• Interoperability requirements: Interoperability between Windows- and Linux-based applications is less of a challenge today than it was a few years, even a few months, ago. However, depending on the application, identifying one that's Linux-friendly may pose a significant challenge for certain user groups. Groups that are largely self-contained (interact only with their own group members) will have an easier time transitioning to Linux because interoperability requirements are less likely to have an impact.

Document both the positive and negative aspects of your evaluation. Remember that Linux desktop adoption does not have to be all-or-nothing. The positive results can be translated into short-term opportunities for segments of your enterprise that are ready to move to a Linux desktop. The negative results can be translated into specific steps or requirements that need to be met before considering Linux desktop adoption for other user segments.

Evaluate application alternatives

An important part of any bid to move from Windows to Linux desktops is evaluating the application changes such a move requires. Begin by looking at the applications in the desktop environments that you have already identified as higher priorities for Linux adoption and move on from there. This is also an excellent exercise in simply understanding your enterprise's application portfolio and what may be possible in the near to long term.

We recommend using the following three questions as a baseline for identifying and evaluating application alternatives:

Is there a Linux version of the existing application?

As the Linux desktop continues to gain attention, more vendors are making their applications run on both Linux and Windows. For example, SAS*, SAP*, and Novell GroupWise(TM), all have clients for both Windows and Linux desktops. Check with your current application vendors to find out if they have a Linux version or are planning one anytime soon. (If they don't, and they're not currently planning on it, this is a great opportunity to encourage them to adopt a Linux strategy by letting them know that you'll be looking for an alternative Linux-friendly application.)

If not, is there a comparable Linux alternative?

As we've already indicated, it's important to view each of your current applications as a set of functionalities that allow users to accomplish their daily tasks. In many cases, fully comparable Linux applications are available; for example, replacing Internet Explorer* with Mozilla* Firefox* or Microsoft* Access* with MySQL* should provide one-to-one and for some activities better. functionality. And while OpenOffice.org is not exactly the same as Microsoft Office, for most users it has more than enough of the same functionality to make little difference.

If the current application will not run on Linux, first determine what functionality users really need and then look for a Linux-friendly application that provides it. And don't be surprised when you discover that some Linux-friendly applications provide functionality that is more specific to the needs of your users than their Windows-dependent counterparts.

If neither, is there another viable option?

When you can't identify a Linux version or a viable alternative, you'll want to investigate the feasibility of other options such as porting the application to Linux, serving it from a Web or terminal server, or using a utility such as CrossOver Office* by CodeWeavers*. Porting is particularly effective for internally developed applications and should be considered as a long-term solution. Web or terminal services can also be long-term solutions, particularly if your enterprise adopts a Linux thin-client strategy or finds it more cost effective to manage certain applications via the Web or terminal services.

In some cases, you'll discover that alternatives are more expensive than your current solution; watch licensing fees and development costs carefully. In this case, you will need to determine whether it's better to wait, to retain your current system, to support two systems, or make to an across-the-board move to Linux.no matter the cost and inconvenience.

Evaluate Linux desktop distributions

Evaluating Linux desktop distributions is part of deciding whether Linux can meet the needs of your users and whether a Linux desktop is a worthwhile pursuit for your enterprise. Your analysis should include an assessment of which distribution to use and what criteria to use in your evaluation. Fortunately, there are many good options, with new Linux desktops being announced almost daily. Since this paper is being provided by Novell, we could end the discussion by recommending one of our own desktop solutions, particularly the Novell Linux Desktop released this fall (2004). Instead, let's look at some of the criteria for evaluating distributions so you can make your own decision.

You could decide to pick one of the more popular distributions-the ones with the greatest market share. You could choose one of the "free" (or nearly free) distributions. Or you could choose the distribution that offers the most comprehensive training and support systems. Whichever distribution you investigate, you'll have to wade through intangibles like perceived value, flashy marketing programs, and other subjective measures. It's easy to get caught up in a wave of hype that clouds the real value. Instead, base your decision on the features and functionality that are necessary to support your business objectives.

Look for specific measurable factors such as Interoperability; does the distribution support the applications you must run? How many applications run on this distribution? A limited number? Are the applications included with the distribution those that you really need?

Look for specific measurable factors such as Interoperability; does the distribution support the applications you must run? How many applications run on this distribution? A limited number? Are the applications included with the distribution those that you really need? Does the organization behind the distribution have strong industry backing? Are hardware and software vendors recommending the distribution for use with their products? Does the distribution offer a variety of windowing environments such as KDE* or GNOME?* What about integration with your workload environment and identity infrastructure?

Evaluate Support for the product. Many distributions are available that generally perform very well, but when you do experience a problem, is there anyone who is responsible for resolving it? Many distributions depend on the Linux/open source community for problem resolution and even though the community's response rate is typically very good, are you willing to bet your business on this method? Will the support organization be able to provide the right level of affordable support.

And if you find a bug, how quickly can you get a patch? Productivity can be significantly impacted when the patch process is difficult and highly manual. Look for a systematic method for patch distribution, one that provides you with discreet control over when, how, and where the patches are applied. This mechanism should not be limited to supporting only the distribution but desktop applications as well.

Consider the Ease of Installation of the distribution, specifically with regard to the default configuration. Do GUI and automated tools make installation easy and automatic or will you need power-user skills to get the job done via the command line? One of the most notable installation concerns is the strength (or lack) of security. Different distributions ship with security settings in various states, some in very insecure states. This often requires a series of modifications that must be handled manually as soon as the basic installation is complete. Anytime manual intervention is required, the stage is set for mistakes to occur and they usually do.

Every operating system requires some level of software Management. it's important to understand what that level is for applications, services, and the end users running them and to select a distribution that provides the level you need. it's equally important to look at how Linux can be managed in context with your existing environment.

Evaluate whether the distribution helps you meet the challenge of managing your Linux resources, especially update and patch management. To be effective, a Linux resource management solution should support the software update process typically employed in the Linux environment.

This process consists of four major phases:

• Obtain new updates. The solution should automate access to updates, not only updates from outside the organization but also those from internal developers.
• Move updates into a test environment. The solution should not only facilitate but also automate the move.
• Organize and manage software during testing. The solution should provide the means to monitor and manage the software test process while tracking progress.
• Distribute tested software to the production environment. The solution should manage the migration of tested software to the production environment.

An additional consideration should be the vendor's activity in the Open source community. Are they a significant contributor? How active are they in forums and events? Do they continually help raise the bar in terms of open source innovation?

If the activity is high, but the nature of the contribution seems proprietary, the contributions may do more to "fork" Linux rather than embrace open source. Innovation, on the other hand, can sometimes be confused with proprietary code but ultimately proves beneficial to the community. Weigh this aspect carefully.

And finally, make sure you include application Certification on a specific Linux distribution as one of your evaluation criteria. In many cases, you'll discover that Linux distributions have been certified by both the application vendor and the distribution vendor for use with specific versions of the distribution. In other cases, distribution vendors simply indicate that their own testing indicates that an application is .ready-to-use. with a particular version. This can be a significant distinction; the best solution, obviously, is testing the application in your own Linux test environment.

Create a road map for Linux desktop adoption

Technically, the time to create a road map is after you have decided to move forward with a project; but in evaluations like this, a road map can also be a valuable tool for weighing what it might take to accomplish such an initiative.

Your road map may be as short- or as long-term as you deem appropriate; however, a road map covering three or more years may have stronger strategic significance. Creating a road map will allow you to consider your enterprise's business and technical strategies and examine opportunities for the Linux desktop to benefit both or even help align the two. If, in your evaluation, you find that some environments don't fit with the Linux desktop right now, a long term road map provides an opportunity to examine the potential for adoption in the future, despite current limitations. Just as Linux desktop adoption doesn't have to be all-or-nothing, it also doesn't have to be now-or-never.

We recommend including these aspects in your road map:

• Business and technical strategies: Consider the direction your enterprise is moving as a whole and how IT investments might be affected in the near and long term. For example, are you looking for opportunities to cut long-term IT costs or for more flexibility in making IT decisions?
  
   
• Business continuity requirements: This consideration can be analyzed in two ways:
  • Identifying areas in the enterprise where business continuity on the current desktop has been a challenge. you'll probably want to replace these desktops sooner than others that haven't been troublesome.
  • Identifying environments where business continuity cannot be interrupted for any reason-including migration projects.
  Such circumstances may include mission-critical applications, quarterly reporting schedules, or expectations for seasonal high sales volumes. Your road map needs to account for and accommodate such circumstances.
  
   
• Other initiatives or events: Other initiatives may be obstacles to avoid or opportunities to pursue. For example, other projects slated for the next several quarters might either take priority over a Linux adoption strategy (and consume the funds, time, and staff you need) or provide ideal opportunities for adopting Linux sooner than you thought possible. If moving ahead with a full-fledged desktop project isn't possible, consider doing some of the preliminary work such as testing in small pilot environments.
  
  On the other hand, some projects might offer excellent opportunities to adopt Linux desktops sooner. For example, if your enterprise will be setting up new regional offices over the next few quarters, you may be able to set up entire Linux-only environments. Doing so would allow you to avoid Linux desktop migration costs and roll the cost of two projects into one. This can also be an excellent testing ground for migrating other environments. Other events that can simplify Linux adoption are new hires, hardware refresh cycles, expiring vendor support agreements, or other software updates.
  
   
• Interim migration steps: You may want to consider some interim steps to test the viability of migrating desktops to Linux and to help ease users into the new environment. Consider rolling out open source replacement applications, such as OpenOffice.org or Mozilla Firefox, on the current Windows operating system. This way, the applications are new, but the desktop is familiar.
  
  Such interim steps make the eventual transition to Linux easier because users are already familiar with the productivity applications that they will use on the Linux desktop; everything isn't new at once. They are also excellent opportunities to target large groups of users without significant risk because users can run the new applications alongside the old ones. This is a good way to test users. reactions to the new applications and gauge possible reactions to the Linux desktop.
  
   
• Test groups: Your road map should include a list of likely pilot environments and test groups. How many will depend on the type of Linux adoption and the number and differences among groups within your enterprise. Often, the best place to start is with the IT department or with other technically savvy users who can provide more specific feedback and who will be less likely to lose productivity in moving to new environments.
  
  Another good method for choosing test groups is to identify a few early adopters in each environment you plan to move to Linux. These adopters should be familiar with the applications used within their departments and should be more technically adept than typical users. Then, when you move the rest of the department, these users will have the experience needed to ease the transition for their colleagues.
  
  Support contracts and licensing agreements: Current licensing agreements and support contracts with vendors will also affect your road map. The expiration of such contracts provides a solid deadline for migrating from an older operating system or application. Contract expiration dates may also delay your plans because you want to get the most out of current contracts. Make sure your road map accounts for these contracts and includes strategies for handling their expiration.
  
  A particularly important aspect is deciding what to do if a vendor ends support for a specific application or operating system. Even if you are not ready to move to Linux yet, automatically upgrading to the new software may hinder future plans to migrate.
  
  Take a proactive approach to your vendors. attempts to force upgrades. If users will not benefit from the new version, they don't need the new functionalities, this may be an appropriate time to consider the alternatives to upgrading.

Make sure your road map is as realistic as possible, even if you don't yet have solid plans for adopting the Linux desktop. The more realistic it is, the more useful it will be in determining whether the identified opportunities for adoption are viable. Road maps are also useful in helping appropriate decision makers understand all the implications so they can make an informed decision.

Putting a plan together

Developing a plan for moving forward is essential, whether you complete your own assessment and migration or use third-party professional services to help you facilitate all or part of your project. Either way, you'll want to plan carefully so that such a transition addresses not only your immediate goals but your long-term strategy as well.

If the recommendations in this paper and your initial investigation suggest that you need experienced help in planning and completing your migration, many consulting organizations, including some hardware vendors, offer experienced and professional help. Compare the services available and choose the one that's right for you.

Novell Professional Services can also provide the consulting help you need. Our engagements span the migration spectrum: from Strategy and Discovery to Requirements Assessment, Planning and Design to Implementation. Our offerings help you assess both current and future strategies and help you discover your readiness for moving to a Linux desktop. We provide help in deciding how to best approach a migration and assist you in planning and designing your entire project. And, finally, our consultants and partners stand ready to help you implement your migration plans. For a high-level summary of Novell assessment criteria and for additional information about Novell desktop migration services, visit us at http://www.novell.com/linux/migrate/desktop1.html

Conclusion

A few months ago, an article in Computerworld discussed the advisability of replacing ubiquitous Windows. desktop applications with Linux/Open Source. The writer concluded that "Microsoft owns the desktop, and the open-source folks might as well give up the silly game." We beg to differ (and so do several other Computerworld readers who wrote to object to this assumption). We at Novell have each personally either made the switch or are in the process. Though not without some pain, we've proved that the Linux desktop is enterprise-ready, but there's another, more important, question: "Is your Enterprise ready for Linux"? The discussion items in this paper should help you make this decision.

Open Source Apps Losing Desktop,. by Mark Hall, Computerworld, June 2004.

Because you will be changing the way your entire organization does business, being realistic and conservative is the order of the day. But in our opinion, it's an exciting–and productive–adventure. You don't get an opportunity to change the way the world works very often. Join us–and the growing number of major corporations and governments across continents–in proving that Linux on the desktop is much, much more than a "silly game".

Additional Reading

The following articles will give you some additional perspective on the issues you'll need to evaluate in determining whether a move to Linux on the desktop is right for your organization. URLs are included with these brief abstracts so that you can read the entire article.

• "The Business Case for Desktop Linux" by Robert McMillan, InfoWorld, August 18, 2004.
  
  According to McMillan, "it's still extremely difficult–if not impossible–to get solid data on Linux's TCO on the corporate desktop. And although the Linux desktop has strong appeal for some customers, it isn't for everyone." McMillan also notes that the "one major outstanding issue for any company looking to migrate to the Linux desktop...is application support. ...When one considers the legacy applications and Microsoft dependencies common to most enterprises, a move to Linux can quickly become a complicated proposition." Alternatives mentioned include CrossOver Office (CodeWeavers) and Metaframe Access Suite (Citrix), but both .require some tuning, or at least extra software licenses, to achieve parity with Windows.
  
  McMillan's article looks at both sides of the issue and is cautiously optimistic about the move to Linux except for wholesale replacement across the entire enterprise. The article cites several Linux desktop deployments including the city of Bergen, Norway, and the Allied Irish Bank. McMillan also notes that one group is engaged in .pilot projects and even some large-scale Linux migrations, which could collectively total as many as 2,000,000 desktops. McMillian also reviews the current state of Linux desktop adoption and suggests gains but not an overwhelming rush to migrate. http://www.linuxinsider.com/story/35918.html
  
   
• "Austin tests desktop Linux waters" by Steven Shankland, CNET news.com, December 2003.
  Read this somewhat dated review of the .non-emotional Linux pilot. project being conducted by the city of Austin Texas. Austin technicians are .just trying to make it actually function in our world.. The OpenOffice suite is also being tested and seems to be a fit. "Austin will use the Microsoft products it's already bought for as long as possible. We are not throwing Microsoft out of the city of Austin."
  http://news.com.com/2100-7344_3-5130142.html?tag=nefd_top
  
   
• "Switching to Linux picks up steam" by David Becker, CNET News.com, August 30, 2004. This article refers to a study by The Yankee Group who found that .36 percent of businesses expected to have a few Linux PCs in their business, but only 5 percent planned a total migration to Linux. A majority 57 percent planned no changes for Windows on the desktop.. The Yankee Group report cites .a number of factors for corporate caution in moving to Linux, most notably the increasingly complex calculations required to determine whether such moves are cost-effective.
  http://news.com.com/Switching+to+Linux+picks+up+steam/2100-7344_3-5330340.html?tag=nefd.top

Contact Us

For additional information about Novell, please contact your local Novell Authorized Reseller or system house or call, fax, or e-mail Novell at
1-888-321-4272 (U.S. and Canada)
1-801-861-7000 (worldwide)
Fax: 1-801-861-8473
E-mail: customer_response_center@novell.com
Copyright Novell, Inc., 2004. All rights reserved 14

Copyright 2004