On Fri, Oct 31, 2008 at 10:41 AM, Haworth, Michael A. <Michael_Haworth@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