[gst-devel] Indifference is not an argument!

[Erik Walthinsen]

A common theme throughout your email seems to be the assumption that we
are here to serve you.  This is simply not true.  The programmers involved
in this project are doing this almost entirely on their own time, for
their own reasons.  Nowhere have we signed up to provide support for this
project other than what we willingly provide.

On Mon, 24 Feb 2003, Dennis Heuer wrote:

> But there is no problem in skipping Hermes on a modern GNOME/linux
> system, except you want to have video support in the single product
> gst-player.
This is how things work:  Libraries that provide a certain service (in
this case colorspace conversion) exist to be used by other libraries and
applications so that they do not have to implement the same operation
themselves.  This is called "code re-use".  When library or applications
programmers decide that they want to "reduce dependencies" by implementing
such operations themselves, they end up with their own codebase which is
inevitably full of their own bugs, which have to be tracked separately
from the same or other bugs in functionally identical pieces of code
mainained by someone else.  Because these chunks of code are not the
primary reason the author is writing whichever program, they are left to
rot, and the bugs remain.

On the other hand, you have programmers who understand the pitfalls of
creating a zillion copies of a routine with their own bugs and flaws.
They search for libraries that already do what they want, and make use of
them.  Those writing new functionality write it in the form of a library,
so it can be used by more than just their own project.  Imagine if no one
had ever bothered to write libc.

Because of the evolution of open-source projects, you often have libraries
that are either fundamentally flawed, or are never adopted by enough users
in order to attain a fully "maintained" status.  Hermes is in both
categories, yet when the original decision was made to use it, it was a)
still under development, and b) used by more projects.

Hermes has not been removed from the core colorspace element because there
has been no viable alternative so far.  We have not gone the route of
merging Hermes into the colorspace element because doing so would not be
worth the hassle in the long run.  It has also not been that big of an
issue, until now.

> I understand that Hermes is needed, I already wrote this, but talking
> about this decision should be legitim.
No one has made the claim that it is not legitimate to discuss the
requirement of Hermes for core video support.  What we are not exactly
thrilled with is your approach to bringing up the issue.  Instead of
politely asking why we are using Hermes for colorspace conversion and
whether there were any plans (or God forbid, whether you could even
*help*!) to remove it in favor of some other solution, you start out by
complaining that you have to install something (which BTW is *very* small
and trivial to compile) that you didn't want to, and so you can't get all
these neat features.  And <GASP>, look at that HUGE dependencies list!

It is precisely that attitude that provokes us into *not* rushing out and
removing Hermes from the dependencies list YESTERDAY.

> It is also legitim to install from source. The 0.01% have the same
> rights like others.
Yes, you have the exact same list of rights, and the exact same list of
things you do *not* have a right to.  Quite high on that list of things
you *don't* have a right to do is expect developers who work on a project
for fun to cater to your every requirement.  If you want to force us to do
X, Y, and Z, you have to pay us (resume's to be handed out at the door).

> You can decide if this is of interest to you but, again, it is legitim
> to discuss about Hermes being a main dependency, atleast if you are
> interested in your users.
We are *always* interested in what our users need, because we are users
ourselves.  Odd are that if someone runs into a problem or a new feature
they need, one of the developers needs or soon will need that same problem
fixed or that same new feature.  Otherwise, we tend to leave well enough
alone, as is the case with Hermes so far.

> Maybe you should re-think about what your position as the developer
> implies.
Maybe you should re-think what your position as a *user* of *free*
software implies.

> P.s.: If business service people would argue your way their companies
> would go bankrupt.
If you actually paid us for a service, we would be obligated to respond
appropriately.  Since this project was written for fun, we are *not*
obligated to "support" it in the same way that a business should support
their products.


Now, because it is indeed relevant, I will explain our plans for replacing
Hermes:

We are working on a number of projects under the codecs.org umbrella
project (see http://codecs.org/) focussing on high-performance routines
and infrastructure for codecs and related systems.  One of these is called
'libcolorspace' and will contain both highly-optimized routines for
various processors (SSE, Altivec, etc.), and general conversion routines
that support any-to-any conversions.

libcolorspace will itself depend on Specialib, which is the main
infrastructure piece necessary to actually select the highest-performing
versions of the routines available.

This puts *two* libraries on the system as a requirement for the default
'colorspace' element.  I suspect this will make you twice as likely not to
use gst-player, but for reasons outlined above, I care enough to assist
where I can, but I do *not* care enough to design my code in a
less-than-optimal manner.

The reason we are building Specialib, libcolorspace, and all the other
libraries on codecs.org, is so that people will use them.  I am personally
*sick* of everyone and their dog writing their own iDCT, their own
colorspace routines, their own this and that.  Every single one of them
has one or more significant flaws, the most common being that it simply is
*not* the fastest available routine of its kind.  Specialib and
libcolorspace are an attempt to gather the fastest and best routines into
one place, so that other authors will *not* have to continually re-invent
this wheel.

If no one else *ever* uses these libraries, that will not change the fact
that they are still the best way to implement a colorspace conversion
element for GStreamer.

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_