[Foundation] my thoughts

Matt Tucker matt at jivesoftware.com
Thu Jul 10 17:15:23 CDT 2003


Peter,

Damn, nice ballsy email. Perhaps people are in too much shock to have 
made many replies yet? :)

I agree that the current JEP process is a bit broken at the moment. A 
lot of other people seem to feel the same way (the file tranfer 
discussion). I also understand the temptation to go with a less formal 
process than what we have now, especially given the Open Source roots of 
Jabber.

Can you clarify something, though? Is it implicit in your email that 
you'd see more standardization work going through the IETF eventually, 
or no? That seems like a potentially valid path, although it could be a 
bit slow.

In any case, I'd argue that we need a more formal protocol process, not 
a less formal one. A good model might be the Java Community Process 
(http://www.jcp.org). There, anyone can bring a proposal to the table. 
If the proposal is deemed worthy of consideration, a small group of 
experts is assembled (under a spec lead) who then work in private to do 
an initial version of the spec. The spec then goes through a public 
comment/review process and is approved or rejected. All this work is 
done on a specific schedule.

It's the expert group idea that I think is a really good one -- it would 
get the right people working on each JEP with enough process in place to 
make sure all the right viewpoints are considered in a timely fashion.

The dangers I'd see with not having any kind of process in place:

  * In general, I think anarchy can work for software but not protocols.
  * What happens when there is significant disagreement over the right 
approach for implementing a particular idea (such as file transfer). 
Without any process to resolve conflicts in place, we may be left with 
competing protocols and developers that are forced to support both to 
cover all their bases.
  * There is a greater danger that vendors will just implement XMPP core 
and ignore extensions. If some organization can roll-up the important 
extensions into a more cohesive whole, that gives those extensions a 
better chance of being implemented.
  * How does a developer know when to implement a JEP? If it doesn't go 
through an approval and revision process we could be left with a very 
fractured set of software out there all implementing different versions 
of different protocols.
  * When larger companies come in to adopt XMPP, they may be tempted to 
"embrace and extend" the protocol however they'd like. Without some sort 
of standards body in place, this too can lead to XMPP systems that can't 
interoperate well.
  * There needs to be a central place to gather all protocol extensions 
or they just won't get implemented. If anyone post a JEP without some 
approval proces in place, a lot of crap will get through. How will 
people know which protocols they should implement and which ones they 
can ignore?

Anyway, lots of interesting stuff to consider here.

I did want to respond to one point in particular:

 > 3. We terminate the standards-jig mailing list and discuss
 > all protocols on the jdev at jabber.org mailing list.

The traffic on both lists is quite different I think. The standards list 
is generally people that are developing new extensions to the protocol. 
The jdev list traffic is generally people discussing how to use existing 
tools. It seems useful to keep these discussions separate. Many 
developers don't care about protocol -- they just want help using 
existing tools and the jdev list seems to be helping with that pretty well.

Regards,
Matt

Peter Saint-Andre wrote:

> I've been thinking quite a bit about the role and purpose of 
> the JSF of late, and I've come to the following conclusions:
> 
> 1. JEPs provide documentation of protocols that have been or 
> are being implemented.
> 
> 2. The distinction between standards-track and informational 
> JEPs is bogus. Some protocols are more popular than others, 
> and they become "standards" in an organic fashion (de facto, 
> not de jure).
> 
> 3. The distinction between protocol developers and implementers 
> (standards-jig vs. jdev) is the slippery slope to irrelevance.
> 
> 4. The jabber.org website is more than JEPs -- it contains other
> documentation, software links, news, etc. This is right.
> 
> 5. The Jabber community is more than JEPs, and it is the Jabber
> community that matters, not the JSF's so-called standards process 
> (except as JEPs provide documentation to developers).
> 
> 6. The JSF is at best an unnecessary distraction, and at best 
> positively harmful.  
> 
> Therefore I suggest:
> 
> 1. We abolish the JSF and its so-called standards process.
> 
> 2. We keep JEPs as informational documentation ("jepforge", 
> anyone?). We keep the JEP editor in a role that is purely 
> editorial, but abolish the Council. There are no de jure 
> standards, only de facto standards.
> 
> 3. We terminate the standards-jig mailing list and discuss 
> all protocols on the jdev at jabber.org mailing list.
> 
> 4. We retain www.jabber.org as an informational website and 
> community hub, as it is now.
> 
> No, this is not an April Fool's email. I am completely serious 
> about everything I've written above.
> 
> Peter
> 




More information about the Members mailing list