Conversion to Linux

[Justin Dugger]

On Fri, Oct 31, 2008 at 10:41 AM, Haworth, Michael A.
<Michael_Haworth at pas-technologies.com> wrote:
> OK, now the real reason for joining KCLUG – I am looking for information and
> wisdom. The company that I work for is contemplating a major shift from
> Microsoft to Linux within the next year or so. I am pretty much the only
> Linux-savvy guy here, and that isn't saying much. I have messed around with
> Ubuntu, Linspire, and a few other distros, and Ubuntu is wowing the
> executives right now with its ability to access windows shares, etc. – they
> want me to draw up a rough plan of what it would take to switch to linux in
> a gradual way. I am looking for some help and guidance, please no flame
> wars…

It really depends on what your company does.  Most companies have at
most two kinds of computers: desktop and server.  With servers, you
can just list out the services running, chart out their
interconnections and roll out replacements over time.  Without knowing
your company's current practices, I have no idea how hard it would be.
But basically, try switching out the least painless stuff first;
webservers, SMB/CIFS windows shares, etc. And then I like Sean
Craigo's idea of finding the service IT hates to deal with the most
and transition it to demonstrate that open source isn't necessarily
worse than proprietary.

The desktop side is a bit different. I would start by moving to open
source equivalents on Windows.  It's the case that nearly everything
user visible in Ubuntu has a Windows port.  Firefox, OpenOffice,
Pidgin, Evolution, Ekiga, Eclipse, GNUCash, etc. You need a list of
software the company needs in the operation of its business, find
equivalents in Ubuntu and transition to them on Windows.  In this way,
the penalty of canceling the transition minimized. You've still placed
the organization into a better place for the future, with high
quality, zero cost software that isn't tied to a single OS vendor.

If you get to the point where everyone's happy and comfortable with
the open tools that you'd be using in Ubuntu, it's time to tackle the
big problems: the software for which no suitable replacement exists.
Your options are to:

1: Do without (unlikely)
2: Emulate Windows (Wine, Crossover, Cedega)
3: Postpone/cancel the transition, documenting the blocking flaws for
later review
4: Fund the development of a suitable replacement

I'd love to recommend the last option, but most places balk at the
idea of paying a ton of money to implement a plan designed to save
money. Certainly investigate option #2, and if that fails bring up #1
as way to discuss how much this tool is costing the organization
versus benefit.  In a few rare cases it might lead to an argument for
#4, if it's a really expensive license. In that case, you should
probably at least call the people who make the software you use
currently and let them know you need a Linux port.

The third column of transition is the IT staff.  Navigating open
source requires a different set of skills than windows.  You have the
opportunity to work much closer with the developers, allowing for a
kind of diligence that pays off far better than emailing your sales
contact will do in Windows.  I find the sweet spot is to be able to
find bugs, load the software in a debugger and pinpoint where things
are going wrong.  Then I can take that to "upstream" developers who
know the code much better than I to fix.  It's the kind of handoff you
can't do in Windows -- "Hey there's a segfault in line 503 of xkbd.c,
but I'm not sure what should be done when the pointer is null."  So
make sure people learn how to navigate sourceforge, bugzilla and
Launchpad, and try to establish a rapport with a few developers
upstream who's work you depend on.  And of course, make sure corporate
and IT staff knows that the GPL comes with source disclosure clauses,
and that it's normally in their best interests to release small
patches anyways.  If you find and fix a bug in Nautilus, contributing
that patch so it's included in the next release makes your company's
life easier.  Certainly, a company with an IT staff of 6 is in no
shape to call trivial patches a competitive advantage.

I hope that helps with the general plan, even though I'm not an expert
at the specifics.

Justin Dugger