[Members] Goals for the XSF Board

[Peter Saint-Andre]

On 11/24/14, 2:25 AM, Kevin Smith wrote:
> On 21 Nov 2014, at 15:35, Laura <laura.gill at surevine.com> wrote:
>> If anyone would like to contribute ideas, we want to hear them! What goals would you like to see set for the Board for the year ahead?
>
> First - thanks to the new Board for asking the question. The things that immediately jump to mind that I’d like to see
>
> * The website finished and maintained.
> * Content on the website ‘selling’ XMPP - why and how etc.
> * Strategic evangelisation of federation to the people who need to be persuaded.
> * Timely (but considered) responses to current XMPPish events.
> * A strategy for IoT.
> * Engagement of people using XMPP in interesting ways who’re currently outside the community (and once that’s happened, that leads on to technical stuff for solving their issues).
> * At least one well-attended Summit with useful location/notice.
> * Engagement with the members (this mail was a good start).

Kev, those are all excellent suggestions.

As far as I can see, the primary challenge we face is that we're selling 
protocols, but developers want APIs and users want apps (I realize that 
the latter audience is not really our target market).

We are not the only organization facing such a challenge. For example, 
both the IETF and W3C are often seen as increasingly irrelevant, too. 
However, I'd note that both the IETF and the W3C have been particularly 
successful in recent years when they have focused on APIs and running 
code - I would single out the Opus audio codec and the WebRTC API.

I see a tremendous opportunity for developers to build realtime 
communication apps using XMPP and WebRTC, because WebRTC does not 
include the signaling and messaging layer. We (the XMPP community) can 
provide that, but web developers hate XML, which is why JavaScript 
libraries like XMPP-FTW and stanza.io are important. (On the back end 
you still need to run an XMPP server and a TURN server and potentially a 
selective forwarding unit like the Jitsi Videobridge, but maybe that's 
something a developer can tell the ops folks to deal with.)

We might have a similar opportunity in the IoT space, although more 
options exist there (MQTT, CoAP, etc.).

Although traditionally we've only developed protocols, we might consider 
working more closely with the API developers (as for instance the IETF 
and W3C have done on WebRTC).

I'm not saying that's the complete picture, but it's part of what I'm 
seeing.

Peter