[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OpenDivX] How to make an open-source project fail

During the past month that I've been exposed to the opendivx project, a
couple of things have really annoyed me.  In the hope that perhaps some of
these things can be corrected, I submit my rant list to any and all who care
to read it.

Herewith my rant:

If the intention is *really* to make DivX a household name, it might help if
attention is paid to the following items:

There is nothing in this world that cheeses me off more than more than this.
Not only is the current documentation hopelessly out of touch with where the
code is now, it is actually incorrect.  I'm referring to the "Codec Core
Interface.txt" document in the root of the divxcore source tree.

This "document" lead me so far down the proverbial garden path its not even
funny.  EITHER have correct documentation (or even just up-to-date sample
applications showing how to use encore and decore), or don't have any.  For
an open-source project, wrong (or even incomplete) documentation can spell

Proper release tagging would be very useful.  If I only want to build the
latest stable libdivxdecore on my platform, I shouldn't have to get involved
with the vagaries of the bleeding edge development code.  If each "stable"
release was appropriately tagged in CVS, I could simply get the particular
release I wanted.

In a recent email I was told to use the 4.0-a50 version of the decore.
Where the heck do I get the source code for 4.0-a50 if the source tree isn't

If tagging the source tree properly is too much trouble, a series of
up-to-date tar files with stable source (i.e. which compiles correctly and
actually includes all required source files) might be nice.

The nonsense I've had to go through to build decore under Linux makes
working with divx anything but fun.
The current makefile (divxcore/decore/build/linux/Makefile) doesn't include
src/mmx/yuv2rgb_mmx.c or src/addblock.c.

The current decore makefile also doesn't install, autoconfigure, etc.  Given
the ease the GNU Build System provides, this situation *really* shouldn't

I shouldn't have to sit with gdb to figure out if decore is working
correctly or not.  A simple set of regression test applications should be
included in the source tree.  Most open-source projects I've worked on allow
me to do a "make check" to determine if everything is ok.  Then I can get on
with the job of using the code for something useful, instead of trying to
work out just why divx isn't working.

I really shouldn't have to wonder if decore is working correctly, or if
perhaps encore is not working correctly, or if perhaps the interface to
decore has changed and no-one bothered to mention it, etc.

You'll probably tell me that then I shouldn't be involved with opendivx.  If
the intention *is* to make opendivx widely accepted, then more is needed
than just a working encore/decore.  My interests lie in applications that
use encore/decore and not in the actual encore/decore themselves.

In summary, I want to get on with writing applications that use decore, not
debug decore, its makefiles, source tree, etc.

OpenDivX mailing list
[email protected]

Reply To Poster

Local References / HOW-TO / FAQs