In the past couple days, there’s been a bit of a dust-up about some changes coming to WordPress in 2.6 — namely disabling ATOM and XML-RPC APIs by default.

The argument is that this will make WordPress more secure out of the box — but the question is at what cost? And, is there a better solution to this problem rather than disabling features and functionality (even if only a small subset of users currently make use of these APIs) if the changes end up being short-sighted?

This topic hit the wp-xmlrpc mailing list where the conversation quickly devolved into spattering about SSL and other security related topics.

Allan Odgaard (creator TextMate, as far as I can tell!) even proposed inventing another authorization protocol.

Sigh.

There are a number of reasons why WordPress should adopt OAuth — and not just because we’re going to require it for DiSo.

Heck, Stephen Paul Weber already got OAuth + AtomPub working for WordPress, and has completed a basic OAuth plugin for WordPress. The pieces are nearly in place, not to mention the fact that OAuth will pretty much be essential if WordPress is going to adopt OpenID at some point down the road. It’s also going to be quite useful if folks want to post from, say, a Google Gadget or OpenSocial application (or similar) to a WordPress blog if the XML-RPC APIs are going to be off by default (given Google’s wholesale embrace of OAuth).

Now, fortunately, folks within Automattic are supportive of OAuth, including Matt and Lloyd.

There are plenty of benefits to going down this path, not to mention the ability to scope third party applications to certain permissions — like letting Facebook see your private posts but not edit or create new ones — or authorizing desktop applications to post new entries or upload photos or videos without having to remember your username and password (instead you’d type in your blog address — and it would discover the authorization endpoints using XRDS-Simple — Eran has more on discovery: Magic, People vs. Machines).

Anyway, WordPress and OAuth are natural complements, and with popular support and momentum behind the protocol, it’s tragic to see needless reinvention when so many modern applications have the same problem of delegated authorization.

I see this is a tremendous opportunity for both WordPress and OAuth and am looking forward to discussing this opportunity — at least consideration for WordPress 2.7 — and tonight’s meetup — for which I’m now late! Doh!

Here’s what I asked myself:

how are you?

we’re going to talk about diso today? is that right?

what is diso?

you say it’s a social network, so how would it work with wordpress?

how is this different from myspace or facebook?

so who’s involved in this project?

so what comes next?

how is this different than opensocial?

what’s going to be the big win for diso?

so do you see this model applying in any other domain on the web?

what kind of support do you need?

are you talking to any of the bigger social networks? like facebook or myspace?

so who cares?

how will you draw customers away from myspace or facebook?

any last thoughts?

Indeed, I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.

Call me elitist in this one aspect, but with all due respect to code artistes, it’s quite clear whether a function computes or not; the same quantifiable measures simply do not exist for design and that critical lack of objective review means that design is a form of Art, and its execution should be treated as such.

What’s got my panties in a bunch? Well, this screenshot depicts the new WordPress Admin Dashboard coming in the forthcoming release, version 2.4, which you can check out from the WordPress SVN repository. From Mr Mullenweg’s own admission, it’s only about 10-20% complete, but you wouldn’t know that from the feedback this work-in-progress is already generating.

Coming from CivicSpace, where we had a beautiful website before we had working code, to working on Flock, where the mockups never quite matched the software that was released, I feel like I’ve seen enough of these fruitless cycles to take for granted that design and open source development are simply incompatible, or, to be clear: the expectations that one has with open source software development cannot be the same expectations that one has for open source interface/interaction design.

From my experience, what can I say about constructive open source UI/UX design?

1. Set expectations. As a designer, I’m trained to take feedback and to accept as given that people will shred my work in the interest of improving it. But I also know that there are plenty of folks who do care but simply don’t know how to provide useful feedback. It’s my job to make it clear what kind of feedback I’m looking for and what feedback I don’t need. It’s also up to me to communicate that I reserve the right to reject any feedback given. It’s up to the feedback-giver to not take it personally.
2. Set deadlines. This one follows the previous point, but if you’re doing any kind of design review, it’s pretty important to put some temporal boundaries on how long the window is open to be given feedback and how long it will likely take to implement it. Nothing’s worse than unrequited design feedback, even if it’s feedback that isn’t useful.
3. Know where you’re at. My more naive self would rebel against what I’m about to propose, but there’s no way around it. If you’re acting as a designer, it’s up to you to “own” the design process and to only ask for feedback when you’re clear on the kind of feedback you’re looking for. Open source shouldn’t be about ultimate compromise or mamby-pamby democratic ideals where everyone has a say. Curiosity kills plenty of cats, but consensus is goddamn plague on most projects so get it in your head that open source is about public demonstrations of repeated meritocratic value creation and not about listening to every Tom, Dick and Harry that has something to spew. And anyone who hasn’t proven themselves by previously being raked over the coals of public criticism and critique should be treated accordingly. Remember, opinions are like assholes and vegetarians are still in the minority.
4. Use productive and appropriate tools. The most aggravating aspect of participating in the Mozilla community has been their reliance on Bugzilla, one of the worst possible tools for design review and discussion. Can you believe that they still do design in ASCII art? Me neither. Look, when you’re doing interactive design, you should try to get as close as possible to the target environment as possible when working and designing. Can you remember the last time you used an application whose interface was made of pipes, ellipses and clever uses of brackets? Neither can I. Therefore interfaces should be presented using tools that support constructive dialogue and feedback. Flickr is actually a great tool for this purpose, with its Notes feature. ConceptShare is another one, developed specifically with this use case in mind. More and more Skitch and Jing are other tools that serve this purpose, as are screen capture applications like iShowU and even Leopard’s built-in Screen Sharing application.
5. Be clear about the problem you’re solving. Nothing spells disaster for a design process more than fishtailing. If you don’t know what problems you’re trying to solve and you don’t have razor-sharp focus on it, chances are you’ll be open to whatever feedback you can get your hands on, grasping for some notion of what the hell you should be working on. This is not design, this is horseshoes and hand grenades.

   Look, it’s okay to not have everything figured out when you embark on a project, and it’s even okay to admit that and to embrace it. It’s wholly another thing to pretend to know what you’re doing and then go about asking for feedback. By its design and nature feedback is intended to raise deltas between the perceived reality and the potential reality. For feedback to be useful and productive, you, as the designer, have to stayed trained on the ultimate endpoint that you’re driving towards and systematically exhaust all possible combinations presented by the feedback that will lead you to non-ideal solutions. This is how you use feedback to whittle away at an opportunity until you finally arrive at a satisfying outcome.

   To put it another way, existential deviation on a theme is certainly okay and to be encouraged; experimentation is where a lot creative ideas will come from. But in the context open source feedback flows, this is absolutely NOT where you want to fluctuate. Trust me, this is where design hijack takes over, and where you’ll lose your control and leverage over the direction of a project. If you hold the reigns tight, an open feedback process can be extremely rewarding; let slip and you’re likely to be overwhelmed in a sea of confusing and confounding false opportunities.

6. Be focused. This tip is twofold and builds on the last. You should be focused on the feedback you need, and rather than going for blanket advice, narrow in on specific user flows or tasks. On top of that, the less certain you are about the approach you want to take or about the appropriate solution to pursue, the smaller the pool of respondents you should consult should be. This is what I mean by “be focused”: the more uncertainly in the project, the fewer external voices you should consult, especially en masse; the further along in the project you are, and the more certainty you have, the more you can open it up for general feedback. Note too that people will bring their own preferences, assumptions and beliefs with them, so choose your early critics wisely.
7. Care deeply and sacrifice nothing. This one’s probably the hardest of all, and really can only be learned/earned over time. The role of the designer is, against all odds, to synthesize and to make sense of ambiguous circumstances, poor or changing problem descriptions, to weigh the individual needs of project sponsors, of product users, or subjective tastes and of sating the hunger of one’s own ego to produce something better than you thought yourself capable of. And it’s nearly impossible to fake it. But the best approach seems to be to do your homework and care deeply about the work that you’re doing and to identify with the problem that you’re trying to solve. Sacrifice nothing in the way of arriving at a solution that meets your highest personal criteria. It helps when you’re your own worst (best) critic, but it’s all the more essential when you’re putting yourself out there for public scrutiny. If you know that you’re not going to let yourself get away with anything, you should be able to face whatever slings and arrows the outside world will heave your way, all as part of.

And so we return to the case of the WordPress 2.4 Admin Dashboard. It’s unclear who owns this project or the feedback coming in (I don’t remember seeing a public call for comments, so this must just be unsolicited feedback), but I sure as heck hope that whoever it is takes this current round of feedback with less than a grain of salt. As far as I’m concerned (and as much as I’d like to affect the design process myself) WordPress deserves more time to make its case for the new design, and to implement closer to 70-80% of the design before people start pontificating about how things should be different (or remain the same) (not like any such plea will stem the onslaught).

With open source development, the cat is always out of the bag. As such, it keeps you honest and focused on issues that people care about, even if they’re occasionally peripheral to the main issues you set out to solve.

So the problem with open source design is not the feedback (designers et al should be grateful when it comes) but with the ego issues that are wrapped up in how feedback is delivered and how it’s received. And these are ultimately social issues. The points I outlined above have as much to do with clear communication, acknowledgement and a Buddhist-esque equanimity as with any kind of formal design training. If open source design is to advance, and to become a dominant force in the creation of exquisite software experiences and interfaces, I say we start here.

WP-Imagefit is extremely simple and serves one purpose: to get images in blog posts to fit inside the columns that contain them. In fact, this plugin is used on this blog, so if you see ever images load wider than the column and then quickly snap to fit the container’s width, it’s this plugin that’s doing that.

I originally discovered this trick thanks to Oliver Boermans‘ NetNewsWire Ollicle Reflex style. Working together, he extracted the resizing code into a jQuery plugin called jquery.imagefit.js and made it available to me for use in my EasyReader NetNewsWire theme.

I had hacked it to work for my blog theme but decided that I should turn it into a WordPress plugin so I could use it elsewhere (and given that CSS’s max-width attribute not only wasn’t cross-browser, but also shrunk images horizontally, I needed a better solution). So, there you have it.

Go ahead and download it. Installation and setup is standard as long as you have an hAtom-compliant theme like K2 or Sandbox.

I have a WordPress.org project page setup, the source is available (released under GPL), and if you want something to look at it, here’s the official homepage.

Feedback/feature requests/patches certainly appreciated and encouraged!

I’ve been involved for many months in the MarsEdit beta list, even before Ranchero (Brent Simmons) sold it to Red Sweater Software (Daniel Jalkut). Today, after months of long work, Daniel has finally released MarsEdit 2.0.

Besides an exhaustive UI overhaul, MarsEdit now supports Flickr account access through its new Media Manager, support for the WordPress ATOM XML-RPC protocol for adding categories and custom code macros among other things.

Brent’s written up the release, as well as TUAW. For $30, it’s a pretty solid deal for a great piece of software.

I decided I’d write up my arguments for switching platforms in the hopes that I might test my thinking and in the process persuade our client to move to a more community-forward platform.

The conversation sprang from a discussion about building out a participatory community architecture… y’know, the standard stuff: regular posts, profile pages, friending, syndicating content, forums and a functional API. They’d been public a couple months, having spent most of their time on their content-creation tool and were finally ready to start investing in social features to encourage folks to share more content and engage with one another in the context of a nascent community.

As such, the first question I asked the client was “Why .NET?”

Now, I’m not a .NET hater or anything — in fact I’m quite ignorant of it save the brief stint of ASP programming I did a looong time ago (which probably no longer applies). But at the same time, from what I’ve seen and heard, .NET is simply not a web-friendly (read: standards based) platform for building a people-powered Web 2.0 community on. Instead, you need something agile and lightweight, something widely deployed, open source and for which there is a great deal of available talent who “get” the web, love the web and can role up their sleeves under tight deadlines and morphing design objectives and execute.

In my limited purview, that is not my impression of .NET.

So, the options that I suggested in place of .NET were Ruby on Rails, Django and PHP (mostly relying on WordPress MU). Let me explain how I evaluated and then dismissed all but the last option.

Ruby on Rails is hot for a reason. It’s an elegant language that’s actually fun to program in. And it does a lot of the heavy lifting for you, leaving developer-designer hybrids to focus on meatier issues like feature development, user flows and the overall experience of an app. But it’s also limited in its server-side deployments, fairly heavy in its server-side requirements and while there’s a passionate community behind this platform, its denizens are pricey and few and far between. As well, due to its facility, many new developers claim to be Rails developers when in reality they’re not seasoned with the realities and limitations of working in constrained or managed environments. This is a risk that can prove very costly unless you’re working with experienced and dedicated developers.

Given that the client is located in Miami where Rails talent is scarce, I felt that, while it’d be a great choice for a small technology-forward team who can afford to stay small and on the bleeding edge, the team needed something with a longer history, that’s more widely deployed in typical hosting environments and for which there is ample available talent.

Django is an interesting and exciting Python-based framework that’s very well architected and very fast. I heard that Rails-creator DHH wouldn’t have developed Rails had Django existed a couple years back. In any case, Django, like Rails, takes a lot of the complexity out of development. But again, it’s a situation where, soup-to-nuts, the fit might not be quite right given longer term considerations that don’t always exist in independent web development shops — and given the same concerns that I expressed above about Rails.

Both are excellent frameworks and you could correctly argue that both of these frameworks require fewer developers, and shouldn’t be evaluated from their respective community-sizes. But you’d still be tasked with finding sufficient and dedicated talent to support your choice on the server side and when that’s not your core business offering, it’s something of a distraction to struggle with hosting demands when you really should be building your product. When you’re 37Signals you’re naturally going to attract (and retain) top talent; when you’re a new startup things aren’t so certain, regardless of how excellent your software, vision or team are, and bringing in the right people is the hardest part of growing your enterprise.

While I’d love to make a recommendation for one of these sexier frameworks, ultimately I’m going to recommend PHP and WordPressMU in this particular case. I’ve talked about some of the strengths of Rails and Django and for somewhat peripheral issues I’ve discounted both (not to mention completely dismissed .NET for similar and worse issues). I’d like to talk about why I think building a social network application in WordPressMU and PHP makes sense and how I came to this conclusion, keeping in mind that you should be comparing this list primary against .NET’s offerings rather than the other two frameworks.

• Employment. First and foremost is the issue of attracting experienced talent that also gets and respects the web. In Miami, you’re going to be hard pressed to find .NET developers who don’t have an enterprise background let alone talented Rails or Python developers. In contrast however, I think you’ll find a lot of PHP and WordPress developers who would love to get into building a social network application. Call it a hunch, but I think the PHP folks will be more savvy to the issues present in building web apps than the local .NET types.
• Open source. Part of the employment problem lies in the awareness and visibility of .NET developers. Since most have an enterprise background, little of their code is available to be downloaded, played with or reviewed. Furthermore, it’s extremely difficult to gauge their strength with online communities or how they are to work with or how comfortable they are working in the open. Since WordPress and PHP are open source, it’s much easier to get a sense for what someone is capable of simply by looking at the code they’ve produced in WordPress plugins and the like.
• Web standards. From what I’ve seen and heard (take a look at Channel 9 and their table-based layout), .NET doesn’t promote web standards or attract savvy web developers. It attracts programmers who are used to a Microsoft world with Visual Studio and form controls and generated code. If you download the basic Community Server theme and peek inside, you’ll see what I mean. Appreciation for web standards is an ever-more critical attribute of a mindful developer who understands that their work may end up being experienced in environments they’d not tested in. Adherence to web standards and open data formats can help mitigate both the cost and pain of the development of new web-based environments and platforms.
• Community. You should choose a language or framework for the community as much as you do the language itself. While I agree with Jason Fried that developers should choose languages that they like to work in (as designers choose tools they’re comfortable using) but I also think that it’s important to choose technology based on the community support you’re going to get by going in that direction. I have no experience with the .NET community but can say that my firsthand experience with the WordPress community has always been top notch.
• Economics. I mentioned the issue of hosting and I think this is where WordPress really shows its value (at least for the near future). Matt’s made it a point that WordPress is going to continue to be based on PHP 4 until there is a compelling reason to upgrade. Since PHP 4 is completely ubiquitous in both script and hosting support, it’s easier to find hosts and sysadmins that are familiar with scaling and deploying PHP infrastructure. This keeps hosting infrastructure costs down as you can build out through commodity service rather than the more specialized hosting needed for Rails and Django.
• Scalability. This one’s highly contentious but I’m only going to draw the comparison here between scaling with the Microsoft tax and scaling without it. With enough technical know-how and hardware, you can scale most anything. The question comes down to how you want to feel when scaling. Personally, investing in Microsoft hardware freaks me out. I can’t explain it, it’s not rational, but it needs to be considered.
• Politics. Let’s face it, your choice of platform should reflect your politics, and I don’t mean Red or Blue. I know that coming out in favor of WordPress is political speak; after all, it’s a matter of opinion and not fact which framework is best. However, I think people familiar with modern web design would agree with me that WordPress/PHP, Django or Rails are all superior choices over .NET when it come to the politics of technology development. In terms of openness, being forward-thinking and in terms of community outlook, any of these choices are going to net you a very different kind of response. Being keen to what each choice says about you is key to making a wise decision.
• Buy out considerations. This isn’t something I usually put much thought into, but given the current environment, I think it’s worth considering. The simple way to think about this is that like attracts like. Yahoo is a PHP shop — and converting from Rails to PHP — as Upcoming did — was probably a bit of a pain. YouTube is Python-based and given that Google is a primarily a Python shop (though they talk in all flavors) that probably played into the attractiveness of their technology. Now, I won’t say that your choice of platform will ever make or break a deal, but I’ve just not seen a successful .NET buy out by the open source friendly incumbents. Unless you consider Microsoft buyouts.
• Functionality for free. One of the great aspects of working in open source, of course, is the ability to reuse the work of others. In the case of WordPress, there are literally thousands of themes and plugins that you can use or learn from when building out your blog or site. Given that so many basic problems have been solved, it only makes sense to go with a proven platform known for its usability and ease of extensibility.
• An overall strategy. I’m still a huge fan of Django and Rails — in fact most of the other projects that I work on start out in one of these frameworks. But when it comes to building a social network with periodic posts being published in a blog-like fashion, it only makes sense to go with WordPressMU. I think this is a solid, lower cost way to move forward, with a higher likelihood of higher local talent and keeping up with the latest trends at the same time. Now that BBPress, WordPress’ forum system, can be easily integrated into WordPress, there’s yet another reason to choose WordPress.

Lastly, I want to make a special mention of ChickSpeak, probably one of the first independent social networks driven wholly by WordPressMU and BBPress and a great example of what a WordPress-based social network might look like. I think there are a ton of lessons to be taken from this site, and I hope a great number of plugins that can be extracted.

I’m eager to hear people’s thoughts on this, though I won’t be able to respond for at least three weeks as I’m literally headed out the door to Hawaii for like, my first evar vacation. Hopefully you’ll keep things civil while I’m gone. Apologies in advance for any rambling or unclear language.

And I should note that Drupal could also be considered for this purpose, but that it’s lack of narrowly-defined features and interface makes it too much of a beast to coral into a finely-tuned and disciplined bloglike site.

Recently I took a look at the numerous WordPress blogs I maintain and decided to extract some of the best plugins I use across them. They range from spam management to reporting and stats to authentication and better overall functionality. Here we go:

• Akismet: the best comment spam protection this side of dodge. It fortunately comes pre-installed, though you’ll still need an API key from WordPress.com.
• Clutter-Free: a simple plugin for customizing the WordPress composing interface. If you never turn off comments or worry about editing the slug, this is a handy plugin to keep things nice and tidy.
• Comment Timeout: I just started using this one recently when it turned out that 90% of my comment spam was showing up on older posts. This one’s a life saver.
• Diagnosis: this is a really useful plugin for finding out information about the server that you’re hosted on. Essential for debugging compatibility problems (like which version of PHP you’re on).
• FeedBurner FeedSmith: Steve Smith originally wrote this plugin to make it easy to use FeedBurner for syndicating your blog and now FeedBurner has taken over its maintenance. Super easy to use and super useful.
• Maintenance Mode: whenever I need to upgrade WordPress, I always flip the switch on this plugin giving my visitors a pleasant down-time message. It doesn’t come with LOLCats out of the box, but you can customize it to be if you’re feeling adventurous.
• Share This: Alex King creates incredibly useful plugins and this is one of them. If you want to make it easy for your visitors to share your posts on bookmarking or social network sites, this is the one plugin you need.
• TanTanNoodles Simple Spam Filter: Matt is skeptical about this plugin, but I find it useful. Essentially you can blacklist certain words and this plugin will delete any comments found to contain those words, as well as pre-filter comments as they’re being submitted. Whether it’s redundant to Akismet or not isn’t important to me — I need all the anti-spam kung fu I can get!
• Trackback Validator: this plugin is part of a research program out of Rice University. I don’t know how well it works, but I certainly have very little trackback spam since installing it!
• Subscribe To Comments: unless you’re a co.mments or coComment user, it’s often a pain to stay on top of comments you’ve left on other blogs. Subscribe To Comments adds a checkbox below your comment box to allow your readers to subscribe to comment followups via email.
• WordPress.com Stats: like Akismet, this is another Automattic product. If you have a WordPress.com account, this plugin will gather visitor stats on your blog and integrate them with your WordPress.com dashboard.
• WordPress Database Backup: this one is also pre-installed by default and is recommended as part of the routine for upgrading WordPress. Every time you increment your install, you should do a backup with this plugin.
• WordPress Mobile Edition: Alex comes through with another hugely useful plugin for converting your site to be mobile-phone friendly. I’m currently working on a skin for the iPhone, but for everything else, this one works wonders. Highly recommended.
• WordPress Reports: If the WordPress.com stats aren’t enough for you, Joe Tan has written an awesome plugin that merges your FeedBurner and Google Analytics stats into a very readable page of infographics.
• WordPress OpenID (+): of course if I’m going to be running multiple WordPress blogs, I’m not going to want to remember multiple usernames and passwords across them. Instead, I use OpenID. Will Norris‘ work on Alan Castonguay original plugin fixes some bugs and update the JanRain library to avoid a number of compatibility errors.
• WP-Cache: if you get any kind of traffic whatsoever, this plugin is a lifesaver, especially in spikes from Digg and elsewhere. Turn it off while testing but otherwise, leave it running.
• WP-ContactForm: Akismet Edition: I used Chip Cuccio‘s WP-ContactForm for some time but found that it was a bit too restrictive with its spam fighting tactics. I switched to this version, which uses Akismet rather than regex rules and have found that it’s a better balance for me.

So there you go. That’s the list that I use for every WordPress blog that I start. I should ask: how many of these do you use? What’s your favorite list of WordPress must-adds?

Oh, and bonus! I start every theme I work on with Sandbox. It’s extremely flexible, fully classed (including native support for microformats) and now there’s a contest for best skins on until the end of the summer. Definitely a must-have for any new blog I work on.

read more | digg story

Two more announcements for OpenID adoption — but this time on the consuming side (as opposed to my originally incorrect report about WordPress.com — for now, they’re only serving as an identity provider).

The first is Shopify, a great Rails-based custom store application. As Alex points out, these guys really get it right — and make it super easy to create compelling marketplaces. And now, it’s super easy to log in with OpenID.

Meanwhile, IconBuffet has gone through a major overhaul, becoming something of a social network for … icon enthusiasts! (Sweet!) One of the more existing aspects of the relaunch (at least for me) is their use of OpenID: you can either create a new account with an existing OpenID (say, your WordPress.com blog URL) or you associate your existing account with an OpenID. Either way, they too’ve made it really easy to get going with OpenID.

I imagine that these won’t be the last of the increasing deployments of OpenID in the medium- to long-tail (read: not Google or IBM, but small business community). What’s so existing about these recent additions is their proximity to commerce — and how folks like Shopify could eventually weave a web service that allows you to check out — entirely by way of logging in to your OpenID provider. If you choose a good OpenID provider, you can start to see how the CardSpace metaphor makes sense — just like when you go out to eat and depending on whether it’s a business meal or a personal expense, you’ll use a different credit card to pay.

The same thing is true for OpenID — where you can have as many OpenIDs as you like and you can pick among them for different uses or purposes. It’s only a matter of time before I go to check out at IconBuffet, I login with my WordPress.com OpenID and I’m able to use credits that I’ve purchased on WordPress.com to pay for my icons — with no need to reach for the credit card, to fill in my address info or any of that ever again!

Now, if that doesn’t sound exciting, you might want to check your pulse.

In talking to Matt last Friday at the Adaptive Path party, I asked him when OpenID was coming to WordPress.com — the hosted blogging service — and he replied “Monday”.

Well, a day late but hardly a dollar short, WordPress.com has added bi-directional support for OpenID.

What this means is that you can both sign in to WordPress.com using your existing OpenIDs (making WordPress.com a “consumer”) as well as use your WordPress.com URL (for example, http://factoryjoe.wordpress.com) as an OpenID elsewhere, making WordPress.com an iDP or “identity provider”.

The FAQ entry is pretty descriptive and I’d recommend you take a look at it. WordPress.com now joins a growing array of service providers offering support for this grassroots-driven authentication protocol.

No word on when OpenID will hit core of the WordPress project, but there are already two great efforts driven first by Alan Castonguay and more recently Will Norris — which point to a positive future between the two open source initiatives.