OpenID Usability Non-solutions
At work we’re building our new centralized authentication solution. Allowing OpenID logins is not part of our first release, but it’ll follow at some point in the future, at least if Rob has any say in it. Even though I’ve had an OpenID identity for as long as anyone, use mine extensively and have even implemented my own provider, I’m not convinced it’s a good idea to only support OpenID logins.
The approach taken by Magnolia (who only support OpenID logins these days) and IDSelector (which is supposed to make OpenID usable) is allow users to log in with any of their existing accounts that offer OpenID (Yahoo, Livejournal, AOL, etc). The thinking behind this is that users don’t have to remember a new username and password this way. This thinking is backwards. Users already remember their usernames and passwords. Web browsers remember passwords and people use consistent usernames and password patterns across sites. Both software and humans have adapted to this problem. People haven’t adapted to remembering which account they used to sign into a site.
If I sign up for Magnolia using one of the accounts I have (of the 7 external account types they offer, I have 5) what happens in 2 weeks when my cookie expires and I need to log in again? Even though I might use the same password across all of those accounts there isn’t an easy way for me to remember which account I chose to use to log in. Fundamentally, this approach to OpenID doesn’t give users less things to remember, but more.
I think a better approach is for site to allow either local logins or OpenID identities. When offering OpenID logins it’s important that sites help educate users about the value of OpenID rather than hiding it.
Source Control for your Operating System
I think that I’ve realised why I feel so uncomfortable using MacOS X and Windows for “Real Work”. They’re fine for playing MP3s or browsing the web, but when it comes to developing software I get scared.
For me, developing my own software usually involves installing other software and upgrading existing software on my computer and when you don’t have a package manager that’s really hard to do reliably and reproducably. I’ve tried doing this by hand, keeping track of what versions of what I installed where with what build flags, trying to write scripts that can reproduce my build environment and trying to keep track of which dependencies are build-time and which are run-time. I’m bad at that, but that’s the kind of thing that computers are really good at.
Now, I know that Cygwin and MacPorts each have their own pseudo-package system, but that only covers the UNIX libraries and utilities that are ported, not native tools, and they don’t integrate with the tools you use when producing packages to ship. When you’re developing a Mac or Windows application how do you keep track of which libraries need to be included in your installer or disk image? There must be a trick, but I’ve never come across a tool for the job. The Debian packaging tools do an amazing job of analyzing the dependencies in software that has been built and mapping them to package dependencies. There are even tools for creating VMs that you can use to test that the autodetected dependencies are correct. All automatic, reproducable, testable.
So today, out of the blue, I found a metaphor that I’m satisfied with to explain to my Windows and Mac developer friends the way I feel about developing on their platforms. It’s like programming without source control. Developing on Linux and with source control I feel safe - if anything I do has unintended (or worse, unnoticed) side-effects I know that I can get things back to where they were before, or at least work out what happened. On Mac and Windows I’m back to when I was writing Pascal programs in DOS where I’d type a few lines, save and never be able to make my program work again.
Aside 1: At least with Windows I can do everything in VMWare which gives me snapshots and roll-back, Apple’s DRM prevents me doing the same for MacOS. Fail.
Aside 2: I feel almost the same about Ruby gems. It’s a package system but a terrible one. It’s like being forced to use RCS when I’ve got git sitting right here. I do understand why Mac Ruby developers seem to think it’s the best thing since sliced bread - I remember in 1995 when I was first introduced to RCS.