lkml.org 
[lkml]   [1997]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux (free s/w) support
On Tue, 30 Sep 1997, Darren Reed wrote:

> Are you telling me that hundreds, if not thousands of people have contributed
> code to the Linux kernel ? How many of them could fix a problem with (say)
> virtual memory or debug an obscure SMP problem ? The weight of numbers maybe
> comforting, but expertise in any particular part may be limited to a handful
> of people.

Are you telling me that you believe the people capable of fixing a
problem with, say, virtual memory handling or SMP in, say, Unixware,
SCO 3.2.x or even SCO OS5 still work there? And even if they do that
they are in a position to be allocated to a support problem without
weeks, if not months, of polictally maneouvering and job rescheduling?
The same arguments apply to the commercial side. The real question
is, do the right people have the source and can they be bought at
short enough order to fix your problem in a timely fashion?

> > With commercial companies, you have to go through a
> > poorly staffed and poorly trained customer support department, and
> > have no alternative to hire someone else to fix the problems.
>
> Whereas with Linux, you have people doing customer support who have never
> been trained for support roles, probably scoff at it even being suggested
> that they do any sort of training and can even be hostile in response if
> it suits them.

Many companies see support as a junior job. Many companies use it to
train new people on their products. This is not unreasonable as 90% of
support calls are easily close by someone who knows how to use an
index in a manual. Getting support and getting to knowledgable
developers is not the same.

> A good example of why _NOT_ to choose Linux (from a support point of view)
> is the lack of any problem tracking such as GNATS (well at least not to my
> knowledge - I asked Alan if there was any database of interesting problems
> reported, to which he said he had no knowledge of which I'm implying means
> a lack of this. There's also an absence of any reference to PR's in email
> on the linux-kernel mailling list...). Even FreeBSD/OpenBSD/NetBSD use
> GNATS for tracking problems.

So set it up. Or offer a system to run it. Or simply offer a bit of
money to encourage someone else to set it up. After all *you* want
it. The reason we don't have it is because no one else has felt that
big a need yet. Maybe if you did it we'd all see how sadly blinkered
we'd been :-).

> You might have lots of people but there is no sense of co-ordination or
> any sort of organisation of those people for problem resolution and nor
> is there any central management of problems.

From where you are, maybe not...

> An example of how this can
> be a problem is if I post a problem and get 10 different patches to fix
> the same thing. Each patch is different because nobody knows what the
> other did and there is no tracking of what anyone is doing/has done -
> unless they happen to cc an email list or others.

That's called parallel development. In complex systems people take
different approaches and see different problems and requirements.
Seeing half a dozen or even a dozen different approaches helps
convergence on the _right_ version. Commercial companies tend not
to do parallel development (except for safety critical systems)
because throwing 90%+ away is not a useful business approach. However
end users should be happy to get this as the systems their businesses
depend on *are* damn critical to them!

> Basically, Linux is supported by anarchy. Is that what you want to sell
> to management ?

Sometimes anarchy works out better than a dictatorship. Remember,
companies aren't there to provide support. They are trying to make
money for their directors and shareholders by selling you a contract
and then fulfilling their obligations under it for minimal overhead.
This is not necessarily bad. The saying, "You get what you pay for"
applies. But that doesn't say anything about what happens when you
aren't paying. As your CEO/Managing Director will probably tell
you, when you want things to happen it's who you know not how much
you pay that turns the wheels the fastest. Tell them that not only
can you offer full access to the source but can also give them a
direct line to the guys that wrote the code for the price of a few
beers on expenses and you're talking their language :-).

Mike

--
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:mike@roan.co.uk |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.539 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site