Posts Tagged ‘herding cats’

Releases, release notes and branding

Following on from my comments about our brands, I want to talk a little about how this affects our release announcement and release promo.

One thing you’ll notice on the upcoming KDE Release Day is, well, the use of ‘KDE Release Day’. When we discussed our branding structure, both last November and at Akademy, we agreed that the software compilation (or what used to be KDE 4.x) is just a result of the way we organise ourselves: it is convenient to release a lot of things together to get group testing, make life easier for localisation, packaging and to give us big promotion opportunities a couple of times a year. The software compilation is an organisational thing – it’s the collection of KDE modules and being in the software compilation means application developers get some stuff done for them (release management, general promotion and localisation) while in return they have to follow the same release schedules including freezes as everyone else. Some of our highest profile apps such as Amarok, digiKam and KOffice prefer not to be in the software compilation and are big enough to handle their own releases.

We recognised this and the fact that the software compilation is not a product, but it is something that people need to refer to sometimes: “Is KMail 2 going to be part of SC 4.5.0? No, it will be part of SC 4.5.1″. That is why we settled on the name software compilation rather than something catchier – it was never meant to be a brand. However, we didn’t get things quite right. The initial announcements were ok, I think, but we then promoted the software we released in SC 4.4 as KDE Software Compilation 4.4. We promoted something that wasn’t really a brand or a product, rather than concentrating on our actual products of the Plasma workspaces, Platform and apps.

Picture of the 4.5 release announcements

Announcements for our 4.5 release day

So, for 4.5 we’re trying to be more true to our original intentions. You won’t see the software compilation mentioned in the official announcements, but instead we will talk about the actual products. We are also more accurately reflecting the purpose of the SC (a simultaneous release of software) by referring to the KDE Release Day. On this day we release new versions of our three main product groups: workspaces, apps and the KDE Platform.

We’re not trying to stop you from using the terms software compilation or SC – we need some way of referring to this thing we release every six months. But externally we encourage you to be more specific where possible. So if you like the new activity manager, it’s more precise to call it a cool new feature of Plasma Desktop 4.5 than SC 4.5. Likewise, if Marble’s new routing capabilities get you excited (and they should) then be excited about Marble, not the SC.

Now, KDE’s 4.5 Release Day is almost upon us and the promo team has been very busy getting the release announcements ready. Personally, I’ve been away on holiday for a couple of weeks and therefore pretty useless :-) but – as always – other people have picked up the slack.

To highlight this, in the pic on the left is of our 4.5 release announcements as written in our EtherPad installation.

One of the many nice features of EtherPad is that you can use colours to track contributors, so each colour you see there represents the work of a different person (except that a few people managed to use two different colours…). The mass of light blue is Jos, although some of that is an import from work Luca started in Google Docs. The bit I really want to point to though is the yellowish part (first paragraph and many others) that belongs to Dion Moult. Not only has he put in masses of his own work, but also rallied people on the promo mailing list to make the needed edits and add information. Dion has been around for a while now – I think I first saw him on the kde-promo list in September 2009 – and it’s awesome that he has taken this and pushed it. Sometimes what is most needed is someone to keep an eye on what needs doing and bug people to do it.

Tags: , , , ,

Hierarchies versus freedom

Jos has been getting very philosophical lately. One post that got me thinking about how odd KDE is (in a good way) was his one about working together.

KDE is quite unlike anywhere else I have worked, for fun or profit. Probably the closest analog is my involvement at university with the student newspaper, the Warwick Boar where I started off writing general features and ended up as Science Editor.

The Boar had a few similarities to KDE. It was staffed by volunteers, was successful (we won awards and stuff), diverse and quite large (I don’t know exactly, but well over a hundred contributors). However, unlike KDE, it was hierarchical. At the top was the Editor, who had ultimate power and responsibility. He or she made the call when someone threatened to sue for libel, or when one of the big national newspapers wanted access to one of our sources (it happened). Below the editor, each section had its own head, responsible for organising their team and making sure that their pages got done.

As a writer, you got told what to do and you did it. You could make suggestions and argue, but ultimately if your editor disagreed you could either accept it or go away. As editor, you had to get things done. If none of your writers turned up one week then you had to put the section together yourself and meet the weekly deadline.

Such an approach, with a named person responsible for every aspect of the project and sanctions (like getting sacked) for getting it wrong, meant that the newspaper always arrived on time and was generally of decent quality.

KDE is quite different. We don’t really have a hierarchy. Sure, there are people in each group that are almost defacto leaders – people listen to them and they push things to get them done, but there tends not to be one person whose approval you need to get to do something. There’s also no one to make you do things and no one who will have to sort things out if you screw up. This can be a good or a bad thing.

Costs and benefits of being KDE

Benefits of a hierarchy:

  • If a named person is responsible for doing something, generally they do it
  • Power lies with experienced people who are less likely to screw up
  • People outside the organisation know who they should contact (even if they don’t know a name, they ask for ‘the Science editor’)

Costs of a hierarchy:

  • If you are going to be held responsible for finishing something you get involved in, you may be discouraged from getting involved in the first place
  • Power lies with experienced people who are less likely to take chances, try new things and make things better
  • People outside the organisation are only aware of the leaders and they tend to get the credit (or blame) for the successes and failures of the organisation as a whole – so the people actually doing the work can feel that success or failure will have little impact on them personally
Cats playing on some tarmac

Herding Cats

Going back to my experience with the Boar and contrasting it with being an editor on the Dot: on the Dot we work by consensus and a few rules that we set. That sometimes means we’re a little slow to get things done because there’s no one person who has to do it. If everyone is busy then it doesn’t get done. However, it also means there are more checks and balances in place – I made a couple of major screw ups while working as an editor on the Boar because I didn’t have to consult other people, but on the Dot we rarely make really big mistakes that don’t get spotted before publication.

There’s also the question of time as a volunteer. If being involved in the Dot meant committing to getting things published within set deadlines and taking sole responsibility for that then I would have to resign tomorrow. We all have real jobs and other things to do and simply cannot make those kinds of commitments.

Conclusions

For me, KDE is in some ways flawed by its freedom – the fact that we can all, in theory, wander round doing whatever we want. Looking at it that way, it’s amazing we ever get anything worthwhile done. But in practice, the bonds withing teams and the consensus that we build mean that generally we do things pretty well. A more rigid structure would kill a lot of that and I think we would have a lot less people involved because it would be less fun and would require commitments that people simply cannot make.

Some more experienced gearheads sum up getting things done in KDE with the simple phrase of “herding cats“. Well to all our cat herders out there: thanks. You do a great job.

Tags: , , , ,