I’ll be at Techdirt’s Greenhouse event in Sunnyvale tomorrow, although probably just through the morning.
One of the biggest PITA aspects of the web is registration screens, usernames, and passwords. Nothing new here, it’s been a hassle for years and the only advances till now have been remembering passwords and automatic form filler widgets… more like the crawling of technology instead of the drumbeat march we are accustomed to telling ourselves.
There are applications that require granular security systems keyed of user identities and their roles, but for the most part these are the minority while most of the consumer web services track user registrations more for valuation reasons than actual security.
MyOpenID is a standards based identity service. It’s so simple it’s almost easy to discount it, you create a profile on myopenid.com that is mapped to a URL, for example the profile firstlastname would become http://firstlastname.myopenid.com. Each profile has basic user information attached to it, really not much more than name and a password (e-mail address is optional). OpenID enabled sites will accept the url when requesting registration, and you then have the option of allowing forever authentication, one time, or always ask. One thing I like about the authentication protocol is that in one place I can see what sites I am registered for, and the ability to deny requests from any site you don’t wish to access. Nice.
Of course to use all this goodness sites have to subscribe to the OpenID protocol, which would scare off a lot of developers were it not for the fact that they may already be using the code for their native authentication, which is an open source library. Having said that, the directory of sites that are OpenID enabled is pretty thin, even though it does include a biggy in Movable Type and LiveJournal (although I don’t recall seeing this in my own MT implementation).
Before launching MyOpenID we developed a free and open-source OpenID software library. The original Python OpenID library quickly became well respected, and we followed the Python library with ports for Ruby, PHP, Perl, Java and C#. We are committed to open source development, and will continue to develop high-quality products for the open source identity community.
Ross announced today that Socialtext and Dan Bricklin have joined forces in the market by bringing together Socialtext’s wiki solution with Dan’s WikiCalc spreadsheet.
The immediate reaction to this is no doubt that a spreadsheet in a multiuser edit mode is certainly a good thing, indeed it’s been my view that even if all Socialtext gets out of this is a better table editor (think about how many spreadsheets are used a databases) then Socialtext will have a winning hand. The ability to deploy this in a intranet environment and on mobile devices are also compelling competitive differentiators.
The idea of multi-user editing in spreadsheets is something quite hot right now but I don’t think most people appreciate how hard it is to build this kind of application. Consider for a moment the complexity of doing cell locking and journaling/rollback of changes when cells may be dependent on other cells. As you would expect from Dan Bricklin, WikiCalc is a serious engineering work that solves some very complex problems.
Socialtext also announced today that they will have an open source version of their core wiki product available in a month, and will re-release the already open source WikiCalc at the same time under a more commercially friendly open source license.
PS- In the interests of disclosure I should also point out that SAP is an investor in Socialtext and I have a role on their Board of Directors.