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

[Alex Jones]

On Sat, 2007-09-22 at 17:50 +0200, Robert Martinez wrote:

> Sander Devrieze wrote:
> > 2007/9/22, Robert Martinez <mail at mray.de>:
> >   
> >> Hal Rottenberg wrote:
> >>     
> >>> Can someone justify the existence of this field?  I don't think it's necessary.
> >>>
> >>>
> >>>       
> >> The vendor lock-in field marks projects that allow users only to use it
> >> with only certain accounts.
> >> google talk would be the most prominent here.
> >>     
> >
> > Then you should choose something else than vendor lock-in: I also
> > would call vendor lock-in all undocumented extensions to XMPP. I also
> > would call all documented extensions without any interest and help of
> > the software project to get them standardized in the future, vendor
> > lock-in.
> >
> >   
> This is about a client software listn not a documentation or extension 
> judgement.
> And if the -> jabber <- client does not actually work if you don't have 
> the "right account" it is something very special.
> The vendor lock-in field is thought to warn users (there is a small lock 
> icon behind the name).
> Every user expects that jabber is open after all!

Hang on a minute... I think you're missing the point, Robert. There is
no vendor lock-in here. A Google Talk user can take his roster and
migrate to another XMPP service with no problem whatsoever.

Please don't discourage the audience from joining federated services, as
ultimately, that is all that matters, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/webteam/attachments/20070922/f8a4b508/attachment.htm