Can I butt in?<div><br></div><div>There are a couple problems with this motion, and with RefreshMedia's approach.</div><div><br></div><div>First, I need some more information:</div><div><br></div><div>* What was the wording of the motion to hire Refresh to build the election site in the first place?</div>
<div>* Was OpenID authentication a requirement of the solution? I presume that it was, and if so, the intention was to support the OpenID 2.0 specification</div><div>* If that was the case, did Refresh look into the existing Rails OpenID plugin before they started their work? If they had, surely they would have realized that the plugin would not pass muster for the task at hand and that, to complete the work order, they would need to update the plugin to support OpenID 2.0.</div>
<div>* If they did not look into the Rails OpenID plugin until later in the project, or used the old plugin without modifying it, and then received complaints because it didn't support OpenID 2.0, and then went with RPX because it was a ready-made solution, then the problem here lies with Refresh (coupled with the need for such vendor-selection decisions to be made transparently).</div>
<div><br></div><div>In other words, if Refresh were hired to build the election system, and one requirement of that work was to enable OpenID 2.0 authentication, plugin or not, it was up to them to enable that functionality.</div>
<div><br></div><div>They ended up enabling the desired functionality by using RPX as a stopgap, and now, as we would like to decouple the election system from a vendor-specific solution, we're left with a non-functioning application.</div>
<div><br></div><div>I like the Refresh guys and think they've done good work, so I'm not out to smudge them or anything, but it's hard for me to comprehend why we should spend another $2000 on work that should already have been paid for, or have been covered in the original work order.</div>
<div><br></div><div>Now, if that original work order was not specific about how OpenID was intended to work (therefore OpenID 1.1 compatibility would meet the terms of the agreement), then I suppose it does lie with the foundation to figure out 1) how to disentangle a vendor-specific solution (or to go about picking a vendor solution in a fair/transparent process) and 2) how to re-enable the sign in functionality of the election application given the state of the Rails plugin.</div>
<div><br></div><div>The problem with Scott's motion is that it conflates several issues into one:</div><div><br></div><div>* enabling OpenID 2.0 authentication for the election app without relying on a vendor-specific solution</div>
<div>* updating the obsolete Rails OpenID plugin</div><div>* funding the development of open source software for a specific platform</div><div><br></div><div>I know that Scott was intending to address these three issues with this motion, but as worded and proposed, fails to confront existing problems: namely, should Refresh be responsible for delivering OpenID 2.0 functionality in the elections app given the money already spent?</div>
<div><br></div><div>If not, then we can look at sponsoring and updating the Rails plugin through some other mechanism later. And if the elections app is not needed for some time after the current election is over, then we can simply shut it down pending community-led improvements to the Rails plugin.</div>
<div><br></div><div>We can certainly argue over how best to spend $2000 to facilitate improvements of the OpenID libraries, but first we should ascertain whether Refresh owes us a running implementation of OpenID 2.0 code given what was already spent on their work.</div>
<div><br></div><div>Chris</div><div><br>P.S. Sorry if that was wordy; it's freezing in my apartment and moving my fingers rapidly is keeping them warm!<br><div class="gmail_quote">On Wed, Dec 17, 2008 at 7:10 PM, Scott Kveton <span dir="ltr"><<a href="mailto:scott@kveton.com">scott@kveton.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">> I think I understand where you're coming from, but I'm not convinced it is<br>
> critical, and that's partly because I don't have an issue with us continuing<br>
> to use the JanRain RPX as long as everything is above board and transparent.<br>
<br>
</div>Great. We'll just switch it to the solution Vidoop (my company) is<br>
baking after the first of the year then. I'm saying that a bit tongue<br>
in cheek but I think you get my point.<br>
<div class="Ih2E3d"><br>
> That said, I'm personally all for us setting aside a non-trivial portion of<br>
> the budget explicitly to fund open source development. But that is for the<br>
> incoming board to decide and is worthy of a debate on its own.<br>
<br>
</div>I'm actually -1 to this ... lord knows Google spends enough on this<br>
already ... :-) Again, I'm not proposing to fund the creation of open<br>
source software for the sake of open source software; I'm saying let's<br>
make the membership software vendor neutral and release the results as<br>
open source.<br>
<div><div></div><div class="Wj3C7c"><br>
- Scott<br>
_______________________________________________<br>
board mailing list<br>
<a href="mailto:board@openid.net">board@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Chris Messina<br>Citizen-Participant &<br> Open Technology Advocate-at-Large<br><a href="http://factoryjoe.com">factoryjoe.com</a> # <a href="http://diso-project.org">diso-project.org</a><br>
<a href="http://citizenagency.com">citizenagency.com</a> # <a href="http://vidoop.com">vidoop.com</a><br>This email is: [ ] bloggable [X] ask first [ ] private<br>
</div>