[Members] Publishing Non-Open-Standard Specifications
dave at cridland.net
Thu Jan 16 19:34:51 UTC 2020
On Thu, 16 Jan 2020 at 18:46, Daniel Gultsch <daniel at gultsch.de> wrote:
> Am Do., 16. Jan. 2020 um 18:32 Uhr schrieb Matthew Wild <mwild1 at gmail.com
> > On Thu, 16 Jan 2020, 18:18 Jonas Schäfer, <jonas at wielicki.name> wrote:
> >> Actually, I think adoption by someone except the XSF would be great,
> but I
> >> fear that this is not going to happen. Instead, we will see tribal
> >> like with AESGCM and the various MUC hacks which are barely documented.
> >> makes it hard for newcomers to implement a modern XMPP client.
> >> I, however, see your points about being an Open Standards organization
> >> having principles. Maybe we simply need to find a different venue for
> some of
> >> the extensions needed for XMPP-as-a-modern-IM-system. That feels like a
> lot of
> >> overhead for AESGCM and OMEMO though.
> > For what it's worth I'd accept PRs to modernxmpp.org, I already
> documented smaller stuff that way.
> > I'm fine with that outcome if the XSF decides it has other objectives
> above serving to document XMPP on the behalf of developers.
> A different venue is what this might ultimately boil down to because
> the underlying conflict here is that the open source community, which
> is super constraint on resources, sometimes has to focus on producing
> working code rather than 'open standards'. It's equally unfair of the
> XSF to try to force the open source community to produce open
> standards than it is for the open source community to essentially
> bully the XSF to accept something that clearly goes against the XSFs
> stated goals.
For what it's worth, there are plenty of Open Source developers who haven't
bullied the XSF or tried to reinterpret its documents and practice to claim
it allows them to do whatever they want. I have done plenty of Open Source
over the years, so I'd be one of them, but so are you, and Matthew, and
plenty of others who have focused more exclusively on Open Source then I. I
have zero interest in polarizing or dividing the community along the lines
of preferred software licensing.
I think there are important advantages in maintaining fully-specified,
unencumbered specifications. Yes, these are harder to write, and please
don't for a moment think that FLOSS developers are the only ones with
constrained resources - very few companies are interested in working on
Open Standards, in no small part because of the time it will take. But by
pooling the talent we have across a number of different companies, markets,
and more, we can get useful things done together. Sacrificing any
significant portion of that pool does not help anyone.
I appreciate that many people don't see the immense benefits that this Open
Standard stance has. I'll happily show people what Pando (my employer) has
been doing with XMPP over the Summit in person, but it's made many
patients' and clinicians' lives very much better.
I know that people have concerns that the technology we write gets used in
the military too - but if it helps, a major use is in medical response
there, as in this video: https://vimeo.com/7392430 ("JChat" runs over XMPP,
with no proprietary extensions at all - multiple XEPs have been published
in support of this).
There's lots of other use too, and it's very hard to get companies involved
in Open Standards work as it is; I don't think changing the organisation to
be not simply pro-FLOSS, but anti anything else, would help. Nor, of
course, do I want to undermine the pro-FLOSS nature of the XSF - we remain
the only SDO to mandate Open Source implementation, and we should continue
For what it's worth, I'm somewhat bemused by the "OMEMO is bad" argument
that floats about occasionally - often put into my mouth along with my
nefarious aims. If OMEMO were so terrible I was interested in killing it on
technical merit, then it'd be dead on its own - the reason it takes action
to resolve the mess it has put us in as an Open Standards Organisation is
because it is fundamentally solving a problem we have no other deployed
Documenting XMPP is what we do. However, OMEMO is in conflict with how we
do it. And this is the mess we find ourselves in.
If our best solution to this mess is to publish things which are not open
standards, that's not ideal.
My proposal is that we do so carefully, and ensure that anyone coming to
our documents clearly understand that there are licensing (or - shudder -
patent) issues existing in a specification which is otherwise aiming toward
the same high quality as everything else we do. A distinct XEP Type seems
to represent the right level of compromise here, and being a compromise, I
mean "least worst".
I would hope that this is not treated as an invitation to deliberately
burden developers with the GPL or other encumbrances, but is taken in the
spirit it's offered - as a rare solution to unusual cases.
The question of whether we need to lower the bar to Experimental or (as Kev
suggests) allow and encourage development in Inbox is another question, and
I'd rather answer it separately.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Members