It’s Thursday morning, and I’m in Portland, Oregon at the 2007 O’Reilly Railsconf, all about the web programming language/environment/framework called Ruby on Rails. I was introduced to Ruby on Rails by a friend/associate who I hope to be doing some work with soon – we’re part of a group looking for funding to develop some applications. I program in a few languages, mostly PHP, but agreed to learn Ruby on Rails after being introduced to it.

Ruby on Rails, it turns out, is a controversial language, in a way that is very reminiscent of the Apple vs. everything else debate. Rails enthusiasts are very attached to the platform, and adherents of Java, C, and even PHP, tend to be very skeptical, with complaints that the structure is too rigid and that the language only goes so far. They might be right – I’m not fluent enough yet to know. But there are a few definite things that have me interested in Rails.

1. Rails abstrats the database creation and management process in a really fascinating way. Using the MVC framework—model, views, controller—you basically develop your database using plain english to describe the relationships between tables. This really works for me. To create the database, you write some very simple code that adheres to certain naming conventions, and then you can manage the database almost exclusively from the code.


2. Once the database is created, Rails uses a method called scaffolding to automatically create forms for database manipulation. With one line of code in your controller, you can very simply grab data from multiple tables using a simple syntax. Rails makes it all very, very easy.


3. I’m looking for a holy grail, of sorts, something that falls halfway between a programming language and a content management system (CMS), and this comes close. What can we use to rapidly develop interactive, web-based applications that doesn’t lock us into the type of assumptions that Drupal and (the current version of) Joomla do, but don’t require building the whole thing from scratch? Ruby on Rails is still a pretty complex thing for most techs at non-profits to budget the time to learn, but it’s intriguing, as is the move in the next release of Joomla to have it sit atop a Ruby on Rails-like framework (that, unfortunately, lacks the database routines).

I’m also looking at Javascript/ajax libraries – I’m in one right now on Prototype and scriptaculous, but the presenter is the developer of scriptalicious and his presentation style is somewhat coma-inducing…

A quick addendum to my last entry:

First, my apologies if you’re trying to play. For some reason, the DNS change that will allow you to access openid.techcafeteria.com is taking a looonng time to propagate. I’ve asked my ISP about this. And it makes no sense to give you the ip or an alternate name – you need the actual name to get this working.

Don’t trust me to maintain techcafeteria.com 24/7 for as long as you may live? Good thinking! I’m hosting this on my home box, because I can’t hack PHP sufficiently in order to get it going on my ISPs system. So this is what’s cool about OpenID. It’s relatively easy to become an OpenID provider, if you have your own server. I think it took me two hours or so to get it all set up. So there will be plenty of providers out there. And OpenID gives you an option for setting up a permanent address on any server where you can create a simple page (regardless of whether it’s your system or if it has anything related to OpenID installed) and then referring it to your OpenID provider. So, if I take my system down (I do that about twice a year), you can register somewhere else and simply point your URL to their system. It’s very flexible, and you’ll have the instructions in front of you after you create your ID on my server.

In addition to OpenID.net here are two important resources:

OpenID Enabled is a wiki devoted to OpenID. Very thorough!

The OpenID Directory is an early stab at collecting all of the sites that allow you to log in via OpenID. It’s also an OpenID provider, if you’re looking for that backup.

Yesterday, Sun announced a rollout of OpenID for all of the company’s employees, and joined Microsoft, Yahoo!, AOL and others in embracing the emerging Single Sign-on standard.

In order to deepen my understanding of OpenID and what it’s ramifications might be for me and the non-profit community, I’m diving in and inviting you to join me. I’ve set up an OpenID server at http://openid.techcafeteria.com that you are welcome to use to establish your own ID. From there, you can also manage your identity, optionally revealing some demographic info to sites that you authenticate to (completely optional!) and managing the sites that you have authenticated to.

I’ve also set up my blog to allow for OpenID as a registration option, via a handy Wordpress plugin.

Some notes if you want to join in:

• If you sign up, you might want to then register on my blog and leave a comment on this entry. That way we’ll know who we’re playing with.


• If you have trouble accessing http://openid.techcafeteria.com, wait a few hours – it should be fully reachable by Friday at the very latest. I just set up the DNS a few hours ago

If you don’t know where to use OpenID other than my blog, note that plugins are available for Wordpress, livejournal, Drupal, MediaWiki, and other community-based applications, as well as a module for apache. Technet has articles on how to integrate it with ASP sites. So, it’s out there – look for the logo:

Okay, I finished the big job of migrating my blog from it’s old home to my new digs, and I think I have the bugs out, with thanks to the two blogs that linked to my OpenID article, and the two people who let me know that the email was broken (making it impossible for people to register). We’re off to a good start!

I offered some preliminary thoughts and asked a question about OpenID, proposing that, while this is a boon for users, it might have a negative impact on an organization’s ability to coax contact information out of web visitors, as providing personal info will no longer be a requirement for authenticating to a web site.
Johannes Ernst, a man who designs identity management software for a living, responded on his blog with a few counterpoints (which I’ll brutally summarize):

1. People often present false information in contact forms anyway;


2. “Because users can provide their OpenID that they also have provided to other sites, the site can actually learn more about the user — which other websites they frequent, for example.” Johanne qualifies this one with the rider that people won’t necessarily use their OpenID to share such data.


3. With control of their identity, the visitor might feel more confident about sharing information.


4. With single sign-on, and easier access to the authentication-required content, visitors might be more compelled to join and share.

Simon Willison, a co-creator of the Django Web framework, anticipated my question and replied on January 10th. Simon makes the clear point that OpenID will only replace the “enter your name and type a password twice” portion of an online registration. It won’t fully replace requests for further data and confirmation, such as the graphical Captchas that we’re all getting so used to. In fact, he proposes, the fact that a user has an open ID doesn’t mean that they aren’t a spammer—we shouldn’t accept it as full authentication, just a convenience for the password tracking part.

Simon has me fairly well sold that this isn’t as big a threat as I thought. But I still have a lot of questions about the idea, and I’m curious as to how it will play out once the standard is established (assuming it will be – I suspect so). if the authentication is as weak for the web service as Simon suggests, will an industry like SSL arise, adding verification to OpenID authentication? And I’m still intrigued as to what conventions will grow out of everyone having a personal web address, which, of course, will lead to some sort of web page.
Johannes made a comment that really intrigued me on his post, when he said:

” Personally, if I have a choice between knowing a URL pointing to your blog, and having the information you typed into a web form that I put up, I take the blog any time. (That might even be true if the form’s data was all correct!) That is not data that your typical CRM system knows how to manage, but as we all know in the blogosphere, extremely valuable to gain some view on the user’s social network and reputation and interests.”

Johannes has a pretty interesting idea for a marketing app there. While he suggests that the data is free-form, I’d counter that – most blogs follow very standard conventions, and many bloggers (hey, me included!) use the standard text that comes with our blogging platform to denote them. So just as HR staff no longer “read” resumes, how far can blog scanning be behind?

Earlier this month, in the Q&A following my Managing Technology 2.0 presentation at the NTC, I was asked how OpenID would impact organizational data management issues. I was somewhat familiar with OpenID, in it that I knew that it was a proposed standard for single sign-on and identity management on the net, but I hadn’t paid a lot of attention and I think my answer, that it would make verifying user data easier for non-profits, might have been way off target. So, to clear it up, I did some research.

The “I’m feeling lucky” response from a Google search for “Open ID” is the very informative home of the project, OpenID.net. This site does a great job – it is largely an extremely geek-speak affair, but it starts off in very plain english. The proposed standard is that every person, just like every web site, can have a URL of their own that is their open ID. Along with the ID, they will have an identity provider that serves as the home for that ID, and provides the authentication service. With the standard in place, it would work like this:

1. You connect to a service (“consumer“) that supports Open ID.


2. You input your URL in the Open ID login field.


3. The consumer redirects you to your identity provider (the target of your url),a nd they prompt you for your password.


4. The identify provider then sends back a “yea” or “nay” based on whether you successfully authenticated (this works very much like a credit card authorization).

A few nice details about the specification:

• You can be your own identity provider if you have the resources.


• The specification calls for a strictly browser-based interaction, no javascript or additional software required.


• Open ID login fields will have a graphical identifier:

The two clear advantages of OpenID, from a net user perspective, are:

1. Single sign-on. No more long lists of passwords for myriad web sites or, worse, as we know many of our loved ones do, single passwords being used at dozens of sites.


2. Privacy – no need to provide passwords or email addresses to services in order to authenticate.

Microsoft’s Passport service was the biggest stab at identity management on the net to date, but it suffered from the initial premise that you should trust a convicted monopolist to manage your identity, and then from some serious security flaws.

So what does this mean for non-profits? Well, unless I’m missing something, it’s possibly a threat, and it will probably put orgs in a bit of a catch 22. Like most companies, you want to capture contact data from your web visitors. It’s key to your CRM strategies. Supporting Open ID removes the most compelling reason for them to give you that info – access to your interactive web services that require authentication. You’re going to have to beef up the begs and rewards for sharing more data if you support it. But, if you don’t support it, and it becomes a widely-spread standard, you’re going to look unethical.

I do think that additional trends and standards will grow around the personal URLs. I can’t see why they wouldn’t grow into Plaxo-like contact pages, to a small degree. But I doubt people are going to standardly publish addresses, phone numbers, etc, for the same reasons why you would hesitate do that on MySpace or Yahoo!. OpenID will not be a contact verification standard – it’s an authentication standard. Like a lot of things that threaten our marketing efforts, we’ll probably all really appreciate it, at least when we’re not in the office.