The question of whether to open source the wireless village code on onesoup came up before, but I thought I should revisit it now to gather more feedback, and open the conversation.

As I have blogged about in the past, I am fully re-writing the system to move to XMPP. All the code, obviously, is now written in Python. The new architecture consists of a twisted HTTP server and TCP server (for CIR) together with client interfaces to XMPP. Actually, in retrospective, the architecture is not very dissimilar to the one I would expect for a BOSH Connection Manager.

I am considering the pros/cons of opening the project under an open source license. The obvious consequence of opening up would be that anybody could setup their own onesoup server, i.e. a Wireless Village Connection Manager against XMPP backend(s). In other words, any XMPP admin could install onesoup and get their mobile users to access XMPP through the built-in IMPS client on the phones.

But there is a much more important aspect to be considered: interoperability between WV domains. Today, the Wireless Village Server to Server Protocol (SSP) is fairly useless. But if onesoup became a common software gateway for the mobile world to access the XMPP federation, we’d then be able to use the XMPP S2S to replace the IMPS SSP, and then achieve true mobile instant messaging interoperability. And, the thing is, one the key reasons, or perhaps the key reason, SMS triumphed as a disruptive messaging technology was interoperability. You can send and receive messages to your friends, regardless of their operator. Interoperability is the quintessential property for open communications.

But there are other reasons I can think as of why to open source something like onesoup. First, there are number of players competing with proprietary mobile instant messaging technologies, and a really great way to compete effectively with them is through openness. Then, there are also pure technological advantages in IMPS for the mobile world vs raw-XMPP or HTTP-XMPP (BOSH), such as transactional message acknowledgements, binary XML and CIR (SUDP, that is). So in a way, an IMPS CSP HTTP connection manager like onesoup, could be the key for spreading XMPP to the mobile world.

Obviously, there are the financial aspects to be considered too. Open sourcing needs to make financial sense, not only to me, but to any other party that could potentially become a contributor. Sure, there are personal reputation, consulting, contractor, support, etc. opportunities associated, but let’s face it, it’s very hard to make a living out of writing open source software.

Because that’s really the trade off, moving from being a service provider, to being a software provider. I believe Jabber did not get acquired by CISCO because of their service (under the jabber.org domain), but because of their software, talent and responsibility for the standard. On the other hand, the success of Jabber Inc. can be largely attributed to the success of the jabber.org domain.

At this point I’d like to open the conversation, both with end-users and potential contributors alike. Do you think there is space, interest and returns for creating an open source wireless village server to interface to the XMPP federation?

I was implementing last night the integration with Jabber/XMPP using the Smack API, when I came across one of the most interesting features in XMPP that I was not aware of.

Every JabberID (JID) consists of user@service/resource, so for example, one could have a JID like donald.duck@gmail.com/Adium meaning:

• username is donald.duck
• service is gmail.com
• resource is Adium

but the thing that I found more curious is that nowhere it says what the hosts are to establish a TCP/IP connection!! Actually, you could specify them, but that’s unnecessary, and you shouldn’t!

XMPP is expected to use SRV DNS Records to discover the service, so in this case, using dig, one would discover the host for jabber (“_jabber”) service using TCP (“_tcp”).

$ dig _jabber._tcp.gmail.com SRV

;; QUESTION SECTION:
;_jabber._tcp.gmail.com. IN SRV


;; ANSWER SECTION:
_jabber._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server1.l.google.com.
_jabber._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server2.l.google.com.
_jabber._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server3.l.google.com.
_jabber._tcp.gmail.com. 86400 IN SRV 20 0 5269 xmpp-server4.l.google.com.
_jabber._tcp.gmail.com. 86400 IN SRV 5 0 5269 xmpp-server.l.google.com.

The fantastic thing is that Smack does this behind the scenes on the XMPPConnection class. Kudos!