[jdev] My GSoC project : to continue the PyMSNt development.

Sander Devrieze s.devrieze at pandora.be
Tue Apr 8 11:46:02 CDT 2008

2008/4/8, Peter Saint-Andre <stpeter at stpeter.im>:
> I am not convinced that working on transports is an
>  appropriate topic for the Google Summer of Code. I plan to give my votes
>  to projects that improve or extend XMPP itself, not provide bridges to
>  closed technologies.

I do not agree on this. Good transports are advantageous for XMPP. As
I already wrote on http://coccinella.im/whytransportsmatter --> "More
and better transports are needed to allow XMPP clients to compete
effectively with the key feature of multiprotocol clients:
interoperability with multiple closed networks. Multiprotocol clients
can't innovate as fast as XMPP clients can (see above), so we can
tackle them on the interoperability feature which is XMPP's core

Every user that uses a transport instead of the official client to
access the closed network or instead of a multiprotocol client
*contributes* to XMPP in these ways:
* Network effects: even if this user only uses the XMPP client to
communicate with people on closed networks he *needs* an XMPP account
on a server. There are even transports that can detect if one of your
contacts on a closed network is also using a transport so that you can
add his XMPP ID instead!
* Testing: every additional user may find bugs in the XMPP client or
the XMPP server. Fixing these bugs will help the broader XMPP
* Reducing client choice and user experience on closed networks: a
stronger focus of the XMPP community on transports will reduce client
choice and user experience on closed networks. This will increase the
value of XMPP for users. See my article for more information on this
one or ask me if you don't understand this.
* Attracting more developers to the XMPP community: a user using an
XMPP client, an XMPP account on an XMPP server, and a transport may
attract people to contribute to all of these. If this user would have
used a multiprotocol client, this will only attract people to
contribute to the closed protocol plugin of this multiprotocol client
and the user interface of this client. Such contributions will benefit
the XMPP community close to zero: only contributions to the user
interface may be beneficial also this also may be seen as a
disadvantage (e.g. ugly XMPP-specific dialogs in Adium).

Mvg, Sander Devrieze.

More information about the JDev mailing list