Hi Nick,
Although I don't think an open letter would do much harm, I'm not sure
it would do much good, frankly. Although I agree with you that lock-in
strategies are diminishing in their importance in software given the
net, in my experience it is *very* hard to convince commercial
orgs...who are fighting with one another for these audiences...for
different reasons...to change these ways. IMHO, for many it's built
into their way of thinking about business (unfortunately).
But I don't wish to be discouraging (even if that's the effect).
Perhaps an open letter would be a reasonable idea...especially if it
came from a non-commercial entity. I would support it.
Scott
P.S. correction:
Also, such an approach minimizes the effort in creating multiprotocol
clients...not that it doesn't eliminate it, but it does reduce it to a
more manageable level for client developers.
should be:
Also, such an approach minimizes the effort in creating multiprotocol
clients...not that it eliminates the effort, but it does reduce it to a
more manageable level for client developers.
Nick Vidal wrote:
How can Facebook (and others) win by adopting XMPP to its full potential?
If we can answer this question and write an open letter to Facebook,
Google, Yahoo, Microsoft, Twitter, etc, successfully making them
realize that this is the way to go, inviting them to have access to
these valuable resources created by the XSF, then we all win. Are
lock-in strategies still benefitial for them in this new scenario? I
don't believe so, and I believe we can convince them of that. So how
about writting an open letter to these influential companies? Who
thinks this is a good idea?
On Thu, May 15, 2008 at 4:44 PM, Scott Lewis <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Folks,
(Lurker materializes)
One comment I would like to make about this discussion of whether
or not to work on multiprotocol clients/i.e. whytransportsmatter.
It's not realistic IMHO to expect that the whole world will
transfer to open protocols/XMPP overnight...as much as some of us
would like to see this happen. Rather I think the key to making
this happen is make such transitions as easy as possible...by:
1) Having lots of clients (whether single protocol or
multi-protocol) so that UI innovation can occur and create new
user value
2) Having lots of good clients
3) Having open clients (open protocol at least...and preferably
open source implementations)
As important as it is, I think it's still very hard to convince
users that they should choose interoperability over UI features.
So for interoperability to matter to users, open clients have to
be as good, numerous, and innovative as well as support
interoperability. Further, multiprotocol clients can expose the
value of interoperability to users while still giving them what
they want: easy/familiar connectivity to others.
In order to help 1, 2, and 3 along, I/we have taken the approach
of creating protocol independent communications APIs as part of
the ECF project: http://www.eclipse.org/ecf. It's our hope that
by creating a protocol-independent, open and extensible 'presence'
API (as but one example) it makes it possible for developers to
create either single protocol or multi-protocol clients more
easily/quickly/with higher quality, and without taking a least
common denominator approach to features (because both the core and
all ECF APIs are extensible at runtime via OSGi either in servers
or client applications).
Also, such an approach minimizes the effort in creating
multiprotocol clients...not that it doesn't eliminate it, but it
does reduce it to a more manageable level for client developers.
Anyway...I'm happy about the Facebook announcement too :).
Scott
Sander Devrieze wrote:
2008/5/15 Nick Vidal <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Sanders: you do support users who use AIM and MSN, since
you *waste your
time* making sure coccinella works with transports. And
you do support users
of Microsoft Windows, since you *wast your time* making
sure coccinella
works in Windows. And this is a good thing! Thank you! :)
My reply is here as already said before:
http://coccinella.im/whytransportsmatter
