[standards-jig] JEPs and Jabber Adoption
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
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
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 ;)
Software Engineer @ Splendo
More information about the Standards