[Standards] A Meta-Discussion about the Standards Process
dave at cridland.net
Sat Jan 18 13:25:14 UTC 2020
On Sat, 18 Jan 2020 at 12:44, Marvin W <xmpp at larma.de> wrote:
> On 1/17/20 10:53 PM, Dave Cridland wrote:
> > In my experience, a lot of the draw for XMPP is the fact
> > it's an off-the-shelf solution with interoperable pieces. That's (at
> > least) a by-product of standardization.
> I see your point but I fail to see how it counters my point.
You seem to have failed to consider that it is possible that I was not
intending to counter your point but develop it further. :-)
> If they
> only care about the interoperable pieces, a WHATWG defining them for the
> most popular software is completely fine for them. They don't need a
> proper standard, they just need the off-the-shelf solution. You are
> exactly confirming that point with Pando by using off-the-shelf
> non-standard solutions by ESL. The important part for such uses is that
> this solution is cheaper than others, the standardization (= our unpaid
> work) is just what caused most of it.
I think your last point explains why my point is valid; indeed it echoes
the last statement of mine. Standardization is a method for commoditizing
useful software components, and it's a very useful and powerful method.
This means there are multiple suppliers available which drives down cost -
some of our suppliers have been open source, and some of them free. And for
what it's worth, Pando is interested in moving much more of its internals
to a standards basis precisely because of the advantages that successful
standardization provides - it amortizes the development costs across the
But please do not keep dwelling on "unpaid". This seems to be a repeated
theme for you, and I'm somewhat concerned by the implications people may
read into this. We are, I think, all volunteers in our work with the XSF,
though I hope that as many of us as possible can generate some indirect
income out of that work. Increasing the applicability of our work increases
the potential market, and that in turn makes more income available for us -
I certainly wouldn't have landed the same jobs without there being a market
for my rather niche skills. And throughout my career, even when I have had
an agreement from my employer to work on XSF things in work time, I have
maintained an agreement that I participate as myself, and not the company.
But really, if you're doing this just for the money you're in entirely the
wrong space. I can suggest stock trading - and your XMPP skills will be
useful there too. ;-)
As for a WHATWG market-share driven plutocracy, that has problems for all
consumers of the standard. WHATWG does not output useful specifications for
others to implement and adopt, it outputs a common platform that consumers
of the standard must use and conform to. The difference is subtle, and
indeed it would be highly desirable to have that common platform as well.
But that common platform, being geared to one market to the exclusion of
others, would reduce a lot of the input we get into the community.
> > And, you know, being able to say "Military Grade Security" to the
> > enterprise market and actually *mean* it wouldn't be all bad.
> > Losing Fortnite wouldn't, I admit, make a huge difference to most of the
> > community, though by the sounds of things, Guus would lose the respect
> > of his kid - and I can tell you that it gets a lot of interest when
> > you're trying to explain why XMPP is interesting to the crowd at FOSDEM.
> I see how it can help with marketing that known popular proprietary
> services use XMPP. On the other end, XSF (and the XMPP community) is so
> bad at marketing that I doubt it made a huge difference.
Being bad at marketing our efforts does not mean we should strive to be
worse, of course, but I readily agree we should be better at this.
> > I'm not sure that's true either - E2EE is really important to many
> > places, even walled gardens, and because the attraction of XMPP is a
> > proven technology that people can pick up and use, the fact that they
> > cannot with OMEMO is a serious problem. (Worse, OMEMO has been in use by
> > people presumably unaware that their software is inadvertently GPL).
> You are touching an interesting point here and while I don't want to
> open the OMEMO can again, I think it's worth mentioning how those two
> things you just said combine: If closed ecosystem companies primarily
> take off-the-shelf things they don't really care if the standard relies
> on a library that is under GPL, they care if there are off-the-shelf
> non-GPL implementations. So even if it turned out that OMEMO has no GPL
> issues, this wouldn't resolve their issue.
If a specification is able to be implemented by anyone without constraint
on their business model, and yet it still hasn't been, it's a failed
standard - de jure yet not de facto.
Failed standards do not carry the same benefit, this is absolutely true.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards