Thank you!

[Anthony Atkielski]

Paul Schmehl writes:

PS> Not to pick a nit...well, ok...to pick a nit...developers do not
PS> support systems. Support organizations do. If you're going to be
PS> using FreeBSD in a corporate environment then you need to find a
PS> good *support* company that can backstop your local admins. *Then*,
PS> if a problem arises, the support company can deal with the
PS> developers.

I'm not sure that this is much of an improvement.

Still, one of the strengths of FreeBSD is that it rarely requires
support.  It's better to have reliable software with little or no
support than it is to have unreliable software with superb support.  But
in situations where you _must_ have support, just in case, you're often
forced into accepting the latter.  This is one argument in favor of
overpriced proprietary solutions like Windows: Windows may give you a
lot more trouble, but at least you can get support--for a price, alas!

PS> Linux is a good example. Entire companies have arisen merely for the
PS> purpose of supporting the code that's written by Torvald's et. al.
PS> Torvalds doesn't support "Linux". He works with the kernel
PS> developers.

Linux has the same problem as FreeBSD in this respect; all open-source
projects do.  Third-party support is certainly an improvement, but it's
still not the same as proprietary support.

One important difference is that you can sue a proprietary publisher if
the software fails and he does not respect his support commitment; as
publisher of the software, he can be _compelled_ to fix it or pay you
lots and lots of money for failing (or refusing) to fix it.  With
third-party support, this doesn't quite work--you can sue for failure to
perform on the support aspect, but you can't force the third party to
provide a fix, because it's not their code.

PS> Another example - I doubt a single developer who's ever written a
PS> line of code for MS has handled a support call. I wouldn't expect
PS> them to. They're developers. MS has an entire support team for that
PS> (they can afford it, of course.)

Some developers do occasionally intervene on support issues, but it is
true that developers do not answer the phones and don't work on support
calls as a general rule.  That would be extremely expensive and
inefficient from a business standpoint, and developers would probably
leave the company as well (support is really boring).  It would
guarantee that problems actually get fixed, though, which is not the
case with the current technical support arrangement (mostly based on
trial and error--just as it is for most other companies).

PS> So, complaining that the developers don't have the right attitude is
PS> a bit off the mark. Find a local company that is *committed* to
PS> supporting FreeBSD, and you will find the same level of support you
PS> get from RH, MS, or anyone else in the business. The only difference
PS> is, support is "disconnected" from development in the FreeBSD model
PS> whereas it's one and the same company with MS.

That's a critical difference, unfortunately.  It breaks the chain of
accountability.  MS can _force_ problems to be fixed (and can be forced
by others to fix problems) because it owns the code and the developers.
Third-party support organizations can't do this.

It's all a matter of business rather than technical issues, but it can't
be ignored when choosing an OS for large-scale or mission-critical
deployment.  All of the open-source solutions suffer from this problem.
Lack of accountability doesn't matter as long as the software shows no
bugs, but it's a nightmare if something goes wrong--and the mere
possibility of that happening can rule out an open-source solution for
some applications.

PS> Nor would any *decent* support company.

True, but third-party support companies don't own the code.

-- 
Anthony