[standards-jig] JEPs and Jabber Adoption

Tijl Houtbeckers thoutbeckers at splendo.com
Sun Jun 29 03:25:22 UTC 2003

David Waite <mass at akuma.org> wrote on 29-6-2003 5:16:29:
>Tijl Houtbeckers wrote:
>> Can you imagine linux kernel hackers debating for years about what 
>> new scheduler to use, and have nothing beyond very experimental work
>> happing cause some fictional "linux council" would refuse to advance
>> one beyond experimental?
>> Ofcourse not.. we have a whole bunch of schedulers outthere now.
>> They're not "experimental" either, they are real implementations,
>> outthere, and being used. Wich one will make it into the official
>> kernel branch? And maybe some that won't will still be maintained 
>> cause they perform better under special circumstances. You could 
>> compare that to advancing to "ACTIVE" or "FINAL". 
>All the comparisons to the linux kernel on this thread are simply not 
>- variances of the linux kernel share a large amount of code-base; 
>they are not independent from-scratch implementations.

So do JEPs (the Jabber protocol)

>- the linux kernel does not have a standards organization behind it - 

(exactly why I brought it up to compare it, there is no standards 
organization with rules like ours behind it. So that's a strange point 
to make). 

>when you take the main kernel tree as a cross-section, it is ruled by 
>dictatorship (although the dictator definitely is good at choosing 
>competent advisors).

However, the dictator is far from all powerfull. So much in fact, you 
could hardly call it a dictator. In fact, the dynamics behind it are 
that of a selforganizing anarchic community (never noticed how everyone 
just writes up patches all the time and submits them to world+dog? yet 
they still end up with compliant goodworking systems). There's just a 
clever man behind it that picks those dynamics up and makes a real good 
branch out of it. Hardly a dictator. 

>- changes in a linux kernel do not affect the ability of other users 
>to communicate with your system (or rather, I should say 'working 

Subsystems affect other subsystems, or even break them. 

I'm not arguing that the development of the linux kernel and a more-
than-IM protocol and the software around it are exactly the same. The 
requirments *are* somewhat different. However, the community behind 
does have many simularities. There's a lot of energy and good will in 
both. But because our requirments are different we try to shape those 
forces in a different way, wich is very understandable. But I do think 
too much of that energy is getting lost the way we do it now. Also, 
there's seems to be some (I hope!) irritional fear that our community 
posses none of those selforganising capabilities and thus needs big 
brother JSF to hold hands every step. While, looking at the past, we've 
already proven the opposite. 

>Think if the W3 had decided that they would promote every web browser 
>vendor to develop versions of HTML based on their customer needs? Of 
>course all the vendors did this originally; they definitely don't need 
>the overhead of a standards process in order to do so. What a 
>standards body brings to the table is interoperability and conformance.

Those vendors sure did what you suggested. But did W3C allow them to? 
Hell no. So what was the result like? Well, very good.. if you have 
Microsoft stocks. W3C has learned from this and are doing better with 
XHTML, will we? They too realised, we're not just making a standard 
here, people are building these browsers and applications and they have 
requirments it. 

>The JSF will not be able to conquer large-scale issues until it finds 
>a way to organize all the strong and different viewpoints of its 
>members into a single process. This is not always going to be possible 
>to do by having someone take control of the reins, such as it was with 
>multi- user chat and is currently with pub-sub.

I agree, MUC is a nice example of how it could work, pub-sub however is 
an example of where a lot of good will and effort has been smothered. 
Many people tried to do work on this, but got blocked by the proces we 
force upon it. Thankfully we'll still end up with something reasonable, 
or even pretty good considering the idea is we can extend it later. 

I still say, the way to determine wich of those viewpoints is good or 
sufficiant should shift more towards useable implementations. (how 
exactly doesn't matter that much to me). There will not be interop. 
hell as a result of this, the community is mature enough to prevent 
that. On top of that, once it's clear wich proposal is prefered (wich 
will most likely be the one that almost everyone uses by then anyway), 
the JSF will be able to make a very clear difference to everyone on top 
of that. ACTIVE/FINAL still sounds very different from RETRACTED, 
DEPRECATED and OBSOLETE. "You're still running that BETA of Exodus that 
supports that DECPRECATED protocol? c'mon!!" 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list