[Standards] Deprecating Privacy Lists

Ben Langfeld ben at langfeld.me
Mon Oct 12 14:53:01 UTC 2015

On 12 October 2015 at 10:54, Vitaly Takmazov <vitalyster at gmail.com> wrote:

> > who complain about specs they want not existing believe is responsible
> for doing this for them at no cost, and why?
> Hi from 2015!

Hey there!

> There are number of options:
> 1) Get an existing protocol/library which is more suitable for the
> task. It can be "no cost", or much cheaper than fighting with
> inconsistent XMPP protocols and specs.
> 2) Develop protocol from scratch. It may cost developer time, but in
> most cases it is still cheaper. And you still can reuse existing
> ideas, specs, tools, experience, etc.
> 3) "Extend" XMPP without documentation and standartization, (whatsapp way)

And anyone is welcome to choose those options. If they do so, however, they
forfeit their right to complain that somehow they got "poor service" from
the XSF as if they were paying for it ;)

> And the counter question: who exactly these developers who want to
> contribute to XMPP community "at no cost"?

Take a look at the list of RFC and XEP authors for starters. As far as I am
aware, the XSF didn't pay any of them for their work, nor do the people who
rely on XMPP specifications pay for a license to use them, or a
subscription for new ones to be written based on their requirements.

> They already must be
> interested and motivated. How existing XMPP/XSF state (inconsistent,
> incomplete, absence of libraries, clients, name it) can motivate new
> developer to join it?
> ---

Maybe a sense of contributing to the greater good? Maybe for a head-start?
It doesn't really matter. If they choose to contribute, great! If they
choose not to then humble feedback is potentially useful, but complaining
and demanding is not. Unfortunately we seem to have got into a mentality of
open-source entitlement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151012/87c07c64/attachment-0001.html>

More information about the Standards mailing list