[OpenID] JanRain library licensing (was: Re: On OpenID 2.0)

[Chris Messina]

Just to add a point from related experience and how critical it is to
have uniformity in library behavior... Think about web browsers and
how difficult it's been for web designers to deal with conflicting
rendering engine a)intrepretations of the speck and b) proprietary
extensions.

The result has been a pretty miserable experience for web designers
and oftentimes worse for website end users with non-dominant browsers
or user-agents.

While I appreciate Walkah's point and think more implementations can
lead to better specs, long term, if there aren't guidelines, shared
priorities and measureable ways to gauge compliance (test suites) --
brought about through strong leadership and a self-imposed mandate to
clarify but ultimately implement to a uniform experience -- I think
we'll end up with a fractured OpenID universe, susceptible to the
typical criticisms of open source and distributed development.

At the very least, we should respect each party to choose for her or
himself, but we must also force this decision to be made plainly, with
eyes wide open to the potential consequences of creating duplicitious
and/or deviating work.

Chris


On 5/11/07, Christopher St John <ckstjohn at gmail.com> wrote:
> On 5/11/07, Jonathan Daugherty <cygnus at janrain.com> wrote:
> >
> > # Generally, it will be completely obvious which implementation to
> > # pick, since it will be at the top of any Google search, followed by
> > # things like my imaginary Haskell implementation.
> >
> > Sure, it will be pretty clear which one is more mature, etc.  That's
> > *already* true.  And yet, it hasn't stopped broken implementations
> > from being created or used.
> >
>
> Well, rather than trying to stop people from implementing
> the spec, it might be better to work on making the spec
> easier to implement and verify. That involves clarifying
> wording, adding  addenda, and lots of non-normative
> text giving the experience of previous implementors. Plus
> conformance tests. It's a lot of work, but, you know, it's kind of
> traditional.
>
> What ended up happening for SOAP (an absolute interop
> nightmare) was the implementors hosted latest-and-greatest
> code on known endpoints.
>
> There was a more-or-less standard set of conformance
> tests that exercised known tricky areas. The tests showed
> the exact sequence of calls and content, so it was easy
> to verify behavior. (That's trickier with nonces and such,
> but there are ways around it) Tricky areas in this case
> might be having a set of "should be rejected" tests with
> bad hashes, for example.
>
> It was all very low-overhead but made it very obvious who
> was with the program in terms of conformance (comparison
> against the spec) and interop (comparison against other
> implementations) Writing the conformance tests was a huge
> help in clarifying the spec, since it forced people to confront
> ambiguous areas and holes.
>
> There's no defense against people who refuse to RTFM,
> but it is possible to make it easier for conscientious
> implementors and developers.
>
> Just a thought.
>
> -cks
>
> --
> Christopher St. John
> http://artofsystems.blogspot.com
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>


-- 
Chris Messina
Citizen Provocateur &
  Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is:   [ ] bloggable    [X] ask first   [ ] private