[vorbis] How to make Vorbis popular

[Craig Dickson]

rob1 at rekl.yi.org wrote:

> On Fri, 11 Jan 2002, Victoria E. Lease wrote:
> 
> > Do mp3 users do this same thing, re: LAME? I think LAME is still
> > making encoding quality improvements (albeit not as drastically in
> > the past), and I know people who are using it to encode all of their
> > music in this "mp3" file format for which an optimal encoder has
> > yet to be produced... ;)
> 
> Huh?  It's good that LAME is still making encoding quality improvements.
> And it's -released- software.

So you're complaining about the version number being < 1.0? That seems
silly.

> If you want to talk about other software which is changed after it's
> released, let's talk about..  well, let's talk about every software
> program out there.  That's what I was talking about in my last post:
> "released" does not mean "completely finished, never making another change
> again."  The nature of software (and most products) is that when it's
> released, it's usable.  It may not be optimal or all-encompassing, but for
> that major version, you can count on the interface/format being
> consistent, the user can adequately use the product for it intened
> purpose, etc.

You can count on that for Vorbis now too. The file format is frozen, and
has been for several months (since at least beta 2, I think, if not
earlier). The decoder, aside from fixes for any bugs that may be found
before the 1.0 release, is done. All they're doing now is tuning.

> Understanding the time-to-market vs. the perfect product argument is
> important, and not too difficult.  Most companies who strive to put out
> the "perfect product" don't exist long because their competitors have
> released something that, while it may not be defect-free or as fast, is
> making money.  They can then revise and improve their product, so the next
> release is better/faster/etc.  If you never get your product out the door,
> you lose market share and everything that goes along with it.

True, but Vorbis is not suffering from never-ending feature-creep. The
developers have a specific set of goals, which I don't think has changed
significantly in some time. They want 1.0 to meet all these goals so
that when it comes out, there will be a very compelling argument that it
really is better than MP3 (higher quality, more flexible, support for a
wider range of sources, multiple-channel support, etc.).

There is room for debate about whether they should have just called RC1,
RC2, or RC3 "1.0" and promised better tuning for 1.1 or 2.0. Nobody
really knows the answer to that, since you can't run a complete
simulation of the world twice to find out what tactics produce the best
result (defining best result as the closest approximation to total world
domination, of course). The developers are sticking to their plan, and I
think they will get the product out when it's ready. Probably in the
next few months, I would guess.

I think your analogy to commercial product development ("Most companies
who strive...", etc.) is inapt. Profit-seeking corporations have a lot
of pressure on them to generate income because they have investors who
want to see results, and they spend lots of money on plush offices and
glitzy marketing campaigns. These pressures don't really exist for a
non-profit "because we love it" operation like Xiphophorous.

As for market share, the history of personal computers has a number of
examples of established products suddenly dying because something better
came along. Nobody uses .ARC compressed archives anymore, and in fact I
think that's the most exact analogy from history that one could draw.
The arc utility was free for personal use, and very popular. Then pkarc
came along, and the company behind arc started talking about lawsuits,
so pkarc was rewritten as pkzip, and it was clearly better. Within
months, arc was history.

Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 233 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis/attachments/20020111/9fddc26e/part.pgp