[standards-jig] informational vs. standards-track
matt at jivesoftware.com
Wed Jul 30 05:11:43 UTC 2003
> People can create "de-facto standards" without ever drafting a JEP,
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