I started writing a response to a discussion in the latest “Linux Link Tech Show” episode, but ended up with something far too long, so I’ve split it up into 4 posts. The next post is about the TLLTS vs TWIT debate, and introduces this set of post. The previous two are about open source support–a true story of a support incident I had, and the unwritten rules of open source support. In this post, I analyze the fundamental differences between Windows, Apple, and Linux when it comes to support.
Dann and Linc had a quite spirited debate about the merits of having a company hire low-end tech support with scripts (Dann) versus having an experienced, savvy, tech professional able to really solve the user’s problem (Linc). Dann’s point was that it can easily be more cost-effective for both the support company and the end user to go straight to reinstalling a system if rebooting doesn’t solve the user’s problem, while Linc seemed to think a savvy tech person could get to the root of the issue much quicker, and brought up the point that there’s a cost to the frustration of users being put through the whole front-line support nightmare.
I’d suggest the situation is even more complex than that, but it also differs greatly between the open source projects and proprietary operating systems. First, let me make a bold statement:
Linux support is far better than Windows or Mac.
But it also has a completely different set of rules. Learn those rules, and you’ll be able to solve your problems more satisfactorily than it’s possible to do in the proprietary world. Let’s talk about these differences, looking specifically at a who, where, what, and how long.
Who can help with your problem?
Let’s take a look at who can help with your problem:
| Level of support | Windows | Mac | Linux |
|---|---|---|---|
| Very basic help, no charge | Friends Family computer guy Newspaper columnists Web Forums |
Friends (fewer than Windows) Family computer guy Mac User groups Web Forums |
Friends (if you know any) Local Linux User groups Web forums Mailing lists Developers on main applications or distributions |
| Paid support | Local IT consultant Franchises like Geek Squad Microsoft, application companies |
Mac consultant Apple Genius Bar |
Linux consultants (like Freelock) Distribution companies (Red Hat, Novell, Canonical, others) Linux support companies (SpikeSource, SourceLabs, etc) Application companies (SugarCRM, MySQL/Sun, Command Prompt) Developers |
The bottom line here is that while you probably know fewer people personally who can help you with Linux, there are more options for commercial support, and you can reach people who can do more to solve your problem for free, than you can with either Mac or Windows.
The fundamental reason for this is that anybody can read the raw source code of any open source product out there, and with enough skill and talent, can solve your problem without needing to pay anybody for the right to do so. In the proprietary world, only one company can help beyond a certain point: for Windows problems, that’s Microsoft. For problems in an application, it’s the application developer.
So the next question is:
Where can you get help?
Again, let’s compare the options:
| Type of problem | Windows | Mac | Linux |
|---|---|---|---|
| Very basic usage help | Google Friends/family Forums IT consultants Seminars Paid support from vendor |
Google Friends/family Forums Mac consultants Seminars Paid support from vendor |
Google Friends/family Distribution Forums Distribution mailling lists IRC Linux consultants Seminars Paid support from dozens of companies |
| Hardware problems | Google IT consultants (may or may not be able to help) Microsoft Hardware vendor |
Google Mac consultants (may or may not be able to help) Apple Hardware vendor |
Google Linux consultants (may or may not be able to help) Distribution paid support (Red Hat, Novell, Canonical) Hardware vendor (support for many vendors is improving) Kernel developer Linux users with the same hardware Application developers for applications that use that hardware |
| Bug in operating system | Microsoft | Apple | RedHat Novell Canonical IBM HP Sourcelabs Many other independent developers |
| Bug in application | Application vendor | Application vendor | Linux consultant Developer Application vendors (often more than one can help) |
| Bug in interaction between applications | You’re screwed. Report it to both vendors and hope they will work it out. | You’re screwed. | Report it to both applications, and get guidance on how to address the issue. Hire a developer to create a workaround. Hire somebody to work with each application to integrate a real fix. |
| Help switching to another application | Application vendor (and you may have to pay them dearly) | Application vendor (and you may have to pay them dearly) | Application vendor, either old or new Any application that uses the same open format Any developer with knowledge of the underlying format |
The main point of the table above is that in the proprietary world, the harder your problem is to solve, the fewer people can help you solve it. You quickly get down to one place to go, and if it’s in the operating system, it might be expensive or not possible to fix. In the open source world, it’s nearly the opposite case–it can be harder to find the simple quick answer to your question, but the harder and deeper your problem, the more places you can go to get help.
Where do you look for help first? This is the single stumbling block for most otherwise tech-savvy users new to Linux. To learn Windows or Mac you can take a class, talk to neighbors and friends, and find lots of very low-end help that way. For Linux, unless you’re friends with some hard-core geeks, you need to go online to find help. Once you’re there, it really depends on where your problem lies.
For just figuring out how to use a system, go to the forums for your distribution. The Ubuntu forums are a great place to ask general questions. Be specific about what you’re trying to do and you’re more likely to get help. Remember that this level of support is free, and people helping you are volunteering their time and knowledge. While you’re there, see if you can answer somebody else’s question–the more help you give, the more you’ll get in return.
The other fantastic place to go for help, especially for quick questions, is IRC. IRC is a system that provides chat rooms and instant messaging. Most open source projects with any community behind them have a chat room on irc.freenode.net. Install an IRC program like Chatzilla, Konversation, Pidgin, or any number of others, connect to irc.freenode.net, pick a nickname to use, and join the channel for the program or distribution you’re having trouble with. Ask your question nicely, and if you don’t get a response immediately, keep your chat program open for a few hours–not everybody is watching the channel every minute.
What kinds of problems can you solve?
Let’s look at the same types of problems as before, and look at the resolutions:
| Type of problem | Windows | Mac | Linux |
|---|---|---|---|
| Very basic usage help or problems | Reboot. Lots of good help available: documentation, classes, seminars, tutorials, books |
Some help available: documentation, classes, seminars, tutorials, books | Same types of help available, but far less widespread. In many cases, the software interfaces aren’t as polished, and the help content is more menu- and feature-oriented than task-oriented–they explain the options, without telling you how to do what you’re trying to do. |
| Hardware problems | Obtain driver from the vendor, and install. Hardware vendors almost universally provide support for Windows. |
If it’s supported by Mac, install the driver. If it’s not supported, you’re out of luck. Most external devices are supported on the Mac. Internal devices, you have far less choice than Windows or Linux. | More and more devices have manufacturers providing Linux support. Many devices have solid drivers written by the Linux community, without help from manufacturers. A few devices have no Linux support whatsoever. Usually if you can’t get it working in Linux, it’s either brand new, or there’s a legal reason it hasn’t been done yet. Do your homework before you buy, and only buy hardware others have gotten working in Linux. |
| Bug in operating system | Wait for a patch or service pack, cross your fingers and hope they fix it Get a premium support contract, and pay Microsoft to fix your bug (note: even with the best support package, they may not do this for you) |
Wait for a new release of the Operating system | Report a bug, wait for the next release Hire a developer to fix it Find other people affected by the bug, and pool your resources to fix it |
| Bug in application | Report it to application vendor, wait for them to fix it (or pay them to fix it) | Report it to application vendor, wait for them to fix it (or pay them to fix it) | Report it to application vendor, wait for them to fix it (or pay them to fix it) Hire a developer to fix it yourself |
| Bug in interaction between applications | You’re screwed. You’re completely at the mercy of one or both vendors. | You’re screwed. | Report it to both applications, and get guidance on how to address the issue. Hire a developer to create a workaround. Hire somebody to work with each application to integrate a real fix. |
| Help switching to another application | Pay the company for access to your data Pay a developer to reverse-engineer the data formats and extract it |
You may be screwed–Apple has a reputation of making it really difficult to get your data back out of any of its applications | Open source applications usually use open data formats. You may have other options that require no changes to your data. Anybody with knowledge can help. |
What’s the key thing in this section? Addressing actual problems is within your control, when you’re working with open source. In the proprietary world, you’re entirely at the mercy of a single software vendor. If your problem is in the interaction between two different applications, you’re really stuck — there’s nothing you can do.
But in the open source world, there’s always something you can do. You can hire anybody with the skills to solve your problem, and fix it in the software itself. You don’t need any blessing from any single software vendor.
Open formats are perhaps more valuable than open source software, for most businesses. Because this is such a compelling advantage of open source software, many proprietary programs are beginning to open up their formats to allow other software to read them–their customers are demanding it.
How long will it take to solve your problem?
I’m not going to bother with a table for this one. The answer is nearly always “too long,” regardless of the operating system.
Actually, that’s not quite always the case–it depends on whether somebody has already solved the problem or not, as well as whether the solution is a fix or a workaround.
Many, many problems in Windows are not really fixes, they’re just workarounds. The only real “fix” for a virus-infected machine is the workaround of reinstalling your operating system. The only fix for lots of other minor issues that cause your system to slow down over time is to reboot. These are not fixes, they’re workarounds.
Real fixes take a lot longer, and need acknowledgment that the problem is real. Workarounds are band aids to get you through until there’s a real fix. And there are some real differences between the entire approaches of each operating system around these fixes.
Windows is chock-full of workarounds. Because Microsoft has gone to great lengths to maintain backwards compatibility of just about everything that’s been released for Windows since Windows 95, it’s full of workarounds to keep the old behavior. Rather than fixing behavior that might really be undesirable, they’ve had to patch it with workarounds because too many existing applications turned out to depend on that bad behavior. That, fundamentally, is why Windows is so big, bloated, slow, and painful to work with.
Apple suffers a different problem: changing their closed libraries too quickly for external developers to keep up. Each release, they break lots of things, and don’t always tell 3rd party developers ahead of time. This means the number of third party developers of Apple software is shrinking–they’ve managed to alienate quite a few. So their polish and high quality comes at the price of having a healthy thriving developer community outside the walls of Apple. There’s little transparency in this process, so developers outside Apple are always playing catch-up, and having to work around these changes in behavior.
Linux has its share of problems, too. Linux does not attempt to maintain “binary” compatibility between versions, though it does its best to maintain compatibility in source code. There is endless debate about the “correct” way to fix a problem, and competition between fixes. The challenge of this is that it can be hard for application developers to keep up, especially if they want to keep their source code closed and only ship software in binary form.
But the process is completely, utterly transparent. Anybody can see the progress on any fixes to any part of the system, and can jump in with their own solution at any time. It’s a true meritocracy, with those doing the actual work and providing the best solutions winning out over time.
The whole open source ecosystem is nimble enough to provide real fixes to technical problems, rather than just simple workarounds. If the source of the problem is design, it can take a long time to get the right design in place and resolve all the issues that changing the design causes in other applications. But when a bug gets fixed, it’s really fixed and usually doesn’t appear again.
Tags: open source, podcasts, support