Alex Hudson

Coming up with convincing vision and mission in a corporate environment is never easy – in fact, I think it’s one of the most difficult things you can do. Setting a clear and crisp vision is crucial to create an aligned organisation. Refining down into an elevator-pitch sized statement while avoiding generalisations, platitudes and (frankly) abstract jibberish is practically impossible.

Doing so outside a corporate environment I think is even more difficult – money is at least a straightforward motivation to hang a hat on. One of the best guides to doing this is Guy Kawasaki’s Art of the Start Manifesto, I particularly like the bit about making mantra.

Read More

Back in 2010 I wrote a post about Canonical’s business direction, in response to something Bradley Kuhn had posted. Both he and I were worried about Canonical becoming reliant on an “open core” business model – worried not just from the perspective that it would dilute the principle of Ubuntu, but that frankly every time I have seen this executed before it has been a dismal failure.

The posts are worth re-reading in the context of Mark Shuttleworth’s announcement today that Ubuntu will be dropping a number of their in-house technologies and, more importantly, abandoning the explicit goal of convergence. I would also say, read the comments on the blogs – both Bradley and I found it deeply strange that Canonical wouldn’t follow the RHEL-like strategy, which we both thought they could execute well (and better than an open core one).

Of course, our confusion was – in hindsight – obvious. We weren’t seeing the wood for the trees. The strategy has since been spelled out by Simon Wardley in his rather good talks; one example is here:

It’s well worth to take the time to watch that and understand the strategy against RedHat; but it’s pretty easy to state: “Own the future, wait for it to come to us”. Let’s see why this is important.

Read More

Not that long ago, I did a switch on my Android phone: against all the promises I made to myself beforehand, I switched on the Google account and allowed it to sync up to GCHQ/NSA the cloud. I did this for one main reason: I had just got an Android tablet, and I despised having to do the same stuff on each device, particularly since they weren’t running the same versions of Android, and one was a Nexus – so not all the UI was the same. The benefits, I have to say, were pretty much worth it: I don’t have too much sensitive data on there, but the ease of use is incredible. What was particularly good was that when I broke my phone, and had to have a new one, once the new one was linked up everything was basically back how it was. That’s tremendously powerful.

Read More

In my previous post about virtualenv, I took a look at a way of making python environments a little bit more generic so that they could be moved around and redeployed at ease. I mentioned docker.io as a new tool that uses a general concept of “containers” to do similar things, but more broadly. I’ve dug a bit into docker, and these are my initial thoughts. Unfortunately, it seems relatively Fedora un-friendly right now.

Read More

Recently I’ve been trying to bring an app running on a somewhat-old Python stack slightly more up-to-date. When this app was developed, the state of the art in terms of best practice was to use operating system packaging – RPM, in this case – as the means by which the application and its various attendant libraries would be deployed. This is a relatively rare mode of deployment even though it works fantastically well, because many developers are not happy maintaining the packaging-level skills required to maintain the system. From what I read the Mozilla systems administrators deploy their applications using this system.

Read More

(For those looking for an rpm rant, sorry, this isn’t it….!)

Currently there’s a ticket in front of FESCo asking whether or not alternative dependency solvers should be allowed in Fedora’s default install. For those who don’t know, the dependency solver is the algorithm which picks the set of packages to install/remove when a user requests something. So, for example, if the user asks for Firefox to be installed, the “depsolver” is the thing which figures out which other packages Firefox needs in order to work. On occasion, there is more than one possible solution – an obvious example often being language packs; applications usually need at least one language installed, but they don’t care which.

Read More

Just yesterday people jumped on the biographies and abstract for a talk at goto: the Keynote is Google’s first public information on Dart, a “structured programming language for the world-wide web”. Beyond knowing a couple of the engineers involved – which allows a certain amount of inference to take place – there’s also some speculation that Dart is what this “Future of Javascript” email referred to as “Dash” (this seems entirely possible: a dash language already exists; Google already used ‘Dart’ for an advertising product but have since stopped using that name, potentially to make way for the language).

Read More

Scott James Remnant blogged his ideas about how to improve the quality of Ubuntu releases recently, triggering some discussion at LWN about the topic. I offered some opinions about Ubuntu which are not terribly interesting because I don’t get to use it often; however, I did also write about Fedora based on the last couple months’ experience of Fedora 15 & 16.

Before I get to that, at roughly the same time, Doug Ledford was posting his thoughts about the “critical path” process – essentially, saying it was broken. I’m pretty sure he will find vociferous agreement with his views, based on previous feedback, but not (alas) from me.

Read More

Over the past couple of weeks, I’ve been pondering the above question for a number of different reasons. For people who really study programming, like I attempt to, there are a number of claims/myths/legends/tales that are commonly held about people who cut code for a living, such as:

1. some programmers, the “alphas”, are as much as ten times more efficient than the common programmer;
2. there are people who “get” computers, and those who don’t. Cooper splits these into “humans” and “homo logicus”. Those who don’t grok computers are destined to never be able to program;
3. there are people who are paid to cut code, and who simply can’t – they rely on auto-complete IDEs, cut’n’paste library code, etc.;

For the purposes of this post, I’ll separate between these different concepts: the “goats” (people who cannot code, at all), the “sheep” (people who code, perhaps professionally, but poorly) and the alphas. Sheep and alphas are collectively referred to as coders.

Read More

Last night, we decided to order pizza – we don’t do it often, it’s lazy but sort of a treat. However, out of the three local well-known places, only one was open: the other two had shut down early. Now, we don’t live in London per se, but Croydon (where there were major fires and a member of the public was shot just a night ago) is only a few miles east, and Clapham a few miles north. Sutton, the local town, had some windows broken by youths, but to be honest this isn’t exactly exceptional behaviour in Sutton.

Read More