[Standards] Easy XMPP

Dave Cridland dave at cridland.net
Tue Jan 17 08:23:22 UTC 2017


On 17 January 2017 at 04:05, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> The world I work in has mostly migrated away from on-premises software, to
> cloud services that are public or semi-private. I recognize that some
> organizations simply can't go there - they have regulatory reasons or
> security policies for not allowing any data outside of their trust
> boundaries (e.g., military systems, some big companies, some smaller
> companies in specific industries like aerospace or medicine). However, such
> organizations are in the minority.
>

I don't think it's a clear-cut divide between cloud-and-closed and
self-hosting-and-open. It hasn't been with email, which has been a
functioning mixture across both dimensions, which Microsoft Exchange
handling self-hosted and closed, and the majority of providers being
cloud and open throughout its history.

So suggesting that "the world [...] has mostly migrated away from
on-premises software" is implying a dichotomy the evidence of which
isn't borne out by history.

Yes, the vast majority of people, and most organisations, will be
served best by using a specialist provider. But a single provider? I'm
far from convinced that's a positive outcome for anyone except the
rare winner.

> Although I like federation, I'm no longer convinced that it is necessary for
> most people. For example, in services like Slack and Hipchat everything is
> room-based, and that fits well with MUC/MIX. But authorization for someone
> to join a room happens via means other than server-to-server federation
> (e.g., set up a private room and invite the external person to that room
> directly). Yes, this kind of workaround isn't exactly elegant, but it mostly
> works for most people.
>

It's a model that works very well for Slack and HipChat, and that they
have managed to make palatable to their users. In fairness, it can
work very well for users - the low-friction of handing someone a URL
is very useful, and serv{ice|er} developers should learn from this -
but I don't believe that it's genuinely in the interests of the users'
or their organisations to operate this way.

And for providers, too, it's a disaster. We only see the handful of
success stories and it's easy - although utterly fallacious - to think
that if one group of six people can knock together a successful IM
system then anyone can. But that's just not true. Enormous luck is
involved, and the path to glory is littered with failed IM services.
They don't fail, for the most part, due to some technical flaw, or
imperfect UX, they simply fail because the numbers of success stories
are predominantly limited by the whimsy of users. It turns out it
needs thousands to try to make a new IM system for one or two to
succeed.

> As to Signal, they appear to be a not-for-profit and to have not taken VC
> money. Thus it's not clear to me that they plan to sell their overall
> service to an acquiring company - the usual model these days. Perhaps they
> do want to sell their technology or consulting services around their
> technology as a way to become self-sustaining, but that's more of a
> lifestyle business (with its own myriad challenges!) and not necessarily a
> path to selling out. (BTW, if I had gotten serious about doing something
> like this with jabber.org, people might be saying the same thing about that
> initiative!)

I think "selling out" is a term that's become somewhat meaningless
over the years, but I've assumed it to mean that someone places
financial considerations over principles and/or the public good.

But while Signal is a not-for-profit, and indeed has not taken VC
money, the levels of cash are very high - just in terms of known
grants and donations it's in excess of $3 million, and split 6 ways
across four years that's not a lifestyle business anymore (well, maybe
it is, but it's a great lifestyle). That's not including the financial
gains from licensing deals with Facebook, WhatsApp, and Google.

The mere fact of making money isn't the real issue here, however - my
main concerns here are the legal stance and apparent willingness to
resort to lawyers to defend their novel interpretation of "open
source".

Dave.


More information about the Standards mailing list