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."

3 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
  3. 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.