Slashdot Mirror


Linux Usage in the UK

pdajames writes "Techies don't seem to understand that businesses want to have a support contract with their usual supplier before they will buy Linux, even though the likelihood is that they may never need support. A survey in the UK showed that support concerns were the No. 1 factor keeping companies from investing in open source software."

8 of 280 comments (clear)

  1. No issues here by Richard_at_work · · Score: 5, Interesting

    I can never see the problem, at my place the only support contract we have is for the AIX server. We have a liberal number of OpenBSD and linux boxes around the business, all running semi critical and critical systems, and we have no support contracts. All of it is handled inhouse by moi, we have redundant backup systems, and a good backup procedure. Any issues i get that i cant resolve, i can usually find a good answer from mailing lists, google or IRC. Seriously, how many of these same people have support contracts for their Windows systems?

  2. It's an excuse... by heironymouscoward · · Score: 5, Interesting

    Developer: I'd like to use Linux for this project.

    Manager: I'll check with our suppliers to see if they support Linux.

    Suppliers: hahahaha.

    Manager: sorry, developer, company policy is clear: no support, no project.

    Developer: COM+ gnash MTS splutter IIS damnation.

    --
    Ceci n'est pas une signature
    1. Re:It's an excuse... by Spoing · · Score: 4, Interesting
      Or, where I am now the techs and managers hear this;

      On-Site: We'll save $300,000 if we use Linux instead of HPUX and Windows on the servers.

      Home office: You will use HPUX and Windows.

      On-Site: Why? It's more expensive!

      Home office: We are Microsoft and HP partners. We will not be using Linux.

      That said, we're using Linux after the main installation (with Windows and HPUX) goes in. Most of the cost savings and support benifits are lost, though, since the budget has been misspent already.

      --
      A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
  3. Identity and accountability by Faust7 · · Score: 4, Interesting

    It's not so much about the actual amount of open-source tech support out there -- we know full well there's a hell of a lot of it -- but about about tech support identity.

    Who do you call for trouble with Windows? Microsoft. Trouble with DB2? IBM. Trouble with Red Hat or SuSE Linux? Red Hat or SuSE. What if one of your critical machines happens to be Debian and the one guy that configured it isn't home? Is management going to endorse going to a mailing list or USENET for the solution? What if those sources are wrong?

    Quite simply, the very nature of open-source development does not lend itself to the establishment of centralized technical support, which is exactly what corporations are looking for. Perhaps individual companies whose sole focus is tech support of open-source operating systems and applications could emerge as viable contractors.

  4. I can see this... by Dysan2k · · Score: 3, Interesting

    Well, as one who's had to use support contracts in the past (Cisco and Oracle specifically along with a couple of very poorly built proprietary apps), I've seen the value in this. Being an expert in something does NOT mean you know everything, and it's nice to have someone you can pick up the phone and talk to, getting your critical machines back up and running.

    Even library projects have given me the fits both professionally and non. QT support helps in a LOT of cases where documentation is SEVERELY lacking, but in other cases (kernel issues I had), the support from the maintainer was "less than shining". And people constantly say "Don't expect anyone to get off their duff to fix YOUR problem unless you pay them." Well, that's kind of the line of the support contract. I'd rather my job not be in jepordy due to some individual who could care less about the past work he's done.

    So, support contracts? Sure. Make them reasonably priced, and not read like stereo instructions. Simple pricing, simple support, and simple solutions. And don't expect M$ to give you much support as I've run into massive horror stories (usually related to Exchange). It's nice to have your problem solved, and not spend 3 hours "guessing" you have fixed it. Besides, having a second person to get ideas for solutions from is hardly a bad thing.

    --
    -What have you contributed lately?
  5. Support Clearing House? by PM4RK5 · · Score: 4, Interesting

    Maybe what Linux needs is a giant support clearing house. By that, I mean that most open source projects don't have the resources to have their own support department, but if one were to form a company or other institution with a handful of linux techies, companies could use OSS and rely upon the said support clearinghouse for their support needs, should they actually need help.

    And in some ways, that might be better, because if you have a handful of people who understand the software itimately, you won't have to cut through 3 layers of workers before you get to the "Engineer" level.

    In addition to that, the cost of support is taken away from the maintainers of the OSS projects, and placed in one company which could take the revenue and pay their own costs, and then distribute profit (if any) amongst open source projects, possibly, to help improve the OSS? I know that's idealistic, but hey, it could happen...

    Anyways, just my thoughts on the issue.

  6. Very similar situation in Israel by ohad_l · · Score: 3, Interesting

    Everything you see here, much like the comment by Peter Cooper describes, is Microsoft. The difference is that England can afford it, and Israel can't (palestenian conflict wreaking havoc on our economy and all). Piracy here is outrageously high, but Microsoft doesn't really care - especially in the past few years: more pirated copies means better lock-in. And they've got a point: Anyone who knows anything about computers here, it's all Windows. True, we have some very skilled hackers here, and people are generally very computer-literate... but Linux's penetration is very weak, mainly due to the fact that bidi (right-to-left text) is extremely hard to implement, and has only recently become usable in Linux. People are working on various distributions - mostly Knoppix-like - for Israelis, the most notable one being Kinneret: a bootable distro geared towards Israeli students. Why? Becaue our teachers openly encourage us to copy our compilers and IDEs from friends. Still, for my 12th-grade C project, I won't be allowed to use any compiler and library but Borland's old DOS one. As for support - the issue is very apparent here. The few Israeli "big-chiefs" who have heard about Linux are extremely concerned with support. Hopefully, our goverment will do something smart about it, like the support they've been giving the OO.o team.

    --
    If it weren't for fog, the world would run at a really crappy framerate.
  7. Supportability by The+Monster · · Score: 5, Interesting
    Heh, a couple of hundred lines of C but it needs supported.
    I work for the technical support department of my company. Our software was originally sold and serviced by independent vendors, many of which have since been acquired by the company itself. One of the things that makes support difficult is the high configurability of both the application itself and the underlying OS most often used (a flavor of Unix) make it easy for people to write utilities to expedite various common functions, to install system daemons that launch from different-named init scripts,.... When I come across problems at sites that were inherited from the sundry vendors, each of which had its own notion of the right way to do things, I must often waste precious time figuring out the intricacies of these 'couple of hundred lines', which are not documented in any way.

    I have become one of those people who writes a 'couple of hundred lines' here or there (gradually assembling a package of tools that I upload to servers whenever possible) but as I am painfully aware of the Dark Side of infinite customizability, I have gone out of my way to document my work.

    1. I write everything to Bourne shell, sed, awk, grep & Co., even though it might be easier to use perl or compile to binary. Even using a Korn shell is something I've avoided because I want my work to be understandable to as many people as possible.
    2. I make liberal use of comments within the scripts to explain what I'm doing and why.
    3. My scripts respond to -h, --help, or anything remotely resembling either, with some, uh, help, which includes my work email address.
    4. I've set up a documentation web page on a server on our intranet so that if anyone has questions, they can see what's supposed to be happening here, why, and how.
    5. If you don't know that my utilities exist, or they haven't been installed on a site yet, you can get by without them. They in no way intrude upon the functioning of the system so as to be required (as your proxy is).
    6. I've tried to educate others in my department about how these tools can be used, how they fit together,
    And, even though I have the support of at least two levels of management above me in the org chart, I'm STILL concerned that someone high enough up the food chain will some day declare my little skunkworks project officially Evil and ban it, if for no reason other than the notion that nobody but I understand it well enough to keep up with the changes that will inevitably be required. What happens if I get hit by the proverbial bus, or just take a better job somewhere else?
    For example, I wrote a utility to get around something our software people had done that makes logged-in users of our thin client software not show up in a who or w. My utility shows those users as well as the ordinary who/w output, and I just found out yesterday that the latest upgrade to our core product changes the rules yet again, requiring me to slightly rewrite the utility to keep it working with all variations of our software and the two main flavors of Unix it runs on.
    There is plenty good reason to not want people to become dependent on my tools being in place, since there is no guarantee that we can make the institutional commitment to maintaining them, even though I have plenty of happy customers and support techs who love what I've empowered them to do. I can only hope that the Guys in the Ties will recognize that deriving this much value from my work demands that we make that commitment, rather than abandon it as 'unsupportable'.
    --

    [100% ISO 646 Compliant]
    SVM, ERGO MONSTRO.