[standards-jig] informational vs. standards-track

Matt Tucker matt at jivesoftware.com
Wed Jul 30 05:11:43 UTC 2003


> People can create "de-facto standards" without ever drafting a JEP, 
> Matt. 

No, that's simply not true. There must be a way to get others to adopt 
your protocol extensions. The only existing mechanism in our community 
for doing so is the JSF JEP processs.

A "good" way to create a de-facto standard is through merit or 
popularity. When a de-facto standard happens for those reasons, at least 
it's not a bad thing in general. However, I think the current 
informational JEP process perverts those normal criteria. Simply by 
writing a JEP, however crappy it is, you have the ability to create your 
own de-facto standard since the document has been published by the JSF 
and will get viewed and implemented by the community since they will 
assume it's a "standard".

> Selection of 
> any given protocol as a standard is still left up to the implementers -- 
> those who choose to implement the JEP. A standards-track JEP does not a 
> standard make.
> What power does the JSF "membership" (such that it is) really _have_?! 
> None. The Council holds final power over a protocol's "approval" -- but 
> even that doesn't mean much.

I'm surprised that you believe that. I write an Open Source client 
library and generally only consider extensions to it that are JEP's. I 
think other developers mostly feel the same way -- they absolutely 
depend on the JSF to provide direction on what they should implement.

> I view Peter's post as a question which 
> drives at the very heart of the value of the JSF membership. Are we here 
> to act as a Community that encourages and builds and collaborates (i.e. 
> running code and rough consensus!), or are we here to be a 
> standards-body that gets into analysis paralysis?

Nobody wants endless, pointless protocol debates. We all want rapid 
progress. But, a certain amount of process is a good thing. It provides 
a framework for collaborating on protocol dev and for resolving 
potential conflicts during that collaboration.

> I don't know the answers, but I do know we need to ask the questions. I 
> also believe that we must reduce the amount of process, not increase 
> it.  We must get back to our roots of moving forward, and away from 
> these long-winded, often circular, protocol discussions.

I hate process as much as the next developer, but everybody publishing 
JEP's with no approval process doesn't seem like good protocol design.


More information about the Standards mailing list