Ok, so I installed Telepathy. OpenSUSE 13.2 (KDE 4.14.2), on a virtual machine of course.

I am utterly unimpressed.

I had been peeking into its development now and then, and it struck me as a somewhat disorganised, hit and miss sort of affair. Not really run by a professional (or at least skilled) project lead. So I did not hold high hopes--hence my installing on a virtual machine as opposed to one of my own systems.

First negative: IM accounts configured in System Settings.

I could sort of live with that. I imagine that it's trying to follow the KMail / Akonadi resources lead. But do we really need a new entry under System Settings? At the very least, I would expect it to be at the same place where my email / CalDAV / CardDAV settings are, and that is under Personal Information.

Second negative: It's just buggy

I am also a developer, I know bugs are part of life. I can also tell a serious bug from a big but not so problematic one. I also know that projects that I work on either are in production and functional after four years or have been killed (a multi-million $$$ project I worked on, not as the lead thankfully, was killed after 2.5 years. Mostly due to mistakes we had made along the way resulting in an unsound design. Embarrassing and expensive, but at least we learned from it and more importantly, we didn't go to market to inflict a shıt product on our users).

So I configured one of my XMPP accounts in System Settings, OK it away and connect on the "IM Contacts" window. It shows my status as "Available", but there are no contacts (nor an actual TCP connection to the server).

So I go back to System Settings and see that there the account shows as "Disconnected" and under the account handle it says "Invalid argument" (Oh, the helpfulness of it! Straight from Microsoft's "An Error Has Occurred" book). Now this is the sort of bugs that I deem totally unacceptable in a product four years in the making. It is just lying to the user. Now, an unsuspecting user would have no clue that something is amiss. He may just think that all his contacts are offline... forever. And a sophisticated user... well, I'd like to be given a clue were to look for the problem. Failing without so much as a visible notification is beyond what I would expect from an amateur.

So let's talk briefly about that:

Third negative: It's confusing

So it misleads the user into thinking that it's connected when it's not. But it also misleads the user into thinking it's disconnected when it's (possibly) not. A visible, clearly discoverable shutdown control is a must for anything that could cost the user money (e.g. in network charges). For that matter, it would be nice to know how to launch the thing in the first place. Or maybe not (answer: ktp-contactlist).

Fourth negative: It tries to displace, not replace Kopete

We need an XMPP client. Proprietary chat solutions come and go: ICQ (or whatever it was called), Yahoo chat (does it still work?), MSN (ditto), GTalk (walled garden now), Farcebook (ditto). On the other hand, I have had the same XMPP handle for the last 14 years. Running on my own server on my own domain. That's longer than all bar one of my email addresses, and way longer than any telephone numbers I have had. Or postal addresses, for that matter. So XMPP is the focus. Regardless of user numbers, if resources are limited, going for the most bang for the buck is a sensible strategy. That does not always mean higher number of users at a given time: if $ProprietaryChatProvider has 50,000,000 users but a year down the line the lose them all to $AnotherProprietaryChatProvider who another year down the line decides that only their official client is allowed to connect, we have developed the same solution twice in the space of two years. On the other hand, if vanilla XMPP can only reach 5,000,000 users but it can reach them over the space of ten/fifteen/twenty years, our development (and maintenance) costs will have been money better spent.

Telepathy does XMPP. For all I know (I haven't looked into it) perhaps it does it really well, but as far as I can see very little of it is exposed to the user, or if it is, it's not clear to me where that can be found.

A big argument for trying to replacedisplace Kopete is that "it's not really maintained".

Well, it works. And it works well. Even without maintenance. And it didn't take the Kopete developers four years and counting to get there.

Fifth negative: It doesn't support OTR

It doesn't support a bunch of other things either. And support for the plethora of things it tries to do is half-arsed to say the least.

But come on, it's not like we don't know what's going on security- and privacy-wise. It is true that it's not only Telepathy. In general the state of things in terms of secure communications is pretty unenviable, in particular those solutions available to the general public. But let us not make excuses. OTR should have been in the requirements from day 0, and implemented from day 1. As I understand, the development team does not even seem to grasp the seriousness of the situation.

Sixth negative: The breadth-first approach

So it tries to provide "a suite of applications for a full instant messaging experience".

A "full" instant messaging "experience" (God, what a stupid term--leave that to marketing) is one where as a user I can do, easily and intuitively, all that I need to do with my chosen instant messaging medium. Note that I said "medium", not "media". Perhaps there are a few primedonne who have accounts on every possible IM system out there, but even those are not being served by this thing in its current sad state.

Positives

There seems to be some enthusiasm behind it. This is both a good and a bad thing. A bad thing because without it, perhaps the project would have been abandoned by now (which would not be an undesirable outcome). A good thing because if people really care, they may decide to take a long, hard look at what they have, put their egos aside, and decide that significant structural change is needed if this is not to become another chronic disaster such as those coming from a certain Teutonic developer.

To recap

Those are my impressions from looking at the project and from my attempt at using its deliverables. I do not think we are looking at a series of isolated bugs or one of those periods of instability that nearly every non-trivial project goes through. Instead, I believe there is an organisational problem with the team (if a team it is) behind this. It appears to me, from a brief look, that they have set themselves the wrong priorities, have little or no discipline, methodological deficiencies, and likely suffer from poor leadership, for it is a leader's responsibility to always be appraised of the big picture.

Duly noted.