[standards-jig] informational vs. standards-track

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


Dave,

> 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.

Regards,
Matt




More information about the Standards mailing list