[Liverpool] Money

Bob Ham rah at bash.sh
Wed Jul 25 11:37:21 UTC 2012


On Wed, Jul 25, 2012 at 09:32:23AM +0100, Simon Johnson wrote:
> > I'm missing it.  What do you mean "shipping is a feature"?
> >
> >
> If you don't ever release your product, it's completely worthless to
> anybody.

Here you're implying (but not stating explictly) that "shipping" means
"a release".

> > Debian just didn't _get_ this for a very long time.
> >
> > I am at a loss to find any meaning of the word "shipping" that Debian
> > might not have "got".  I'm definitely missing the fundamental point.
> >
> 
> The gap between major releases for Debian used to be huge.

Here you're talking about the amount of time between major releases.
This is different to your idea of "shipping" given above.

The original fundamental point it seems you were trying to make then,
is that having a regular, time-based release cycle rather than "it's
ready when it's ready" is valuable to some users and that free
software projects should do this.  However, to release software in
this way requires a great commitment and effort on the part of the
software developers.  The fact that many free software projects don't
release software in this way is because it isn't worth it, not because
they don't get it.

Releasing GNOME, X, Debian, or other large software projects on a
time-based release cycle makes sense because they're large.  Doing the
same thing for smaller projects, which constitute the majority of free
software, doesn't.  Suggesting that joe, dict, or hdparm should be
released using a time-based release cycle is just nonsense.


> > > Herd never got it :)
> >
> > I think you mean the Hurd.  Again, though, the fundamental point is no
> > clearer.
> >
> 
> Linux released and iterated, Hurd didn't and effectively died.

The Hurd has made releases:

  ftp://ftp.gnu.org/pub/gnu/hurd/old/

and iterated.  The Hurd hasn't died since those releases were
made.  The lack of recent tarballs is due to the refocussing of the
work of the project's leaders away from the set of servers in those
tarballs, toward the microkernels that the servers run on.  Because
the massive and heavy microkernel work is not evident in that
directory, you could conclude that work on the Hurd had ceased.
However, that conclusion would be wrong.

> You could wave your arms and say, "It's still here, it's still here." but
> the percentage of Hurd installs is approximately 0%.

I won't wave my arms and say it's still here.  Instead, I'll just
point out the flaws in your arguments.

Firstly, the number of installs is an indicator of the popularity of a
software project, not its health.  The popularity of a software
project is not the same thing as its health.  Secondly, using the
number of installs as some indicator implicitly assumes that the
project is intended to be installed.  The Hurd is in development; it
is not intended to be installed yet.

A valid and useful indicator of a project's health is the rate of
commits.  Using that indicator, you can see that the Hurd is not now,
nor has it ever been, in danger of dying:

  http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/


-- 
Bob Ham <rah at bash.sh>

for (;;) { ++pancakes; }



More information about the Liverpool mailing list