[standards-jig] JEPs and Jabber Adoption

Tijl Houtbeckers thoutbeckers at splendo.com
Sun Jun 29 02:23:16 UTC 2003

Ryan Eatmon <reatmon at jabber.org> wrote on 29-6-2003 4:17:53:
>Tijl Houtbeckers wrote:
>> I've been thinking a little more about this, and the more I do, the 
>> more I think that the JSF and Jabber Council were not meant to have 
>> this effect on the Jabber community. I'm seriously starting to think 
>> an anarchic "linux-style" approach without a Jabber Council would 
>> have brought a lot more enhancments with a lot less effort. 
>The JSF is there to provide a central place where outsiders can look 
>to see what is shaping Jabber.  The Council is there to provide a 
>central group that decides what is and what isn't Jabber.  Ideally the 
>Council is made up of experienced protocol people who can 
>intelligently look at a JEP and point out problems and suggest 
>improvements, or just deny the JEP all together.
>What I find interesting is that you think Linux is developed by 
>anarchy style.  And that's just plan false.  If you mean Linux to be 
>the kernel, then there is a central group that everyone looks to 
>(kernel. org), and central intelligent body (Linus) who accepts or 
>denies addition to Linux.

Wrong, there is a main branch of the kernel that is maintained by Linus.
 There are several other active branches as well, for example by Red 
 Hat, etc. With linux you do not have to discuss your ideas till a 
 council approves of them and moves them forward. Ofcourse, you don't 
 have to consider the council opinion with Jabber, but it's simply not 
 attractive to implement your ideas before the council takes the step 
 of making them draft. With linux quite the opposite is true. You can 
 write experimental major patches to the kernel, and people will use 
 this for testing. Also, if it's a nice idea, other coders will mostly 
 take in account your patch (even if it is experimental) and make sure 
 their own patches don't break it. You can then evolve your patch into 
 a stable usaable product, all this without a single council or person 
 having to mark your idea as "good". Then Linus, or one of the other 
 persons with CVS acces to the main branch can choose to accept your 
 idea. Even if they don't, someone else might choose to put it in their 

>If by Linux you mean all of the other free projects that make it up a 
>distribution, then I'd like to point out that SOMEONE is in charge of 
>each of those projects.  You can't just come up with something and 
>expect them to include it their software.  If you want to get it 
>included you need to have conversations with them, build a 
>relationship, code to their style, etc...

Ofcourse you can't. But they sure as hell won't make you discuss your 
ideas on a mailinglist for months and have everyone else on that list 
agree with your idea.  Rather they'll say, write that patch, ask me for 
help if you need, and when it's done, we'll see how great it is. 
Ofcourse if you're gonna build something they don't want (no we don't 
want Clippy in KOffice!) you shouldn't bother, but that's clearly not 
the case here. We're talking about solving a problem that we all agree 
should (by all means) be solved. 

>Or you can decide that you want to invent your own piece of software 
>to do what you want to.  Which is what I think you mean by anarchic 
>style. Feel free to NOT write a JEP and go invent your own protocol to 
>do whatever it is you need in your client.  But much like a new 
>project, you will be on your own to promote and get people to use it.

My point is, there *should* be no reason I can't invent something nice 
and put a JEP out for it so others can use it too. And benifit from the 
community by having little bugs fixed I didn't see, and adding usefull 
functionality I didn't immidiatly think of. 

However, somehow this has become an impossible thing to do. You come to 
the list with a good idea, but immidialtly people will start to say you 
should use *their* idea instead. The council splits or sides and we're 
stuck at that place that makes everyone tired. 

>If you want your new protocol to be considered part of Jabber, then 
>you are going to have to convince people why it should be.  Those 
>people are the JSF, and the Council.

And what this comes down to is the council decides what ideas should be 
implemented and *how*. Why don't we just let the council right all the 
JEPs themselves? We're almost at that situation anyway. 

>The convincing comes in the form of a 

JEPs (ideas) are being blocked that solve the problem, and are 
technically ok. This on the basis of the subjective *opinion* of the 
council or part of it, that a different idea should be used. Why? That 
is in many cases subjective. Rather, I'd see a much more objective role 
for the council in the early stages, up to a point where there's 
actually a solid base for the council to make their subjective decision 
(is this Jabber or is it not?) on. 

>And much like Larry Wall and feature requests that were made to 
>Perl 6, 

Not sure what you mean with feature requests here, but if you mean 
packages to be included with the standard Perl distro, then you're 
submitting an implementation. If you mean the new language semetics for 
Perl6, as far as I know that's not even remotely comparable to what we 
do or try to do here. 

>you should not be surprised if the JSF/Council decides that 
>your idea is not fitting with Jabber.  But we will take the input into 
>consideration and probably merge it into an existing JEP so that it 
>all works nicely. 

That's a nice thought, but it's not happening.

>Ryan turns to address everyone:
>My complaint about the current state of affairs is that we seem to 
>have three groups of people in the JSF.
>One group cares and gives a lot of time and works together within the 
>rules to find solutions.  They work hard to try and take everyone's 
>input and merge it to fit what a JEP is trying to provide.
>One group complains about a JEP because it is not how they would have 
>designed it, and rather than work with the existing JEP authors to 
>improve the existing JEP, they create new competing JEPs.  They work 
>hard to undermine the structure that the JSF has set up.

The problem here is the two ideas are not always compatible. That 
doesn't mean one is that much better than the other. For sure, in many 
cases there is absolutly no way of determening that, let alone during 
the experimental theoretical phase. Things that come down to taste 
even! But it does mean if the council sides with one idea (or 1 in the 
council) and you with the other idea, you, and all the other that 
worked on that idea can throw away that work. 

>One group just sits back and doesn't give any input.
>My feeling is, that if you do not agree with the structure of the JSF. 
>If you do not agree with the rules that we have set up and created. 
>Then by all means, DO NOT JOIN the JSF.  Do not join and then complain.
>    Do not join and then not participate.  Do not join and then be a 
>road block to progress.

I'm not lashing out against the people that make are in the JSF and 
council. I'm sure they're all good people that put in good effort. As 
far as I know I did not join the JSF? Rather the jabber community (or I 
try to anyway). Wether it's the proces as described in the bylaws of 
the council, or the way it is put into practise, I have the feeling 
something *is* wrong. I doubt I'm *all* alone in that (though some 
might have left the list already). 

I've given my view on the situation, I'm not sure I'm entirely correct 
(call my opinion EXPERIMENTAL if you like :), but I think it comes down 
to it that new JEPs do not get enough room to show their worth, and 
thus a lot of effort is waisted. 

I asume the rules for the JSF and council are not set in stone. I'm not 
suggesting that just cause I say so everything should change now. 
Merely I give my opinion to encourage debate and see if others have 
simulair concerns. 

I think I must have said it zillion times on this list by now, choice 
is good. Well here's a new one, competition is good too ;) 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list