- Dave Cridland
I'm Dave Cridland. I work for Forward Clinical Ltd, as the Messaging Engineer. I also hang around on the board of the Ignite Realtime Foundation, which provides a legal existence for things like Openfire (which I suspect to be the XMPP server with the highest number of deployments) and Smack (which is almost certainly the client library used by the most projects).
I have previously served on the Board of the XMPP Standards Foundation, and indeed chaired it for a year.
Since the last century, I have actively worked toward Open Standards. A key feature of Open Standards - at least to me - is that they must be implementable, without constraint or condition, directly from the specification. For years - certainly without question the whole of the 1990's - the simplest benchmark for this was "could I implement this as Open Source". Patent licensing, whether RAND or whatever else, has an obviously damaging effect on this, but there are plenty of other complications we can run into.
It's not just a benchmark, either. Open Source is desirable in and of itself. We should, as an organisation, promote its use (and throughout its history, the XSF has been unique in requiring Open Source implementations for advancement to Final).
The GPL, in particular, muddies this, by essentially mandating Open Source. This itself is a condition, certainly - though whether you view this as a constraint might be up for debate. I don't object to the GPL, in and of itself. I'll happily contribute to GPL projects, and I'll certainly use them.
But for the purposes of Open Standards, perhaps the better benchmark is "could I implement this as MIT" (or BSD, or any permissive license). Again, this doesn't mean that *everyone* should implement as MIT, or Open Source, or indeed impose any condition or constraint. But as a benchmark for whether something conforms to "Open Standard", that seems the simplest rule of thumb.
And I do feel, very strongly, that the XMPP Standards Foundation must be, first and foremost, an Open Standards Organisation.
We are in the business, here, of communication.
Every one of us uses or makes protocols, systems, software, and more that handles communication.
We do so to a minute degree. We should be proud of this.
But we're terrible at communication.
Several years ago, the standards list was hard to keep up with. Council members would often struggle to simply read every message.
That seems to have died off. We get messages thrown into chatrooms referencing blog posts, or conversations squirrelled away on pull requests, or mentioned obliquely from particular groups. It's really no use at all.
Personally, I like mailing lists, but perhaps we have reached a point where they are now no longer fit for purpose, between DKIM and fashions. Or maybe we're just out of habit. I do remember that when we moved to Github and PRs, there were concerns expressed that moving discussion to pull requests might mean that we lost visibility.
I think we are rapidly developing a transparency problem, and we need to urgently address how (and maybe even where) we communicate to ensure that we don't make this worse.
We have a lot of often highly commercial uses of XMPP - Nintendo, Electronic Arts, and so on. I think that as a community we should be encouraging people from those organisations to join us, and become part of the community in turn. We could gain much - to get people from EA talking about Fortnite's use of XMPP would be great marketing, certainly, but their input into the technical design might yield some insights about how to make XMPP more attractive as a platform. That should not only improve XMPP on a technical level, but also improve job opportunities for many of us.
Achieving this means ensuring that we are a welcoming community, and pragmatic too - I'd like nothing more than to be able to connect my own client into a game's chat service to stay plugged in to the discussion conveniently, and even better if I can federate sanely. But I understand that's a big and scary jump for a lot of XMPP users. The first step seems to be welcoming them into the community so we can - eventually - encourage them in that direction.
Council vs Board
I have things I want to do on both, but being on both Council and Board isn't ideal.
I'll review the state of applications, and if I feel I can I'll withdraw from one or other.