hplip: hp-toolbox advertising?

[Bernard Johnson]

Rahul Sundaram wrote:
> Bernard Johnson wrote:
> 
>> Thank you for the clarification.  The only problem I see, if I
>> understand you, is that the mp3 codec is sole-sourced to Fluendo.  I
>> understand that Fluendo is the only vendor to providing a legal
>> alternative today, but we should have the ability to allow multiple
>> vendors at that step.
> 
> We do it this way because
> 
> * Fleundo is the company that employs many (most?) of the gstreamer
> developers that provides us with a Free multimedia framework. This is
> one way of acknowledging their efforts.

For the record, I am not against this at all... but

* Hewlett Packard is the company that employs many of the hplip
developers that provide the free hplip software.  This software supports
1100+ printer models.

> * It is a gratis solution and a commonly requested feature.

The hplip software is GPL and not intentionally feature-limited in any
way.  One must assume that if you want to print to your HP printer, it
would be a commonly requested feature given the market penetration of
HP.  (It was important enough to include at FC-4 anyway)

> * If we provide redirects it is just a additional step over making it a
> click through option which is more usable. Like you said there really
> isn't any choice of vendors to provide the same feature and providing a
> theoretical level playing feature for a gratis component does not appear
> to important as opposed to the usability advantage at this point.

There are no vendors that provide the same level of functionality as the
hplip software.

> If there are other vendors in the future we can reconsider what we need
> to do. The hooks for codec buddy are already in upstream gstreamer,
> nothing is hard coded  and we can change this very easily.

Today, we do not allow the hp-toolbox to have an icon on the menu.

Now,

I do not disagree with the direction taken with CodecBuddy (this I
stated in my original email).  I very much disagree with lack of
impartiality between vendors who are both supporting Linux.

Given that the original argument against the hp-toolbox menu item was
because it was advertising, the Fluendo agreement goes /far/ beyond that.

I should also point that that the "advertising" HP gets has no directly
-tied revenue (ie. it doesn't not direct anyone to a website to purchase
anything).  At the same time, Fluendo will directly profit from the
CodecBuddy tie-in.


And please, before anyone goes down the "but I don't like the HP
software" rant road, get a reality check.  Show me software that can be
used to get the same functionality.

We told HP that we wanted Linux support, and not only did they give us
printing support, they supported the whole MIO ball of wax.  As far as I
understand it, they are also paying for the continued development of the
software AND support in the newsgroups.

Compare that to Broadcom(wireless)/Nvidia/ATI who we also asked to
support Linux.  Two companies gave us blobs and said "trust us, it's
great software!", while another said "get bent"[1] and the only reason
we have support at all today with this vendor is because someone reverse
engineered the chip and developed the ability to load a firmware blob.

All the "free software zealots" say to vote with your pocketbook.  I
did.  I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT.  And
not just a blob, real GPL software.  Now I hear total bogus arguments
like "it's advertising" [but don't look at these other things that are
advertising as well that we will let slide] or "yeah, it's free but it's
not good enough"[2][3].

This is exactly the attitude that will cause Linux to not get any
support by vendors.

The fact of the matter is that it takes vendor support to make
Fedora/RedHat anything other than a toy operating system for many uses.
 At many junctures, we have to make conscious trade offs between
idealogical beliefs and functionality.  That trade off may be a little
recognition of the hard work that someone / some company put into the
software, and I say that's great, give it to them.

But to actually go out of your way to make it harder for the end-user it
beyond comprehension.  There are already multiple bugs filed on this
issue, and I would have filed one too had I not looked at the spec file.
 It's not like Linux doesn't have enough hurdles (potential patent
pitfalls, trademark issues[4], brand recognition, user-base
fragmentation, etc), let's not create more problems just for the fun of it.


[1] That wasn't the real response, but since they are ignoring the
issue, it's clear that they don't care.

[2] Where "good enough" seems to be based on idealism and by people who
don't even use the software.

[3] I can consistently break the bcm43xx stack, but you don't see me
screaming that it sucks and we should disable it.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233729

[4] See my response in this thread regarding potential bluetooth problems.