[Members] 2013 Board and Council Elections - questions for candidates

Philipp Hancke fippo at goodadvice.pages.de
Wed Oct 16 18:12:14 UTC 2013

Am 16.10.2013 16:31, schrieb Ashley Ward:
> Hi All,
> So my thoughts about what I expect the board to be doing this year. Well, a normal company board usually consists of several individuals overseeing different parts of the business.
> Bearing this in mind, on one side I think there are two sides to the board's responsibilities:
> 1) Keeping the lights on - making sure that business as usual goes on. Keeping an eye on the coffers and generally overseeing the running of the business. I don't think this will be too much of a problem this year as there are several applicants versed in running a business. However, I think it would be great to get some more transparency into the state of the business side of the organisation.
> 2) Ensuring that the organisation strives towards its vision and carries out its mission. Looking at the mission statement of the XSF, on the face of it we seem to be living up to it pretty well, after all we do have a pretty darn good open, secure, feature-rich, decentralised infrastructure for real-time communication over the Internet.
> However, you read a bit further: "The XSF’s product is protocols; the XSF’s market is developers.". So we have a great product - a mature set of protocols which have a real USP, but we really rely on our customers (the developers). And we need to make sure that their needs, both technical and business oriented, feed back into the organisation. The extensions come from the needs of developers, so making sure that it's as straightforward as possible, and that they even know that they can, contribute their extensions back to the community. The value and relevance of our product is directly linked to our customers involvement in the community.
> So there is a two-fold need for developer relations - firstly to get people using the technology (over and above other competing technologies), secondly to get them engaging with the community, feeding back their lessons learnt, improvements, extensions, etc.
> Quick SWOT analysis - it would be great to do a proper one of these (which should form part of the incoming board's first set of responsibilities) with involvement of the membership:
> Strengths:
> - We have a great, mature protocol.

We think we have. We generally know that the stuff we use works, because 
we're dogfooding.
We might take the level of interoperability we have for granted, but I 
don't think it is. There is quite some marketing opportunity, also for 

> - There is an opportunity to capitalise on WebRTC, we should make sure we have a presence around that. Could we push XMPP to become the de-facto signalling protocol?

Let me pick that one, i've been working on that topic for the last year.
I was really annoyed by the fact that I saw more people asking questions 
about webrtc/sip than about webrtc/xmpp. If XMPP wasn't built for the 
web, then this applies even more to SIP?

So before I gave the "why should xmpp developers care about webrtc" talk 
at the summit in Brussels there were others trying to do the same.
See http://mail.jabber.org/pipermail/jingle/2012-March/
It did not lead anywhere however. Was it because the people discussing 
are not XSF members? I don't know.
A technical issue that certainly contributed to this was that at that 
time WebRTC wasn't readiliy available in chrome or firefox.
I'd note that my own attempt did not yield any immediate results until I 
used the wake-up call by google to convince my employer that publishing 
some of the javascript code I wrote under an open source license. 
Marketing game...

So... recently Lance took the code, refactored it and integrated it into 
stanza.io. We did some interop testing, I fixed about five minor issues 
and we were interoperable, doing a videochat over federation.
It took me about an hour to make sure that is interopable with my 
employers native c++ client and our mobile guy found a bug in his 
android client which took another five minutes to fix. Standards 
compliance pays off.

So later this week, the plan is to show this for the "Simple, silo-free 
WebRTC" talk at realtimeconf and webrtc camp.

So, coming back to your question... what is required for making XMPP the 
de-facto signalling protocol for WebRTC?
- make XMPP accessible for web developers
- make sure Jingle works
- make sure we can interop with existing jitsi client
- make sure it's easy to install the server side stuff for that
     (both xmpp and turn servers)

This requires collaboration. We know how to do that.

Quoting Adam from &yet @ 
   We've yet to see a company interested in selling WebRTC services
   point to documentation for using a publicly accepted standard.

I think the XSF is the... errr... shop that can sell that package.

More information about the Members mailing list