20 GB of Ogg Vorbis files

Why do I have 20 GB of Ogg Vorbis files on my computer? Or perhaps the question is, why to I still have 20 GB of Ogg Vorbis files on my computer?

Ogg Vorbis is an audio compression format. Think MP3, but then think open, non-proprietary, patent-and-royalty-free. Oh, and also think quality. Now you are beginning to think about Ogg Vorbis.

I first started using Ogg Vorbis back in 2004. I wanted to purchase a personal music player for my wife for our anniversary. I was concerned about using a proprietary format such as MP3. Largely this was because I was working for OSS Watch at the time. I was learning so much about free and open source software and open standards that I wanted to put some of what I learned into practice in my personal life. Since Ogg Vorbis was the leader amongst the efforts to provide a high-quality non-proprietary codec I went with it. I was also delighted to find that iRiver, at least back in those days, had a substantial player, the iRiver H140, that supported Ogg Vorbis natively. Anniversary gift solved!

One thing leads to another and three years later I find myself with more than 20GB of Ogg Vorbis files on our main desktop computer at home. If I tell you that I generated all of these from cds we own, you will get some idea of the size of our cd collection. Music is important in our lives – all forms of music: folk, rock, jazz, classical, opera, instrumental and more. As soon as we buy a new cd, I rip and encode it as Ogg Vorbis files, for backup and for use on our various players.

For myself, I’m happy with a 1GB player on which I store a selection of my favourites suitable for running or for sitting on a bus. My wife does the same thing for running, but on the bus she likes to have everything available to her: absolutely everything. Hence the value of the 40GB iRiver player she has been using. I should say also that we have always been happy with the quality of the music we get out of our personal music devices. So no complaints there.

So, everything should be fine. Why then am I wondering about that decision I made a number of years ago?

Two things. First, I need to replace that iRiver player. Alas the hardware was not as reliable as the software. And there is no doubt that the cool gadgets for music these days are Apple’s iPods. Players, even the hard disc ones, have got much smaller and sleeker. I would like to get something cool for my wife. Second, I no longer work for OSS Watch. So I don’t have the same impedus, perhaps, to support so-called marginal codecs even if they are non-proprietary. Or do I?

I know that I could just buy an iPod and install Rockbox on it in order to play Ogg Vorbis files. But I just can’t convince myself that buying a new iPod and then immediately wiping its operating system is a clever move.

So what should I do? Should I abandon what I started some years ago and switch to the better supported MP3 format? Or another way of putting that: is there still a reason for me to be using Ogg Vorbis (now that I no longer work for OSS Watch)?

It’s that last question that has me thinking. In essence it amounts to a question about what the significance is of free and and open source software and open standards in an ordinary person’s life. By ordinary person, I just mean someone who isn’t directly connected to the business of free and open source software or open standards (of course those people are also ordinary folk, it’s just that they have special interests/reasons in this area). Is there a reason to choose an open standard or open source, even if it entails a bit of extra bother (like not being able to use the latest cool gadget, or needing to search around a bit to find compatible hardware, etc.)?

I think there is.

It is a question of principle and conviction, a question of deciding who you are and why. Curiously it is not a question of technology, except to the extent to which I want to be in charge of my technological choices rather than have the market decide for me.

Note that this is not the hypothetical question I often ask people. I usually ask, if two software products equally met technical and user requirements but one was proprietary and the other was open source, which would you choose? That question is about whether there are aspects of open source that might be decisive in an otherwise technologically neutral choice situation. The question above, however, is about whether even in a non-neutral situation, it might be rational to choose the open source or open standard option.

I think this is the point where, as we used to say when I was younger, the personal becomes political. My personal choices are political.

And that too has me thinking. Thinking about what kind of a political being I have become and where this will lead. But I also think this is a question I am going to be returning to again and again over the next few years. It seems to me that there is a good reason to use open source software or open non-proprietary standards even if that choice, in some cases, means I get marginalised.

Canada: chapter two

I have been in Canada now for about a month and a half, enough time to have got my bearings and to make some decisions about where I’m headed.

First off, let me say that it is good to be home. Home, I know, is a state of mind. While I lived in Oxford and London, I quickly settled on those locales as home. Because I really need to feel like home is where I’m living. Maybe that’s just me. I don’t function well with divided loyalties, the constant longing to be somewhere else, somewhere that isn’t here. I always want to be precisely where I am. And that’s why home is a moveable feast for me. So I can say again, with as many layers of meaning as you like – it’s good to be home.

Home is now Waterloo, Ontario. It is half of the Kitchener-Waterloo conurbation. The Waterloo half has two universities (University of Waterloo and Wilfrid Laurier University), the Perimeter Institute for Theoretical Physics, Research In Motion (RIM), an excellent repertory cinema – The Princess and its sister cinema The Princess Twin, and enough Tim Hortons coffee shops to make me think I might be back in Hamilton again. It’s a nice town. It has a thriving Uptown area of shops, an excellent public library, a vibrant arts and music scene with plenty of free festivals throughout the summer, and a scattering of parks and cycle routes. All this and yet mere minutes drive to some of the most lovely countryside in the province, complete with an industrious Mennonite community about which I have much to learn.

There is a bit of an open source and free software community in the region. For example, I’ve already been to a meeting of the Kitchener-Waterloo Linux Users Group (KWLUG). But with plenty of universities within a short drive (e.g. the University of Toronto is only 90 minutes drive away) there are numerous opportunities for those with a background in open source development, free software deployment, and a bit of drive and determination. Even RIM periodically advertises for individuals with open source experience.

What there isn’t is anything like OSS Watch. Indeed there isn’t anything like the numerous significant advocacy groups that I knew in the UK. Maybe I just haven’t found them yet, but if I haven’t then they are well hidden.

What there is, however, is oodles of potential and buckets of opportunity. It’s a cliché, I know, but everyone here in Canada has been ever so nice. You get the impression that if you put forward a good idea, there will be lots of hands to help out straight away. It’s a place where community isn’t just a word.

And finally a word for family. I’ve seen more of my family (parents, sisters, nieces, nephews, etc.) in the past month than I have in the past 10 years combined. And that turns out to be a good thing too.

It’s nice to be home.

Moving on

For the past four years it has been my great pleasure, even honour, to work for OSS Watch, the JISC-funded national advisory service on open source software in the UK based at the University of Oxford. And now I’m moving on.

I knew almost nothing about free and open source software back in 2003 when Oxford won the bid for this small, pilot, advisory service. I was given the role of Communications Manager (splitting that with a job of the same title for the Humbul Humanities Hub, another JISC service based at Oxford). It was my task to ensure that OSS Watch had a clear message to communicate and that it reached the right people. In fact, communications was the sole function of OSS Watch as we set about raising awareness and understanding of the legal, social, technical and economic issues that arise when educational institutions engage with free and open source software. With more than 500 tertiary education institutions in the UK, this was no small ask for an advisory service with a staff of only 1.2 full-time equivalents (FTE).

Fast forward four years. OSS Watch is now a robust advisory service with 5 FTE, a team that I’ve been proud to lead for the past two years. It now provides direct, practical support for JISC’s 200-plus software development projects struggling to cope with an open source development methodology with which they are (mostly) unfamiliar. A big challenge, but also a huge reward. It’s an amazing kick you get when young and enthusiastic developers and educational practitioners grok open source for the first time: realizing the value of building communities around their development projects from the very beginning, as well as appreciating just how hard that can be. OSS Watch is also now working closely with Knowledge Transfer Units at the UK large research institutions, raising awareness of open source licensing and, especially, open source business models.

It’s hard to leave that behind. But mostly it’s hard to move away from the vibrant team of men and women whom I’ve had the pleasure to work with these past few years. Not everyone gets to work in a team. Most people’s working lives are spent either on individual projects or as part of a work group. A team is something else. In a team all of the players work together toward a common goal. Everyone is vital to that outcome.

OSS Watch will survive without me. In fact, it might even grow and become something better. Meanwhile I am on my way to Canada to start a new life. I will be based in Waterloo, Ontario, a city I have never even visited. I can’t say for certain what I will turn my hand to once I’m there. But I can say for certain that the future is open.

Communication in a small team

For some time now I’ve been thinking about communication tools used by small teams. In part that is because I work in a small team. There are 7 of us now in the OSS Watch team, though that is slightly misleading since only two of us work for OSS Watch full-time. Everyone else is either half-time or less. Moreover, no two of us share an office. And those conditions

  • distributed participation
  • partial participation

are typical of most open source projects. So the nut I’m trying to crack is one that lots of others have been busy cracking for some time.

Here are a few of the things I have learned so far about communication in a small team.

There is nothing new under the sun.

You may think you need to re-invent the wheel, but in fact the best solution to your communications challenge is probably being used by someone in the next room (or the next project). Go ask them what they use and try that first.

Everything is new to you at least once.

You may not need to re-invent the wheel in order to ride a bicycle, but you are still likely to fall off a few times. Don’t pretend there is some magic short-cut to successful communications. New tools take time to get used to. And each new member of your team will have to go through the same (difficult?) learning process.

Talking with people is hard; talking to people is easy.

Communication is about talking with one another, that is talking and listening. The tools you use will not compensate for your limitations as a communicator. So you are going to need practice. Lots of practice. But you may not have a water cooler at which to go stand around and practice. So you need to think of other mechanisms.

I don’t think I can adequately emphasize just how important this is.

In a fully distributed team (where you really don’t have the chance to meet face to face on a regular basis) there need to be multiple channels and levels of communication. It doesn’t matter whether you push this off to an irc channel (though that too could be your principal communication tool). What matters is that there are opportunities for members of the team to put some flesh on their digital bones.

Time is elastic, it snaps back when you stretch it.

Since you can’t expect the undivided attention of your partial participants at all times, you need to structure communications in such a way that they can participate fully as and when their time permits. What does this mean in practice? Don’t treat email as though it is a synchronous communications tool, even if it effectively is for you. Let other people get involved in a discussion rather than dominating it simply because you are always on.

Keep it fun.

Life isn’t just a grind. So why make it one?

Keep trying new things.

There are always new tools to play with, new ways of organizing meetings, new opportunities to facilitate communication.

Here are the tools that my team uses at the moment. They may have changed even by the time you read this because I’m always looking for that next opportunity.

  • team emails
    lots of emails that go to and from the whole team – and when I write lots I mean lots
    (okay, I confess, I’m a bit of a dinosaur and this is my preferred route to team communication)
  • email list
    dedicated mailing list for specific topics; be aware that some members of your team may not distinguish the specialized team mailing list from their ordinary team emails (yes, that’s me still on the upward slope of the learning curve)
  • irc channel
    some people just love to use irc; great, so now we take advantage of that with a dedicated #oss-watch channel at irc.freenode.net; this serves at least two purposes (as everything should) – it provides an outlet for team chatter that only hits those members of the team that are actually working on OSS Watch stuff at the time, but it is also publicly available thus providing a further interface to the team for our stakeholder community (or at least the ones who like using irc)
  • team blog
    recently we started a team blog to let us explore issues with each other (as well as the wider world) in public; it was time, I think, to let others see that we don’t always agree even amongst ourselves – but we do value the way in which we negotiate across those disagreements toward some common understanding
  • internal team wiki
    a safe place for our initial thoughts, debates (yes, we usually thrash an issue from all sides), explanations of how to do things – very useful for new members of the team (or old ones with faulty memories), team meeting minutes and curiosities
  • team meetings
    not everything needs to or should be done digitally, if you can mange it; our team meets once a week for an hour; since we use so many other communications tools, these meetings serve a different function – they remind us that this team is made up of real people
  • monthly team day
    I won’t embarrass anyone by telling you what we actually call these, but they are not meetings as such, rather they are days when we pool our collective time in order to work together on something such as reviewing our published documents, exploring a new open source development tool, arguing the pros and cons of some topical issue, etc.; each one is different and yes, food is involved

I haven’t learned all there is to know about communication in a small team. But I am trying.

Building a community: email archive profile

A wander through the public email archive of a project’s development list or its user list is, for me, a prerequisite to involvement of any kind. But that may just be me. I am not a programmer with a particular itch that needs scratching. So I can afford to be choosy about where I spend my free time. And I don’t have the skill set to be fascinated by a project simply on the basis of its truly remarkable code – code from which I could no doubt learn a thing or two. Those are both great reasons to get involved in a project: individual need and learning. But they aren’t mine.

If your open source project scratches someone’s itch exceedingly and uniquely well, you will probably have no difficulty in attracting people with similar itches to your project. They might even stay around regardless of the environment because that itch has just got to be scratched.

If your open source project happens to have such brilliant programmers that they are collectively pushing the envelop or even defining the nature of the envelop, again, you will probably have no difficulty attracting people desperate to learn from you and develop their own skills. And again, they might even stay around regardless of the environment because of the substantial benefit they are getting in terms of learning.

I’m guessing, however, that the vast majority of open source projects do not fall into either of these camps. Certainly the majority of projects that I encounter on a daily basis are only moderately itch-scratching and very rarely paragons of programming excellence. They are the relatively unsung projects that address a particular need, but not necessarily uniquely. They do their best with regard to their code, but they aren’t going to be written up in next textbook for computer science 101. And nearly all of them would like to grow their project in some way. Indeed, many need to grow their project, to build their community base, or the project will not survive at all.

It seems to me that I am a likely candidate that such a project might wish to attract. I’ve got a bit of free time, a modicum of ability to provide content authoring or user support, but not such a high opinion of my own coding that I think my talents would shine better in the bright heat of one of those star projects mentioned above. What kind of things will I be looking for when I first visit the email archive for this project?

In no particular order, these are some of the things I look for:

  • modest throughput
    • lists which are too busy will take up too much of my time reading, so I won’t have time to contribute
  • project focused
    • if the majority of discussions on a development list are about the recent events on Big Brother, it’s not for me
  • treatment of newbies
    • I’ll be a newby if I join this project, so I want to know how I’ll be treated by those who have been around for some time. I can get abuse at work; I’m not going to bother hanging around for it on my own time
    • societies are said to be judged by their treatment of their most vulnerable members; for me, that’s also true of open source projects
  • clear guidance for appropriate behaviour
    • this could be guidelines on the project site, but it also could just be evidenced through the example of the key members of the project and their periodic explanation to newcomers
    • sometimes this guideline is codified into an acceptable use policy (AUP). AUPs do not have to be draconian, they just have to make things reasonably clear and give a pointer to what will happen (or what you should do) if there is a confusion.
  • periodic summaries by the list owner
    • this is not essential, but it is incredibly useful to have someone periodically summarize the discussions that have taken place on a list that is receiving more than 10 emails per day. Once per month is probably more than sufficient. It recaps for those who have been filtering this list to read later, and it reinforces the usefulness of the archive to those searching. I don’t see this nearly often enough.
    • this probably sounds like a lot of work. Hey, if you want to attract me to your project, maybe it’s worth a bit of effort. You might even convince me that this would be an excellent way that I could contribute to the project, i.e. by writing this summary for the list myself
  • treatment of those who for whatever reason abuse the list
    • people can abuse a list in lots of different ways, some deliberate, but most inadvertent. How do the key contributors to this list deal with that abuse?

Remember, I’m not one of those star developers looking to make a mark in a star project. I’m part of the long tail that will, due to the network effect, potentially make even your modest project successful.

What’s the email archive profile for your project?