M. Fioretti wrote:
There is a problem peculiar to the free/open source world in that poor
quality versions of things have no reason to ever go away.
What we're discussing now, that is your "just do it, someone will fix
it" approach, has nothing whatever to do with the software license.
Because we're talking of documentation written, or possibly improved,
by third parties, not the developers.
What happens to the people trying to use it relates very much to the
license, although only as a side effect. Commercial software vendors
tend to maintain their own knowledge bases and attrition takes care of
cleaning up the things that are out of date. With free stuff, you can
probably still find copies of anything that has ever been released and
it will clutter any searches you attempt.
I don't have a solution for this - it is just an observation that if
anyone ever releases bad documentation or even advice, others will
be finding and following it years later via google and other
archives.
but this is a problem only because releasing crap documentation (the
"just do it, someone will fix it" kind) is much, much easier than
releasing good stuff, which is again the only point I was making. In
the Postfix example, if such documentation existed the Postfix gurus
would simply tell newbie "don't read A, read B". Instead they say
"don't read A, read the mountain of over-detailed stuff at postfix.org
even if you could go by with one decent, ten page how-to".
One decent ten page how-to is right for 10% of the installs, a different
ten page how-to would be right for a different 10%. But there's no way
to find the one you need and avoid the others.
I have a different take on this. Complex programs like postfix have
(and need) thousands of options to cover every possible
case... Rather than confuse people who should be just following
standards with the thousands of options they shouldn't touch anyway,
we need a dozen templates for this sort of program.
Right. Now, who could write such good templates, ie distill without
errors those thousands of options and explain the result clearly, in
order to minimize misunderstandings, except the developers themselves
or (much better) some pretty good technical writer who's either paid
to do it or already financially secure?
None of the above. Only a person who actually runs the program in
production over a period of time will have a usable template, and it
will only be suitable for some subset of other situations. The problem
is that he has no way to share his work with the thousands of other
people who could use exactly the same setup, and those thousands of
people have no way to find the dozens of good examples that exist whose
owners might want to share them. For the code, there are source code
archives where you can easily track changes over time and alternate
branches of development - for a very small developer base. For the much
larger user base there is only a choice of 500-page books detailing
every obscure config option or the single default config that comes with
a distribution.
We keep going back to the original point, don't we? (and probably
could well stop here, since we're not the ones who could fix this and
it isn't Fedora-specific in any way)
Who could fix it? What we need is a location and mechanism for admins
to share their config files with similar tools that code developers have
to maintain versions/branches etc., and view diffs across them. And to
whatever extent possible, fedora could produce alternative packaged
configs on the order of the caching dns server that would help some
subset of users. Making an end user need to know about a million config
options to create one of a dozen or so common setups doesn't make much
more sense than just throwing the source code at them.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
