Coccinella - Various

Design Great Software with Coccinella

sander — Mon, 04 Aug 2008 20:20:06 +0000

Ok, I admit this must be one of the laziest blog articles I ever wrote. It only consists of 5 parts:

First, one big quote from an outstanding article:
"Design is high-bandwidth, the Net is low-bandwidth.
Volunteer software projects are usually highly distributed, with contributors in different cities or even different continents. So project communications are mostly plain text, in e-mail, instant messaging, IRC, or a bug tracking system. But interaction design is multi-dimensional, involving the layout and behavior of elements over time, and the organization of those elements in an overall interface.

When developers are in the same room, they can discuss interaction design using whiteboards, paper prototypes, spoken words, and gestures. But on the Internet, these often aren’t available, making discussions much slower and prone to misunderstandings.

Solutions: Develop and promote VoIP, video chat, virtual whiteboard, sketching, and animation software that allows easier communication of design ideas over the Internet. And whenever possible, hold physical meetings for developers to collaborate in person."
Followed by two related screenshots of Coccinella:
Plus, a related link:
Collaborative Whiteboard Tutorial
Then, a smaller quote from Matthew Paul Thomas's article:

"Often these teams don’t communicate with each other frequently. And unlike their proprietary competitors, they nearly all have different release cycles. This makes usability improvements difficult and slow to implement, if those improvements involve coordinating changes across multiple parts of the system."
And finally, two links related to the small quote:
Economic clustering and Free Software release coordination
The Blessings of Synchronized Releases

Story type:

Sander's blog

Various

Coccinella The Movie

sander — Sun, 22 Jun 2008 19:47:37 +0000

Story type:

Sander's blog

Various

Facebook Going XMPP - Never Support Walled Gardens

sander — Wed, 14 May 2008 21:23:30 +0000

It was announced yesterday that Facebook Chat is soon going to use the open standards XMPP. This means that in the near future you will be able to use Coccinella and any other XMPP client to connect to Facebook Chat. We don't even have to provide you with a new Coccinella release, thanks to the merits of open standards.

When reading this great news, I remembered that not so long ago Adium and Digsby announced support for Facebook Chat. Obviously, the support they added is for today's closed Facebook Chat protocol, not for tomorrow's XMPP based service. Both applications already support the open instant messaging standard XMPP since long. This means that these projects would have had support for Facebook Chat anyway if they just had a bit more patience. I wonder how frustrated these developers currently are, now that they know that their brand fresh code will become obsolete even before it gets in a stable release.

So, in fact, instead of using their scarce time to implement sexy new features that are interesting for all their users, Adium and Digsby developers wasted their time to support a walled garden protocol of which the wall fell ultra fast. I must admit that I now have a small grin on my face :-)

However, I also have a bad feeling. What if not only Digsby and Adium were so fast in adding support for the closed Facebook Chat, but also others such as Pidgin, Trillian and many others? Would there still have been enough pressure on Facebook to make the decision to switch to XMPP so fast? I guess XMPP support wouldn't have been that urgent for Facebook any more.

I hope these developers have learned their lesson: never add support for new walled garden networks to your client. Wait as long as possible and direct all requests from users who are requesting support for a new walled garden system to the owner of walled garden. If you don't do this and try to attract users away from other instant messaging clients, by adding support for a walled garden network, you may get frustrated when this network switches to XMPP. Plus, your support reduces the pressure from users on this walled garden network to open its entrances. All in all, what you thought was a feature, in fact is a misfeature.

If waiting not helps to get a walled garden to show its flowers to the public, you can better use server-side XMPP transports. Transports have several strategic advantages over native client support, they provide basic interoperability to please your users, when shaped to die fast they don't lead to much frustration, and they do not lead to competition amongst multi-protocol clients based on the numbers of walled gardens they support. Better compete on *real* features.

To conclude, I also hope that developers who are still adding new features in multi-protocol clients for the Yahoo and ICQ/AIM protocols are aware that they can experience the same frustration as described. Indeed, these two walled garden networks are already experimenting with XMPP.

The future is XMPP. Walled garden networks are finally getting a thing from the past!

Story type:

Sander's blog

Various

A Fool's Guide to Bypass Openfire's Client Control

sander — Wed, 14 May 2008 13:21:42 +0000

Today the Openfire Team announced the open sourcing of the Client Control module for Openfire. This module promises it "allows to specify which XMPP clients are allowed to connect to the server".

In this guide I will give you instructions about how you can bypass this restriction and always use Coccinella. Don't be afraid that this tutorial will be too difficult for you! Thanks to Coccinella's flexible branding features, even a child can do this. No, you don't have to recompile Coccinella or apply some difficult hacks. It's only a matter of adding 1 small line to Coccinella's preferences file and then restarting Coccinella! Read further to see how easy it is to bypass OpenFire's Client Control module.

Locate Coccinella's preferences folder on your platform:
- Windows: C:\Documents and Settings\UserName\Application data\Coccinella\
- Windows Vista: C:\Documents and Settings\UserName\AppData\Roaming\Coccinella\
- Mac OS X: /Users/UserName/Library/Preferences/Coccinella/
- Linux: /home/UserName/.coccinella/
- Portable Coccinella, the folder CoccinellaPrefs in the same folder as the Cocccinella executable
Use your favorite text editor to add the following line to the preferences.rdb file (replace "Psi" with another client name when it is also blocked):

*appName: Psi
Restart Coccinella; if all went right you will see that the window title changed to "Psi" and you will be able to connect to a restricted OpenFire server.

As this short tutorial shows, the kind of protection that the OpenFire Client Control module promises is so weak that even a child can bypass it without problems!

Story type:

Sander's blog

Various

Choose Your Hosting Service the Harvard Way

sander — Wed, 19 Dec 2007 14:20:45 +0000

Update: VistaPages has been sold to Millennium Data Systems (HostMDS).

From Evil to Hell

Credit: luisvilla, License: by

Less than a fortnight ago, I wrote about evil. This week, I write about hell and how Harvard's insights will help you to avoid a customer hell.

But first I want to add to last week's evil story that I was informed by a reliable source that 'Google would have preferred XMPP Federation, but that AOL was only willing to agree to a multiprotocol approach'.

This is no traditional review. Information is made as generally applicable as possible so that you can perfectly read this review without having any interest in a VistaPages review or whatever web host review. Hence, you may call this a 'tutorial review' or whatever you prefer.

As a last introductory item, we want to excuse for:

the severe website accessibility issues you may have encountered before we switched hosting provider,
the long downtime the Coccinella project website suffered last summer, and
the fact that our communication regarding this downtime is not as instant as you may expect from us.

We also thank all worried visitors who contacted us regarding last summer's downtime.

The Short VistaPages Review

As you probably hate reading long reviews, I will try to make a very long story as short as possible. If you are not interested in the VistaPages review, you can just skip to next section.

On the 22th of July our account at VistaPages was suspended for the first time. No notification was given! Although I could persuade VistaPages to revert the suspension, this took several hours. VistaPages said we used too much resources. As we didn't want this to happen again, I asked VistaPages to provide me with sufficient information so that we could fix the issue. However, VistaPages never gave sufficient information.

Thanks to the unwillingness of VistaPages to cooperate, I made the wise decision to backup the Coccinella website at my own computer. Only 1 week after the first suspension, VistaPages repeated the awful customer experience as can be seen in the above graph with visits stats. One difference though: VistaPages did not wanted to bring the Coccinella website online. They told we had to upgrade to VistaPages' not so cheap VPS service if we wanted to see our website back. So yes, the local backup really was a wise decision! B-)

Mats was thinking about just paying for the VPS as that was the only way to get the website online very fast. Even though my personal website also was plagued by the suspension, I refused Mats to accept the upgrade offer. VistaPages' held a pistol to our head and that's not the way of doing business that should be rewarded with more money. Thus, we started looking for another hosting provider and we found Florian Jensen, our new hoster. As he is a member of the XMPP Standards Foundation, we were sure the Coccinella community would not be fucked again.

We still wanted to give VistaPages a last chance. Therefore, I asked VistaPages if they were interested in cooperation. I informed them that we found another web hosting provider, that we could move within hours if necessary, that we would be indebted our community (you) to write the review you are reading now, and that we would have to inform Canadian authorities regarding our horrible experience (done). This is the reply I got from VistaPages, including all spelling errors...judge for yourself:

Hello Sander,

Your Top is showing nothing, and to bad for this that i was the one on the server in that moment suspending accounts.

Why only your account and also another one, there were two accounts when the load was up, is having problems with mysql, and the other one with spamd, i tell you why, because the other guy was spamming around big time, and your mysql databases were crashing the mysql server. from your top, you can not see anything, were are the processes that your site were running at that moment, the connections to the mysql server?

Also, stop sending replies about vistapages customers, when you should take care of your site and your problem, if there is one. Not go in front and start threating a company with whatever words, when you are not sure you are right. All this words will mean nothing if there is something to combat them, and more to it if there are facts.

So, in the end just try to focus o the issue, but if the next reply will contain a threat to the company or to one of the employees just don't reply at all, because this is not a way to do business, and more to it, it is just not good enough for 3-5$/month .

Thank you!

----------------------------
Florian N.
Sr. Systems Administrator
VistaPages, Inc.
www.vistapages.com

Refer a friend to VistaPages and earn free months! Ask us how :)

Obviously, this 'customer friendly' email settled everything! Within hours the Coccinella website was up and running at our new hosting location. Note that we actually paid VistaPages 35$/month and not 3-5$; no refund was given for 19 other months. Remark that Florian N. is not Florian J., our new hoster. Also note the funny line at the end of the signature!

The reason why it took so long to inform you about the downtime of the Coccinella website is that I had to struggle until last week with VistaPages to get my personal website transfered to another host and registrar. Leaving VistaPages is hard, be warned!

Please do not hesitate to contact me for more information about VistaPages if you were thinking about choosing them as your hosting service. You also can contact me for 'exodus tips' if you plan to leave VistaPages.

Web Hosting Providers and the Customers Who Hate Them

Wittingly or not, many companies encourage customers to make bad purchases—with the result that their profits depend on their most dissatisfied customers. [..] Why, then, do so many companies infuriate their customers by binding them with contracts, bleeding them with fees, confounding them with fine print, and otherwise penalizing them for their business? Because, unfortunately, it pays.

'Companies and the Customers Who Hate Them' is an insightful article written by Gail McGovern and Youngme Moon, and published in the June 2007 edition of the Harvard Business Review. Even though the article is not focused at web hosting services, the insights are extremely valuable for examining web hosting providers. Therefore, I would recommend anyone who is interested to enter the hosting market to read the full article.

Deep dissatisfaction is further manifest in relentless customer churn. [..] This level of turnover requires companies to engage in endless, aggressive customer acquisition, including extravagant spending on advertising.

The above quote is very interesting. My belief is that McGovern and Moon's article is not only useful for business, but also for customers like you! To choose your hosting service the 'Harvard way', you should compare advertising of hosting providers. Forget about comparing features of hosting packages! The advertising strategy of a hosting business reveals the amplitude of the 'suck factor' of the service. If a hosting provider needs a large advertising budget to compensate for high levels of customer attrition and large amounts of bad word of mouth like this, you better avoid that hosting service. The service will never be worth whatever amounts of Yottabytes of web space and data transfer are promised. You even should be careful when the service is free. The next section will give some practical measures to detect evil web hosting providers that have a hard time acquiring new customers.

Web Hosting Checklist

This checklist can be used as a tool to detect web hosting providers you should avoid. All measures may give you an indication whether or not a hosting provider requires aggressive advertising to keep up with high customer defection rates caused by an unsatisfactory service. Don't get influenced by a cheap hosting service with lots of features, simply avoid a hosting service depending on big advertising spending to stay in business. The more positive answer you get in the following list, the more reluctant you should be.

Affiliate Program - Does the hosting provider have an affiliate program? Is this program promoted on the front page on a very visible location? Is the hosting provider desperately looking for new affiliates? Did the affiliate program get better over time?
Awards - Does the hosting provider prance with its awards? Can you find scandals regarding the review website which gave out the award? Can you trust the review website? (general rule: no!) Does the domain owner of the review website hide behind a proxy service? Who is the hoster and/or registrar of the review website domain, the hosting provider? When not hidden behind a proxy service, you may be able to see that the domain owner lives in the same city as the hosting provider, and furthermore, you discover the owner of the review website worked for the same hosting provider as the CEO of the hosting provider you are looking at!
Headquarters - Does the hosting provider have a nice picture of its headquarters on its website? Is this really a picture of the headquarters of the hosting provider or is it a picture of a Canadian post office? Google Maps can be a very helpful tool to find Mailbox companies and thus helps you to detect how professional the hosting provider in fact is.
Customer Testimonials - Does the website of the hosting provider have a separate section with customer testimonials? Did the hosting provider found it worth the money to register a separate domain to boost search engine page ranking (SEO)? Did you actually check if the testimonials are pointing to a real website? The Internet Wayback Machine is a useful tool to see what was on these websites before they went down. Do you find people telling on their own website the provider you are interested in rules, or sucks?
People - Does the website of the hosting provider contain many photos of professional looking people? Does these pictures make the company look like being a trustworthy business? Does it look like these pictures did cost a lot for the hosting provider?
Marketing Tricks - Are there advantages if you choose for a longer billing cycle? No subscription fee, for instance, or lower monthly fees, or something else? Such advantages may indicate that the hosting provider is unsure about themselves; they know the chance may be high you want to leave as soon as possible.

How to Earn Money From Unethical Hosting Companies

As can be deduced from the Harvard Business Review article, hosting providers who suck benefit financially by doing so. At least in the short term it pays. Nonetheless, due to huge customer attrition rates, unethical hosting providers like VistaPages have large advertising budgets. And this is exactly the weak point you can exploit to earn money!

Affiliate programs and sponsorship are of key importance for bad hosting providers to compensate for huge customer attrition and to restore reputational damage. Hence, the willingness to pay of unethical hosting providers is extremely high in this area. Bloggers and open-source communities like you and me me are worth their weight in gold for them. We have a very valuable reputation of trust! To restore their reputation, unethical hosting providers may want to pay you much more than the value of the sales you can bring in! Negotiate with the hosting provider to squeeze the money out of them. Let them pay for your reputation! Let them pay more than ethical hosters!

Of course, you may simply not want to take the risk your reputation being tarnished by accepting the unethical money. Therefore, establishing your own ethical sponsorship framework may be a good way to protect your reputation of trust. Another solution, the easiest option, is to refuse any kind of sponsorship from people outside your community, like we do.

Credit: D. Gillard, License: by

Conclusion of the VistaPages Review

For God's Sake, we advise you to avoid VistaPages at any cost!

As The Consumerist already suggested to hit Kaumil Patel in the face, it is probably a good idea. Personally, I loathe violence, though VistaPages and Kaumil Patel seem to enjoy being hit in the face as is written on the VistaPages website:

We treat you the way we want to be treated by our service providers! (source)

I am really proud at the fact that VistaPages has offered customers the support and service that we have (source)

Note for the service providers who treat VistaPages: please give VistaPages and Kaumil Patel (CEO) the treatment they are begging for; get inspired by the Barbie picture!

Other VistaPages Victims we Trust

This list is meant to be an up to date list of stories of other VistaPages customers we trust. Please contact me by email or instant messaging to initiate the trust verification process in order to get listed.

VistaPages Must Really Hate Having Customers
VistaPages Curses Off Customer
Vistapages sucks... worst host ever (link broken)
BBB Reliability Report about VistaPages
web host to avoid

Comment Rules

One of the purposes of this article is being a trustworthy review and guide for people searching a good (and maybe cheap) hosting service. Therefore, no 'flamewar review' is desired in the comments regarding web hosting companies. Hence, comments containing any of the following are not allowed:

Links to websites of hosting providers
Links to review websites including review blogs
Names of hosting providers or review websites/blogs
Unethical content with any evil purpose

Use your own blog or contact me personally instead for such comments! If I find your email useful, I may add your comment. Note that I'll be the sole and final arbiter as to what constitutes a violation of this policy.
@Kaumil Patel of VistaPages: for 1,000,000 EUR we may think about removing this article from this website. :o)

Story type:

Gmail + AIM = Evil?

sander — Thu, 06 Dec 2007 15:08:47 +0000

Gmail supports AIM. That's good news. Err, it's bad news! This is an evil feature and in this article I will write why Google is evil.

A Shameful Lie

First, Michael Davidson, a Googler, writes in the announcement that

'Google has been committed to open standards and interoperation for instant messaging. So when our friends at AOL agreed to let Gmail users talk to users on their network, we jumped at the chance.'

This is a shameful lie and an abuse of the term 'open standard': no open standards are involved in the evil Gmail feature. Gmail behaves like a normal AIM client. The AIM servers still talk a proprietary protocol and so does Gmail; nothing changed. So, we are still talking about walled gardens in instant messaging.

Google's current move with AIM support in Gmail is in no way comparable with their recent contribution to the destruction of walled gardens in social networks.

A Curse for Adoption of Open Standards

Technically, Gmail now became a multiprotocol client implementing a proprietary instant messaging protocol. Google thus promotes the use of the proprietary networks by allowing their users to connect to this walled garden.

As I wrote a few months ago, multiprotocol clients are a curse:

Multiprotocol clients are a curse for interoperability.
Multiprotocol clients hinder adoption of open standards like XMPP and SIMPLE.
Multiprotocol clients even hinder their own adoption!
Multiprotocol clients explain why "the Firefox of instant messaging" does not yet exist.

More details about these these tough claims can be found in the section Why a Curse and Why Transports? of that article.

Not Fair to other Instant Messaging Services

Google's agreement with AOL is a coalition between 2 incumbent players. Such a partnership is an evil entry barrier to make it more difficult for other players in the market to compete on the same level. Both Google and AOL restrict the market by this move. This is not compatible with Google's "Don't be evil".

How to Fix

If Google want to restore it's reputation for not being evil, it should process the items on this TODO list:

Excuse for the wrong use of the term 'open standard' in the announcement
One of these:
- Use transports instead, to achieve the AIM integration as a means to achieve #2
- Get AOL to adopt XMPP for server-to-server interoperability

Others who Think it's a Misfeature

Other bloggers who also don't like the AIM feature:

This list will be updated when you provide me more links.

Story type:

Sander's blog

Various

8 Years and More: The Roots of Coccinella

sander — Sat, 01 Dec 2007 20:20:46 +0000

Credit: D. Bell, License: by-nc

Exactly 8 years ago, on the 1st of December 1999, the first official release of an application called Whiteboard was released. In 2003, Whiteboard was renamed into Coccinella. Happy 8th birthday Coccinella!

Read on for a more complete history of 'the beginning' and to read about Coccinella's birthday presents.

The 'Before Coccinella' Era

Somewhere in 1998, Jeremie Miller started working on Jabber, a project that gave birth to innovative instant messaging protocols which are used today in an increasing number of instant messaging applications, including Coccinella. In November of the same year, another well-known instant messaging project named Gaim (now Pidgin) was started.

In January 1999, the Jabber project was officially announced.

The Birth of Coccinella's Roots

Throughout 1999, the Tcl community worked on a Jabber client called zABBER and a Jabber client library called JabberLib. We do not exactly know when these projects were started, though we found a development snapshot of zABBER which was released on the 12th of April. Note that the original zABBER website is still online (!!) and screenshots and snapshots of this prehistoric software can still be downloaded. In September 1999, the tcl.jabber.org site was created. This was the home of the Jabber Tcl/Tk Team.

For those who are interested, I tested the latest zABBER release and it still works to some extend (connecting, presence, receiving messages, replying to received messages) with some of today's Jabber servers...8 years of compatibility of the base Jabber protocols which were still in heavy development in 1999!

The Birth of Coccinella

As already said in the introduction, the first official release of Coccinella was Whiteboard-0.90, released on the 1st of December 1999. We don't know when Mats actually started working on Whiteboard, but maybe he can add a comment to this post with a guess and/or additional interesting details he still remembers about 1999... B-)

You may think Coccinella always has had support for the Jabber/XMPP protocols but this is not true. On the 27th of January 2002 (coincidence?), Whiteboard-0.93 was released. This was the first release 'adapting to the jabber XML IM server system'. The peer-to-peer "Whiteboard protocol" was only removed earlier this year, in Coccinella 0.96.0. Also, it would be cool if Coccinella could adapt to a good whiteboarding XEP...which first should be made of course. See also Mat's related memo on synchronisation. /me pokes the XSF. ;-)

Credit: K. Tate, License: by-nc-sa

Cheating

Implementing Jabber support was not as tough as it could have been thanks to the work done by the Jabber Tcl/Tk Team in 1999 and beyond. Mats 'simply' could recycle the JabberLib client library made by this project (Mats' fork of JabberLib). Five months later, on the 3rd of July, the Tkabber project repeated the same trick by forking JabberLib for a second time. So, today there are 2 separate forks of the original JabberLib. This also means that these are probably (correct me if I'm wrong) only 2 active Jabber-only clients which have such mature Jabber roots.

Besides that, there are at least 2 projects using Mats' JabberLib fork. However, which projects these are and more details about these projects will be the topic of a further blog post as this one is already getting too long :-)

Birthday Presents

We have 2 presents for Coccinella's birthday. First, there is the updated website design including Néstor Díaz's new logo design (do you like it?). Secondly, there is a secret present which will be revealed tomorrow. So, stay tuned!

Story type:

Website

Sander's blog

Various

Your art contributions are welcome

sander — Tue, 16 Oct 2007 18:59:57 +0000

As you can see above, Néstor Díaz did a great job with creating nice Coccinella art. However, he has no time these days whilst the Coccinella experience still could be improved by more art contributions. So, do not hesitate to contact us or to add a comment if you are interested in contributing art!

PS: of course other contributions are welcome as well ;-)

Story type:

Sander's blog

Various

Why Transports Matter

sander — Mon, 17 Sep 2007 16:25:30 +0000

This is an open letter to all people related to the content of this article. So, you better read everything to see if that includes you ;-)

Instant messaging clients like Pidgin, Adium, Miranda and Kopete combine support for different instant messaging networks in one program. They often also support platforms that are not supported by the official client software. Therefore, these so-called multiprotocol clients are seen by many as a good thing for interoperability. However, I strongly disagree on this. Instead, my analysis sounds the opposite way:

Multiprotocol clients are a curse for interoperability.
Multiprotocol clients hinder adoption of open standards like XMPP and SIMPLE.
Multiprotocol clients even hinder their own adoption!
Multiprotocol clients explain why "the Firefox of instant messaging" does not yet exist.

In this article, I will explain these tough claims. Also, I will elaborate about a possible strategy for those who would like to get rid of closed non-interoperable instant messaging networks. In short this strategy is simple: we need to render the walled gardens pointless by destroying the reason they are more profitable than open networks.

Why a Curse and Why Transports?

In this section, I will tell you why multiprotocol clients do not help much to fight closed networks. Not much, as a lot of resources are wasted in these projects which could otherwise be used in a more effective way to get rid of closed networks in favour of open networks. Without closed networks there would be a very friendly and innovative environment suitable for the emerge of "the Firefox of instant messaging".

Ok, but what is the right way to fight closed networks? The right way is a combination of several dedicated XMPP clients with some darn good transports. Transports are server-side gateways that allow XMPP clients to connect to closed networks without any significant effort like reverse engineering or designing a multiprotocol architecture. To be more clear about this abstraction, transports translate the language of the XMPP client to the language of a client on a closed network without the XMPP client knowing that language.

Time for the core of this article...Why transports matter:

The quality of support for open standards like XMPP is lower in multiprotocol clients than in dedicated XMPP clients. This can be easily explained by the increased complexity of the software to support multiple protocols, but this is only a minor point that can be solved by having enough eye balls to catch bugs. More important is the fact that XMPP is less used by geeks compared to popular closed protocols. Hence, there are more eye balls looking for bugs in closed protocols support than to catch bugs in XMPP protocol support.

Compare this with instant messaging clients dedicated to the open standard protocol XMPP. First, these clients don't need a complex multiprotocol software architecture. Second, their reason to exist is XMPP support. Thanks to this dedication, the quality of XMPP support is more likely to be much higher than that of unfocused multiprotocol clients. A bug that breaks XMPP support is a major issue in XMPP clients whilst it is a less major issue in multiprotocol clients as these clients will still be usable for other protocols.

Transports matter because they force end users whom mostly use closed networks to contribute their "eye ball capacity" to XMPP support.
The 'instant messaging experience'(or innovativeness) of multiprotocol clients is lower than that of the official clients for the closed networks. They run behind because of the required reverse engineering, the complex software architecture, and the tendency to only support features common to the majority of supported popular networks. They tend to limit their feature set to the least common denominator of its constituents, which can be very small. They cannot influence the future of the underlying protocols as these protocols are controlled by the companies owning the closed networks. Where is the room for innovation? There is no room for this as multiprotocol clients simply can never take over the lead of the official clients in designing the future of the closed protocols.

Dedicated XMPP client projects instead, fully focus on a single protocol that is extremely well documented and thus don't needs any reverse engineering. Moreover, XMPP client projects can have their say in the future of the underlying protocols and even can propose their own protocol extensions for standardisation. That's an open door for unlimited innovation!

Transports matter because they allow XMPP client projects to fully focus on innovation without losing interoperability with closed networks and without being influenced or hindered by the closed networks. Transports allow XMPP clients to lead the instant messaging world, instead of following the closed networks owners, like multiprotocol clients tend to do. The later can be compared with Mozilla: no focus, complex, not sexy, following the leader(s), not popular, and so forth. The combination of dedicated XMPP clients and transports could become like Firefox: focused on open standards, innovative, taking over the leadership position, very popular, and so forth.
The image of open source multiprotocol clients hurts the broader open source image. Open source multiprotocol clients do not lead in their environment and are seen as poor extracts of the official clients. Unfortunately, this poor image of being a follower instead of a leader means the public will associate open source alternatives by definition with poor extracts of the real thing. Hence, people even may not try XMPP because of earlier unsatisfying experiences with multiprotocol clients.
Choice on closed networks is created by multiprotocol clients. Multiprotocol clients allow people who for some reason cannot or do not want to use the official client to connect to closed networks. This choice also reduces the vulnerability of closed networks to malware. You may think these are all good things, but in fact they hinder adoption of open standards like XMPP.

Imagine a world without alternatives to official clients for closed networks. All people who are today contributing to the multiprotocol part of multiprotocol client projects would focus on XMPP and server-side transports. Client projects wouldn't be forced to do urge releases due to some compatibility change in the closed network protocol. Development would be totally independent from the closed network owners. Focus can be directed to innovative client features in the XMPP world. All end users using one of these clients in combination with transports would use XMPP. So, every user would contribute to the maturity XMPP, even if they only want to communicate with people on closed networks!

Transports matter because they can lead to more and higher quality choice in the XMPP world. More choice because the existence of very good transports make it more interesting to create XMPP software. Higher quality because all end users will use the XMPP code, even if they only use their XMPP client to connect to closed networks.

Flexibility of multiprotocol clients is extremely low. Multiprotocol client projects are bloated. They need testers for all integrated protocols. The complexity of the multiprotocol architecture needs maintainance. Large changes in the support for one protocol are not easy if this could break support of other protocols, and if they make such changes they have to do this very carefully. Multiprotocol client projects tend to first add features common to all integrated protocols instead of adding innovative features.

Compare multiprotocol client projects with XMPP client projects. Look at the number of innovative protocol features in multiprotocol clients compared to XMPP clients. Also consider how many coders are involved in the different types of projects. The following statistics from ohloh.net about contributors over the entire history of the project can help you. Of course, these numbers are not 100% accurate at all (e.g. some projects give translators commit rights whilst others don't), but still, the significant differences give an indication:

Multiprotocol Clients	XMPP Clients
Pidgin (33), Kopete (100), Adium (52), Miranda (22)	Coccinella (3),Tkabber (2), Psi (7), GOIM (5), Spark (10), Gajim (19), JWChat (3), Bombus (1), Freetalk (4)

The fact that there are more active dedicated XMPP clients in the wild than there are active multiprotocol clients says a lot about the required community size to sustain a less complex but focused XMPP client.

Transports matter because they move the maintenance burden and release burden (no forced releases) away from the client projects. They increase the projects' flexibility and development speed (less and shorter testing periods, less complexity). They move away the eventual legal issues in some countries from the client project to a server project which is more suitable to benefit from today's globalised world. A country eventually can forbid multiprotocol clients, but it never can forbid inhabitants to use a transport service hosted in another country without being punished with a trade war by other nations as this would be a trade barrier in services.

The Solution

Multiprotocol clients should become single protocol clients. To accomplish this goal I propose to "steal" community of multiprotocol client projects in favour of XMPP software so that their 'community resources' will become insufficient to sustain a complex design for multiple protocols. We also can ask them to drop support for closed protocols, but I'm afraid they will just laugh at us.

The Tactics

To "steal" community of multiprotocol client projects, he reasons why end users chose multiprotocol clients should be eliminated. Currently, I see two constructive ways to do this:

Help the Wine project to support the official clients. In this way, the hard task of reverse engineering and maintaining the proprietary protocol code becomes less urgent for people who contribute to multiprotocol clients, and they may stop doing their hard work. Also, end users will be more happy on their new platform as they can stay using the client they are used to. They can use all features of this closed network...including all misfeatures of the client. If this end user wants choice, he has to install an XMPP client.

Note also that official instant messaging clients for closed networks are strategically an interesting target for the Wine project. Instant messaging clients are probably the most important application of younger people. These people like to experiment with new operating systems. However, they face huge switching costs as they cannot run the instant messaging client their friends use. The switching costs are higher if they need to use an alternative client as they need to learn a new interface for their most important application, and because the alternative multiprotocol client probably does not has all features of the official client.

As a side note, you can see why the Mac OS X version of Windows Live Messenger can't be compared with the Windows version. You also see one of the reasons why Microsoft will not adopt XMPP soon: it hinders youngsters to switch to non-Microsoft platforms. But if the Windows version of Windows Live Messenger can fluently run under any platform thanks to Wine, Microsoft loses a good reason to not adopt XMPP. Note that I do not say they will per se adopt XMPP afterwards!
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 feature.

Wishlist for Transports

Currently, there is lot's of room for improvement of transports in XMPP land. Because transports are a key feature in the success of Coccinella and other XMPP clients, we would ask the broader XMPP community to improve the current situation regarding transports.

Wishlist for transports:

Focus on reliability of service: uptime, hot code update, fail-over, clustering to bypass blocking, and so forth.
Focus on reliability of compatibility. Fast deployment of fixes for protocol updates by the closed network owner is what we need. The faster transports are updated, the more expensive and thus the less interesting it becomes for closed network owners to change their protocols to block alternative software.
Focus on basic interoperability features only. Text messaging and presence should be the focus. Other features are not important and only make it harder to maintain "reliability of compatibility".
More closed networks. Transports should cover all closed networks.
XMPP based ideology. Transport projects should favour the XMPP world in the first place. "What XMPP feature will I map to the closed network today?" instead of "What closed network feature will I map to the XMPP world today?" XMPP protocols should be written first and only after that we should look if they can be mapped to closed networks, we should not write XMPP protocols to get similar features as the closed networks have. Taking the lead means not copying features, instead it means innovating with unique protocol features.

Also, transports should be friendly only to people on the XMPP side of the gateway. People on the other side of the gate should get what they have chosen for: no openness, no help, and a bad experience. For example, an error message should sound "You cannot send this file to your contact because your software is not interoperable. Please contact <name of network owner> for more information." instead of "You cannot send this file to your contact because your contact does uses an XMPP client. Please consider switching to XMPP to fix this issue.". When the XMPP user wants to send a file to his contact on the closed network it should sound: "We are sorry but this file cannot be send because your contact uses a chat system that is not interoperable. Please consider to ask your contact to switch to the open XMPP. This issue cannot be fixed without the help of the closed network owner. May we therefore also ask you to sign the petition on <URL>? By supporting this petition, you ask the owner to open its closed network and by this offering a better service to you. This interoperability issue can't be fixed without their help".

As you can see, with a difference in approach we can forward all troublesome interoperability experiences to the real responsible instances (the owner of the closed networks). In this way end users will not associate the issues to XMPP and they may even understand open standards fanboys! This can mean a big thing for the image and popularity of XMPP.
No lock-in feature of a server. As is normal in good open standard communities, any lock-in is seen in the XMPP community as evil because it is bad for the emerge of the open standard. Lock-in also can be the root of a software monoculture. We also don't want that. Luckily, server projects are making their components compatible with other servers. And hopefully, this server will follow soon. But we are not there yet.
Shaped to die fast. Transports' main goal should be to die as fast as possible. If a transport project dies it may mean the related closed network became open or went offline! Transports should be tools of judo strategy:

The central message of Judo Strategy is that [instances] facing more powerful opponents should avoid head-to-head struggles and other trials of strength. Instead, by employing speed, agility, and creative strategic thinking, they can shape the dynamics of competition in ways that prevent rivals from taking full advantage of their superior strength. At its most effective, judo strategy can even transform an opponent’s apparent advantages into strategic liabilities that undermine his or her ability to compete.
Sexy software. Transports should become sexy software projects with a nice website, good documentation, a good community, easy installation and configuration, and so forth. But this item is obvious :-)

About me

In case you want to argue on my thoughts, consider all next facts before you reply:

I am no real coder; my speciality is copy-paste coding :o) and other ways to contribute to open source projects
I like open standards
I like XMPP
I like unlimited choice in all XMPP software
I don't think XMPP software is so good it can't be improved
I don't believe Coccinella is so good it can't be improved
I also like other XMPP clients; monoculture is evil
I like successful open source projects like Firefox and Ubuntu because they increase popularity of the broader open source world
I don't want multiprotocol client projects to die, they just should become dedicated to only one open standard (preferably XMPP)
I prefer Konqueror over Firefox, but I also like Firefox

Story type:

Sander's blog

Various