« January 2008 | Main | March 2008 »
Mike Butcher over at TechCrunch UK has just posted about a map of start ups around the world. Nice idea. Who’d have thought that being in York would provide such an advantage - you can see our logos! (At least until Tom gets in with burning a hole).
Rather a long time ago Tristan of BBC Audio R&D announced public last.fm accounts for the 4 main BBC music stations. At the time I thought we should probably set up accounts on Sleevenotez for these stations so that people (us included, to be honest) could track what was being played on the radio. Finally, finally, I've got my finger out and done it:
Enjoy!
There is a risk that this is going to sound like a bitch. It's not, I promise. Getting the release notes right when you are tracking tens or even hundreds of developers is nigh on impossible. That said, I need to get this off my chest...
One of my niggles with Plone over the 2 years that I've been using it has been that upgrades to apparently minor versions have sometimes had major and unexpected effects. Unexpected because the release notes simply haven't made it clear that particular changes have been included. The one that leaps immediately to mind was the change from 2.1.2 to 2.1.3. All sorts of things changed not only under the hood but also in the UI, making what appeared to be a fairly minor release suddenly a blocker on the project we were working on at the time.
Since then I've been very wary about changing versions of Plone mid project, even when the documented release notes show very few changes. The problem for me is that the release notes do not show every change. Even the relatively detailed release notes for the 2.1.3 release didn't include all of the changes that were made that directly impacted our project, and the notes for later releases contain even less (see, for example, the ones for 2.5.4).
We recently found a nasty bug in Plone 2.5.3, where users couldn't register if their desired username was contained within the username of another user. E.g. if a user with username freddy already existed the usernames fred and eddy would both cause the The login name you selected is already in use or is not valid. Please choose another message when a user tried to register with them. The bug appears to have existed throughout the Plone 2.5.x releases until 2.5.4, when it was identified and fixed.
This is major bug. Any Plone site at 2.5.3 or lower with a medium number of users is going to hit this problem. Here at Isotoma our first port of call is to start hunting down the bug, but most Plone deployments aren't done by people with such intimate knowledge of the code base. Most people's first port of call will be to see if this bug is fixed in later versions. In this case it was, but the release notes didn't mention it.
So. If I'm a Plone deployer (rather than developer) who's not comfortable with the source do I a) upgrade in the hope that my bug might be fixed in the latest version (and not knowing what else might have changed), do I b) stick with the version I've got and work around the problem, or do I c) think seriously about an alternative CMS that tells me when my bugs been fixed?
What I'd really like to see is a simple list of all tickets that have been closed and all the commit messages that have gone into a particular release. Trac (which the Plone team uses at dev.plone.org) has this ability to do this right now (here are the tickets for 2.5.4, for example) - all we need are the links on the release page so that those users that aren't developers and aren't comfortable with the tools we use have easy access to the information they need to assess if and when to upgrade.
Limi (the Plone project lead) recently posted 18 Things I wish were true about Plone. Number 1 is Simple development should be possible entirely through the web interface. This really talks to the pretty much constant discussion within the Plone community that the product can be hard to get started with and that it feels like you need to be a developer to use it.
I can't help but feel that incomplete release notes are a part of this problem. For the want of just a little extra Trac magic and the judicious placement of links this wouldn't be a problem.
As an aside... While writing this post I wondered how the Drupal team handle it. They do, indeed, do it differently. They provide detailed ticket based release notes for each release and easy links into their CVS for each main branch. I kind of wish they didn't, to be honest...
Yesterday I ordered a new server from our ISP, as I do pretty regularly. I happened to take a look at the “bandwidth” dropdown on their order form, and you can now get a Gigabit of unmetered internet bandwidth to your server for £3000/month.
This got me thinking. What on earth would I do with all that bandwidth? Well, serving video is the obvious application. Lets try live TV, something exciting, maybe sport. If you don’t do anything clever at all, just ship data to every individual person who wants to watch TV, how much would it cost? Say you need 10Mb per person for the video stream.
£3000/month is £4.30/hr for a Gigabit. For this you can serve 100 people their TV. So, 4.3p/hr/person for a video stream. Reckon you could make 4.3p / person / hour from advertising on a live sports channel? I reckon so.
So why not do it right now? Two reasons. People don’t have the Internet on their TV, and bandwidth isn’t enough of a commodity. If I wanted to broadcast the FA Cup Final to 500M people, I’d need around 5 Exabits of bandwidth, just for a couple of hours. The market just isn’t there for me to buy it like that. Yet. But it will be - it’s the direction the industry has been moving in, at vast speed, and there’s no reason to think it’ll stop.
Give it a few years. Imagine a day, not that far off, when everyone’s TV is on the Internet. I, personally, could bid to broadcast the Cup Final on the basis that I need to make, say, 25p per person in advertising. Obviously I don’t own any cameras. Or Gary Lineker. But both of those are available for hire, at the right price.
I’m not proposing to go into the sports broadcasting business myself, but the effects of bandwidth commoditisation are going to be felt very soon in the TV business, and they are woefully unprepared for it. Commoditisation lowers barriers to entry and lowers the cost of innovation. Right now anyone betting on their TV channel keeping audience just because they’ve already got them is betting against Moore’s Law. And a bet against Moore’s Law is a very, very bad bet.