[webteam] vendor lock-in, what the .... is it?

[Susan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 24 Sep 2007 13:56:26 -0400
"Hal Rottenberg" <hal at halr9000.com> wrote:

> On 9/24/07, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> > There *are* clients that are locked down to a specific service. IMHO
> > they are not of general interest (though they may be of interest to
> > users of that service), so perhaps it doesn't make sense to list
> > them at jabber.org anyway, because you could argue they are not
> > jabber clients in the first place!
<snip>
> My point is this: if it speaks XMPP and it's considered a client, that
> should be enough.  And if the vendor wishes to self-identify the
> client's closed nature (in the description field), fine, and if not,
> fine.  If a user wishes to add a comment to the node, fine.
> 
> If everyone feels we must have a field to track this, which I still
> disagree with, at least come up with something better-sounding without
> a negative connotation.

Oh, my.  I sat down to catch up on the mailing list and I couldn't
believe that this is so hotly discussed!  I am really disappointed that
the responsible approach here isn't obvious to all.  Since I'm coming a
little late to the party, I'm going to try to address the main points
I've seen from both sides in one post. Here goes:

* Clients that are vendor-locked to a particular server are not real
jabber clients, and shouldn't be listed at jabber.org at all.
* We should list as many XMPP-capable clients as possible, in order to
offer the greatest selection to our users.

XMPP was developed to give users choices with regard to their IM usage
for the first time.  I would think it obvious that we should show them
the widest possible range of clients.

* It's not our job to advertise corporate products.

"Corporate" is not equivalent to "has nothing to offer the community".
I certainly wouldn't give corporate products special treatment, but a
client is a client.  Also, by shunning corporate and/or currently
vendor-locked XMPP products, we forfeit any chance of leading them to
more open practices.

* If a product has desirable features, the vendor lock situation
shouldn't matter to most users.

That is not for us to decide.  Remember, the point here is choice.  We
should give users all of the information that we can, and let them
decide what is or isn't important.  Even on this list we have differing
opinions on the merits of vendor-locked products -- is it right to
assume that the same isn't true in the wider jabber community?

* Most users don't know enough about XMPP or the concept of vendor-lock
to care anyway, we shouldn't filter by vendor lock because we risk
confusing them, but with no real reward.

Users are individual.  Some will care about vendor lock, some won't,
just as some will care about Jingle support, or file transfer support,
or gpg support, etc. and others won't.  That's the whole point of
listing clients and their characteristics -- to help each user come to
an informed opinion about which client will best fit his/her individual
needs.

Most users didn't know what an open protocol was until we educated
them.  Let's not limit ourselves to the lowest common denominator,
instead, let's raise it.

* Allowing users to filter by vendor-lock or lack thereof is
pejorative, and shouldn't be done for that reason.

If a user doesn't want a vendor-locked application, isn't that choice
his/her right?  That's what this is all about, remember?  Choice.  

If it is true that users are less likely to choose vendor-locked
products, (a point I'm not prepared to concede) then the clients locked
to particular servers will either drop the lock, or fall to the
wayside.  That's life in open source and open protocols, as well it
should be.  Not only is it not our job, but it does the jabber
community a great disservice, to try to prop up products people don't
want by burying their flaws deep in a queue of comments.

* The term "vendor lock" is pejorative, and should be replaced with
something more positive.

The term "vendor lock" isn't pejorative; that is, it doesn't convey any
negative connotation in excess of its denotation.  It describes, but
does not imply judgment.  Whether or not someone feels "vendor lock" is
a negative term depends on their opinion of the practice.

That said, I don't think that the term "vendor lock" is appropriate to
the application discussed here because it is not descriptive enough.
As stated elsewhere in this thread, there are many types of vendor
lock.  We should more clearly define that this field represents whether
or not a client is restricted to one jabber service, or may be used
with any XMPP-compliant server.

***                                ***                               ***

What this all boils down to is that open protocols like XMPP exist to
provide users with choices about the software and services they
consume.  I fear that the term "vendor lock" is not sufficiently
descriptive for our purpose here, and should be replaced.  That said,
the ONLY responsible course of action is to clearly tag and allow
filtering of client listings by whether or not they are restricted to a
particular service, and let each user decide whether or not that
matters to him or her.

Susan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG+KwbvWyNbJGZcawRArnRAJ97n3e6pvbA8FHhZ91Ug4XM+VYG3ACgzA9R
F3D/jmQQrxjwMMKjJ5/DG9k=
=nDmu
-----END PGP SIGNATURE-----