> before you go to far in condemming companies, note that even transmeta is
> in this situation with their docs. when Linus was asked about
> documentation for the longrun config stuff he stated that whil trasmeta
> was planning to release both docs and source, they were not willing to
> release them in the state that they are in currently.
>
Yes I did read what Linus said, and I did consider that when I wrote this, I
still don't feel that it should stop them if they plan to release it and it
might be quite some time before they have it in what they consider a
releasable state (if a company wants to clean things up before releasing
them, great, but if it's going to be a while, I'm saying that they
should *consider* simply releasing them in a given state)
> and to be perfectly honest, they do have a point, if the internal
> documentation is so poor, releaseing it will cause a flood of calls for
> clarification of the docs. it's better to spend the time before release to
> fix it then to spend the time (a much larger chunk of time) after the
> release explaining it multiple times AND fixing the docs.
>
> sometimes companies are not willing to spend that much time on what they
> see as a minor market. that's just the fact of life.
>
> the real fix isn't to yell at the companies, it's to show them that it is
> a significant market and worth them spending their money there.
Please understand that I'm not really condemming anyone or anything, I
saying that I did not see the point in keeping it all closed simply because
the source/docs are a mess.
I do understand that they may have reason for not wanting to release things
in that state, but I'm not sure it should stop them if at all possible, as
even messy, undocumented code, and bad spec sheets, is better than nothing
at all.
There's something else I was going to add in my original note but failed to.
(warning, painfully obvious paragraph ahead)
I belive that if companies would write drivers and specs from the beginning
with the intention of releasing at least the specs if not the specs and
source, then we'd probably wind up with better products as well as cleaner
code and spec sheets.
Prehaps it's time someone gave the companies a little nudging (possibly with
a penguin beak? :).
>
> David Lang
>
-NK
>
> On Mon, 19 Feb
> 2001, Nicholas Knight wrote:
>
> > Date: Mon, 19 Feb 2001 03:28:56 -0800
> > From: Nicholas Knight <tegeran@home.com>
> > To: Jeff Garzik <jgarzik@mandrakesoft.com>
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: [LONG RANT] Re: Linux stifles innovation...
> >
> > ----- Original Message -----
> > From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
> > To: "Werner Almesberger" <Werner.Almesberger@epfl.ch>
> > Cc: "Henning P. Schmiedehausen" <hps@tanstaafl.de>;
> > <linux-kernel@vger.kernel.org>
> > Sent: Monday, February 19, 2001 3:07 AM
> > Subject: Re: [LONG RANT] Re: Linux stifles innovation...
> >
> >
<snip>
> > While I understand that internal docs and source are often simply a
mess, I
> > fail to see why this should prevent a company from releasing specs or
> > source.
> > Sure somebody will come along and say "What on earth were you people
> > THINKING?!", and then they'll get over it and do something useful with
the
> > specs and/or source to the drivers (or if they don't, somebody else
will)
> > I seriously doubt it'd lead to a company seeing a drop in sales because
of
> > it... and even if they did, I'd say it's a calculated risk, as they
could
> > well pick up a higher number of new customers than the number of old
> > customers they lost due to wider ranging support.
> > And even if their specs and code were the worst peices of trash on the
> > planet, I'd still thank them for opening them up to the public.
> >
> > -NK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/