(Off Topic ) Open Source: The Model Is Broken ??

Les Mikesell lesmikesell at gmail.com
Sat Dec 6 22:55:54 UTC 2008

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 at gmail.com

More information about the users mailing list