Seventy-Five to Go

Asides

People are abuzz because it looks like the W3Techs survey of the web now has WordPress at 25% market share.

Screen Shot

Sometimes it goes up and down through the course of a month, but it’s still a pretty fun milestone that we can now say about one in four websites are now powered by the scrappy open source underdog with its roots stretching all the way back to a single person in Corsica, France. We should be comfortably past 25% by the end of the year.

The big opportunity is still the 57% of websites that don’t use any identifiable CMS yet, and that’s where I think there is still a ton of growth for us (and I’m also rooting for all the other open source CMSes).

If you want to celebrate with us come to the first-ever WordCamp US event next month in Philadelphia (tickets still available) — it’s shaping up to be an amazing event. We just published the schedule and there are some amazing speakers and sessions.

Christmas Site Updates

Asides

First off, Merry Christmas everybody! I’ve been doing some tweaking here around ma.tt. The biggest thing you’ll notice is that I’ve imported about 12,000 photos from my old Gallery-powered gallery, which was broken since I upgraded to PHP5, into core WordPress, and you can see them under this category. I even managed to bring over people tags and comments from the proprietary system I had written. I feel so much safer now that all this data is in WordPress, I know it’ll still work in 10 years. I might have to change how “random” works, though, to exclude the really old photos, because they can be fairly embarrassing. 🙂

Infrastructure as Competitive Advantage

Rant

There’s an interesting post at GigaOM: Web 2.0, Please Meet Your Host, the Internet. It’s a good read, though could be shorter, but a few things struck me after reading it. I don’t disagree with him per se, I just think the emphasis is on the wrong thing. (Probably for effect.)

Infrastructure can be a competitive advantage today — the speed and reliability of WordPress.com has certainly put us in a favorable light with users, especially large customers — but that’s going to disappear over time. We’re very much at version 0.1 of things like Amazon’s web services and App Engine, but it’s not hard to read the writing on the wall and understand that level of abstraction is going to be the future foundation of web applications. I’m not counting on infrastructure to be a long-term competitive advantage for Automattic.

If you have a few minutes it’s worth reading On Grids, the Ambitions of Amazon and Joyent which has the real definition of a grid and Sunshine, which is worth it for the extended analogies to Greek mythology. (Both end in ads for Joyent.) Also check out Early notes on GoogleApps, Dave Winer groks where this has to go.

Second, Allan describes a case of a DDOS attack hurting a friend’s startup who had very little information about how to stop it:

Unfortunately, the poor site performance was not missed by the blogosphere. The application has suffered from a stream of bad publicity; it’s also missed a major window of opportunity for user adoption, which has sloped significantly downward since the DDOS attack and shows no sign of recovering.

We can all name startups or sites that aren’t particularly known for their performance, but that flourished in spite of it. Twitter and MySpace comes to mind. If we dug a little deeper we could also find thousands of startups who were prepared for the world to show up to their door, and it never did. Building something people want is much harder than scaling it. (In most cases.) If you solve the what-people-want problem, they’ll use you no matter how bad your interface is, how slow your site is, just give them somewhere worth waiting for. I would suspect the friend here isn’t seeing their usage decline because on their Techcrunch day the site wasn’t responsive, it’s that they’re probably still in the before market fit stage.

Third, I am a huge believer in the importance of performance, but most people forget that on the web 80-95% of performance is on the front end not the page generation time. (I realize I’m saying this on a site with a 140kb header graphic. :)) Yahoo has fantastic resources on this. When a website “pops” it probably has very little to do with their underlying server infrastructure and a lot to do with the perceived performance largely driven by how it’s coded at the HTML, CSS, and Javascript level. This, incidentally, is one of the reasons Google Gears is going to change the web as we know it today – LocalServer will obsolete CDNs as we know them. (Look for this in WordPress soonish.)

Finally, for the next few years before we have true utility computing, there are some great “hardware as a service” providers like Layered Tech and Server Beach that essentially handle everything from the power to the network to hardware, and let you take over from the operating system up. This is what we use for WordPress.com, Akismet, WordPress.org, and it’s great. It’s allowed us to focus on what matters — our software and service. You still need a pro like Allan describes to handle things at the OS level (most performance problems I see are badly configured servers, not hardware limitations) but leave networking and hardware to people with economies of scale. This comment nails it.

Update: I’m in a video Rod Boothby did asking What is Cloud Computing, good timing.

Jawbone UP vs Basis

Review

Jawbone UP I’ve always been into personal analytics. From Wakemate to the Nike Fuelband I’ve tried pretty much every device that’s come on the market to help you become more self-aware of your activities, and hopefully improve them as well.

Lately I’ve settled on two that I think are really high quality: the Jawbone UP and the Basis watch. I would recommend either above the Nike Fuelband or Fitbit, but let me share some brief thoughts about my experiences with each:

The UP is beautiful — it’s easy to wear with pretty much any outfit, even with formal wear I find I can move it up my arm a little bit inside my sleeve above my shirt cuff thanks to the flexible nature of the band. The social app they have for it is cool, though it can be a little weird to see your teammate’s minute-by-minute sleeping habits (“Hey! I noticed you were up between 3:32 and 3:50 AM last night. How ’bout them Giants?”).

I'm very proud of my sleep.
I’m very proud of my sleep.

The battery life is over a week so you never have to think about it, but you do have to carry around a proprietary connector for it which I keep losing leaving me (like right now) with an uncharged and useless device. To sync you plug the band into your phone’s headphone port and the sync takes a few seconds, it’s a fun process I do usually first thing in the morning to see how I slept the night before and it’s also fun to demo to friends. The first one I had was in their “mint green” color and I ended up wearing it out — it started to look dirty and I broke it where the headphone jack comes out making it difficult to charge and sync. That said, I was pretty rough on it. My new one is blue and I like it much better. My only big complaint about how the whole thing works is it doesn’t detect when you go to sleep, you have to press and hold the button on the end to put it from wake to sleep mode, which I would frequently forget to do. I really like the idea of the smart alarm and power nap features even though I never used them.

Basis B1 BandThe Basis is a bit clunky and retro looking, but functionality-wise it provides some really cool data: it tracks your heart rate, skin temperature, perspiration level, steps, and sleep. It detects automatically when you’re asleep, no buttons to push. The data is presented in a really cool web app that lets you compare some of the data points and that I learned cool things from, like my heart rate jumps about 20 beats per minute when I wake up, and I’m most warm about two thirds into my sleep cycle. There don’t appear any social features that I’ve seen in the software, though its habit formation tracking seems pretty slick. The way the “buttons” work on the device is pretty cool, the silver dots in the corners are touch-sensitive. There’s a button on the side that I haven’t figured out what it does yet. Syncing and charging is much worse than the UP — it’s got an even clunkier proprietary USB thing that both syncs to your computer and charges, but because the display can show you how you’re doing as you go throughout the day I don’t feel the need to synchronize it as often. The heart rate tracking is by far my favorite feature. It’s comfortable to wear, but doesn’t disappear like the UP. Finally, as an added bonus, it tells the time. (Surprising useful.) If it somehow merged with the Pebble I’d be in geek heaven.

If I had to pick between the two I’d just use the Basis. The awkwardness of the device is outweighed by the richness of the data it provides. For right now I’m not choosing: I wear one on each wrist and compare the data. (It’s always within a few % of each other for things they both do.) If I were hiking in the woods for a week I’d probably just take the UP as its battery would last the entire time. It’s really illustrated for me what a silo each of these systems are, they don’t talk to each other at all and it appears unlikely they ever will.

Long-term I think we really need an open source package you can run on your own servers that can ingest the data from all of these services, say from back when I used to use a Wakemate sleep tracking to today’s Fitbit Aria scale, the meals I track in the UP app with my Basis heart rate data and Runkeeper and Hundred Pushup logs, and provide you with a single data store for all the personal analytics you generate across various services. I think there’s going to be a lot of competition in this space in the next few years.

Mac Woes

Apple, Asides,

After a security update my 12″ Powerbook asked me to reboot, after which it decided that it will only boot to a command line. I have no idea how to even start to fix this, I can navigate around it like it’s Linux but there is no indication of what went wrong or how to fix it. I’m going to take it to the Genius bar in hopes they can do something, but all-in-all this is pretty disappointing.

In Greece

Asides

The past few days I’ve been in Athens and now I’m on Ios island for the Greek Blogger Camp. Having a conference like this in one of the prettiest places in the world is a great idea (go Stefanos) and there is a lot of energy in the Greek blogosphere. Things are very early here, I’ve heard estimates that there are fewer than ten thousand Greek blogs, but it’s obvious that there is a lot of growth coming, they have all the right ingredients.

Yahoo on WordPress

Asides, WordPress, Yahoo

Stephen Steele (is that a real name?) just wrote in that the new Yahoo Mail updates blog is on WordPress. As far as I know this is the first official Yahoo blog on WP I’ve seen. What makes it really interesting is it’s the first time I’ve seen third-party software (like WordPress) on the yahoo.com domain. You’ll notice every time they’ve done blogs before it’s been on a different domain like yahoo.net or ysearchblog.com, I imagine because of the incredibly strict security requirements anything with access to Yahoo.com cookies must meet. This is very exciting news. 🙂

Should We Have Hidden Options?

WordPress, ,

Alex King has recently suggested that we have an about:config for WordPress. When I first thought this I thought “great!” because we’ve had this for several versions now: if you browse to options.php directly you can edit any option in the database, even those that have no UI because they’re from plugins or just something we don’t expose.

However after several comments pointed this out Alex began clarifying his request, some of it isn’t entirely clear to me (I would never want to go back to storing configuration in files, that was a nightmare we eliminated in 1.0), but the main gist is not merely exposing an interface to the options we have, but rather adding many more options to the code to allow for more than one way for some core parts of WordPress to work.

With that clarification, I think it’s pretty safe to say that something like that will probably never be incorporated.
Options have several costs, which is why we avoid them fairly religiously in WordPress. The most obvious cost is UI clutter — everyone wants their 15 pixels of fame and configuration screens quickly devolve into pages of utterly confusing junk no one understands or cares about.

A very closely related problem is user frustration. With WordPress we’re trying to make publishing to the web as effortless as humanly possible, and one part of this is taking care of a thousand little details that really shouldn’t ever cross your mind — if we’re doing our job right. One common reason for the proliferation of options in open source software is that (news flash) people often disagree about how things should be done, often violently and vocally in threads that can drag on for weeks on development mailing lists. (It is frustrating for many people that these option flame wars draw more discussion than useful topics or questions.) Few like fighting about things, and project leaders pull the proverbial car to the side of the road and declare “Screw it! We’ll do both!” To satisfy a handful of developers a burden is put on countless users.

I try to build everything imagining I have a million users. (Someday!) Small things add up — if there is an option in the interface that people have to think about for only 2 seconds (which is probably low) across a million users that’s 23 days (555 hours) of time lost to the world! (Call centers track efficiency per second because of similar constraints. Small things add up.)

Alex’s hidden options don’t trigger either of these by definition. However there is a third hidden cost: as the number of options increases it becomes difficult (or even impossible) to test for all possible combinations of how the options may interact in different enviroments. This also makes support a real bear. Costs go up, bugs increase.

This is why we say no by default to pretty much every suggested option, and we do our best to remove the ones that have built up over the years. (I just axed a whole panel earlier tonight.)

All that said, hard-core developers often need flexibility in the system to expand WordPress to things we’ve never even imagined, and that’s where our plugin system comes in. While we often say no to new options, we rarely ever shoot down a suggested extension to our plugin API. The beauty of this is it allows for near-infinite flexibility in how you interact with the program (there are some amazing plugins out there) while still keeping the core light, clean, stable, and fast. It also makes support relatively painless: “Does it work when you deactivate the plugin?” When someone says they want to do X and it should be core because it can’t be a plugin, 9 times out of 10 I see that as a plugin API bug, not a core bug.

In summation: Don’t waste your users’ time like I just wasted yours with this essay and be mindful of hidden costs. If I had a few extra hours I would edit and cut most of it out. (Good thing I don’t have a million readers.)