One thing that bothered me was that the little-updated Beta Technologies pages were hard to navigate and had a different theme from the blogs which really put a cramp on my marketing (where I managed to be a little more creative…). There was good reason to do some minor tweaks and unify the themes…

Last week I got an email from WordPress.org to say that 3.0 was now on its second Beta. Well, I usually don’t try the betas out — Automattic, the company behind WordPress, tends to innovate little, making sure that as most backwards compatibility is preserved — and just do a “blind update”, crossing my fingers, when the new version comes out.

This time, however, I was a bit bolder. I’ve been frustrated like crazy with WordPress’ lack of proper menu navigation. While I consider myself a fangirl of WP (like I am of Second Life®!), I’m also the first to know its limitations. Menu navigation was at the top of my worries. Oh, yes, the lack of that is so serious that some companies sell plugins to deal with menus — because the free ones, frankly, are pretty much a waste of time. There are a lot of other things that frustrate me, like the lack of areas for “registered users” — you can password-protect articles (I keep forgetting how) and some plugins allow you to force users to log in first to be able to see some areas, but that’s really not the best way. CMS like Joomla deal with that easily and without much configuration: just click on a checkbox.

I’ve also been encouraged to move over to Drupal, which is getting better and better in its complexity. It’s a “serious” CMS for professional programmers, allowing one to create pretty much any kind of website (or portal, or set of websites with the same backend) you want. There are no limitations whatsoever, except your ability to install the appropriate plugins and extensions and programme in it whatever you need.

But I’m lazy. I like WordPress. It does 90% of what a so-called “serious” CMS is supposed to do, but it’s way easier to install, configure, and, more importantly, to get users instantly working with it without having to learn a complex backoffice. The simplicity of blogging is implied in WordPress’ interface — hiding the true power beneath its fully-configurable engine.

So, well, I got to read the two new major features for WP 3.0: menus and integration with WP MU. WP MU, for the ones that are unaware of WP’s “world”, is a WP branch that allows multiple sites to be managed from the same installation and the same database, but each gets their own “admin” user with full access to it… or almost. You can still define what themes are available overall. You can just allow admins a subset of all plugins. And, of course, you can upgrade all sites with a click of a button from the “superadmin” backoffice.

The WP MU team has done a huge effort to keep up with the “normal, single-admin” WP. Still, it was a pain to test new plugins. WP MU, since it has to deal with different configurations per website (imagine a simple plugin for viewing Flickr images: each independent site will have its own configuration), sometimes breaks some outdated plugins, and fixing them is a pain.

On the other hand, BuddyPress, a full social networking solution for WordPress (getting more popular as people start running away from soon-to-become-a-paid-service Ning), as well as some e-commerce solutions, work better under WP MU. This means that it gets hard to keep everything under the same administration backend: you might have a separate install for the main blog or site, several WP MU-created blogs, a BuddyPress install, some e-commerce solutions, and so forth. Wouldn’t it be nice to put them all under the same roof, so to speak?

Well, the good news is that WP 3.0 brings the WP MU branch back into the trunk. Yay! No more fuss with figuring out what plugins will work and what will not! Now it either breaks for 3.0 — and it means the plugin writer will quickly fix it, since there are far more “trunk” installations of WP than of WP MU — or it works flawlessly.

And, of course, we got a menu navigation system. One that works. Really. It’s so good that I can’t believe how I could survive without it before. You have a simple drag-and-drop interface, where indented items show the layout of menus and sub-menus (I don’t know how deep it goes, but it seems unlimited…). You can create menu items for pages or categories… or free-form, e.g. whatever link you wish to place there. Links can point back to your own blog too, of course, giving you the ability of using some nifty tricks. Save the manu, and Bob’s your uncle — hey presto, your blog has a menu!

Of course, it’s not that easy for yours truly, who sadly lacks advanced HTML/CSS skills. By very patiently pushing pixels here and there, I managed to backpatch a clumsy (but effective!) menu on Beta Technologies’ main page. Now finally — finally! — after three years, our clients can see what areas are available on our page, and hopefully find, with a mouseclick, where our contacts are 🙂

Thanks to Automattic for doing such a stable Beta. I’m certainly enjoying it very much 🙂 In two weeks, I hope to tackle my much-tweaked, infinitely-patched personal blog as well…

And it was when I (automatically) downloaded the latest nightly build that a thought occured to me. WordPress is what I call company-directed free and open-source software. What that means is that it isn’t some kind of software where a handful of eager anonymous programmers — here today, gone tomorrow — set a code repository up and start attracting friends to write code for free. No, Automattic runs a business (even though their haiku page seems to indicate otherwise!). And of course they keep strict control over “their” code.

Obviously anyone can download WP, tweak it, and release a “new” WP (as a matter of fact, that’s how WP MU and BuddyPress started). However, that doesn’t happen so often. What most programmers do is contribute code back to the main, or trunk, WordPress — thus benefiting all users, not just the ones that particularly like them 🙂 This is, in fact, how almost all company-directed FOSS projects work: the company’s role in the project is, beside adding code and fixing bugs, providing direction, establishing deadlines for releases, and doing quality control. Independent programmers can, of course, do that on your own, on their own repositories — but they know that the millions who test and evaluate WP’s code will not look at their code, they will just use the one being under watchful control of Automattic.

I said “almost all”. The biggest exception I’m aware of is… Linden Lab’s Second Life. When the viewer became open source, I was expecting that the same model would be implemented: programmers would contribute code back to LL, LL would check and validate it, and release a new viewer. But this didn’t happen: instead, groups of programmers download the code, set up their own repositories, try to attract a few friends, and release a different viewer. Now this seems to be a waste of time for everybody involved — and it also means that no viewer incorporates all tweaks and bug fixes developed by all programmers.

Why did this happen? The major two reasons are: an insanely slow quality control process (except for emergency security patches, LL usually takes 6-18 months to implement a single-line patch, since their code auditing procedures take insanely long) and a relatively limited margin for adding patches that might be marginally unaligned with LL’s vision. Thus, since LL doesn’t want that users do their own backups, they frown upon any implementation of a backup system. Collecting viewer data and showing it to other users (like Emerald, and more recently Imprudence) are doing might also be something LL doesn’t want on their “main” viewer (or even Snowglobe). “Restrained Life”, a powerful API that allows the viewer to send commands to in-world items (mostly HUDs), providing functionality not possible in plain LSL, is also something which LL prefers to avoid (for security reasons; they’re developing a plugin system for the viewer which should render Restrained Life obsolete — but we don’t know when that will be ready). Other things, however, always baffled me. Why don’t we get a better radar system? Or a fantastic way to search for lost items, like Emerald does? Surely these are relatively peaceful changes that should have been incorporated on the LL viewer eons ago…

Until LL changes their policies on those two issues — faster QA to approve code within days (not months or years!) of its submission, and a clear policy on what kind of features are “peaceful” — it’s hardly likely that programmers will be willing to work for free for LL to submit code to the main viewer. And while this goes on, it means that residents will continue to switch back and forth between different viewers, as they look for the features they need to enjoy their experience in SL. We’ll never have the equivalent of WordPress for SL: a single source, with hundreds of contributing developers, benefiting millions of users.