On Sat, 18 Jan 2020 at 12:44, Marvin W <x...@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 entire market. 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. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
