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; 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?

Communities and meritocracies

In my work environment I almost never encounter anyone saying to me, “This is a meritocracy”. Do you?

I never hear political scientists or even politicians refer to our society as a meritocracy. What would it mean to say such a thing? I think it would come across as harsh, to the point of absurdity. What would we do with those who don’t warrant our merit? Cut them adrift? Expose them in infancy upon a high bare rock? It just doesn’t sound plausible. In the community context, even if some aspects of it are calibrated by merit, as a whole I think we would have to say, “This is our community. No one gets left behind.”

So why do I hear, “This is a meritocracy,” so often in various free and open source gatherings. It is said with pride and no small amount of beating of chests. But what does it mean?

Meaning, of course, might be tied to intention. I think what is intended by the claim in the open source context is that great technical merit will be rewarded by substantial affirmation. And who could argue with that? I like to see great scientists win Noble prizes. I see nothing wrong in showing our appreciation for their accomplishments. But the claim to being a meritocracy goes far beyond this. It indicates that decisions and, more important, who gets to make decisions will be determined on the basis of merit. Indeed, it suggests that only those with merit ought to make decisions.

Of course the claim is always bounded by a context. Thus: This is a meritocracy. That which is not this is not a meritocracy. To join our meritocracy, you must agree to our rules. And the first rule of our meritocracy is that only those with merit get to decide the rules.


As …ocracies go, this is fairly typical. After all, a democracy simply replaces those with merit by the mob, or demos. In either case, rules still get made by someone (or some group) after all.

But what happens when you try to marry a meritocracy with the notion of community? These days I regularly hear tell of the open source community, or community building around an open source project. That sounds nice, doesn’t it? But if community in these uses is simply equivalent to our gang, then all that has been said is that you want to increase the size of your project. Adding the word community doesn’t add anything new.

Should it?

I’ll rephrase my question. Does the notion of community mean something more or different than group?

I think it does. I think the notion of community encompasses all the interactions between individuals of a certain group. For example, think of a small town. There are people of all ages there, including infants. There are people engaged in a wide variety of activities not all of which are commensurate. Most important, while there may be decision-making procedures, of whatever kind, these are not defining for membership in the community.

As this is a point I’m struggling to make clear, forgive me for taking another run at it.

In my town, infants, small children, even young adults are not directly participatory in the decision-making processes. They do not have a vote. But that does not make them any less members of my community. Moreover the transition to the full decision-making process is based on something completely out of the control of any member of the community: age. And that is a curious thing.

Without presuming that I’ve fully clarified that, I’ll press on.

What happens when a small open source development project of one or two (or more) developers decides to set about building a community around the project? I would have thought that meant the project was setting out to broaden its base. But surely it doesn’t just want more bodies. It must want more roles, i.e. more things that different people can do for the project. Moreover the project leadership must be thinking that by building such a community they are somehow shoring up the foundations of the project itself.

And they would be right to think so.

A broad based community open source project has a whole range of individuals – by analogy, the infants, children, teenagers, adults, and elderly. And it won’t be true in such a community that everyone does the same thing, or has the same skills, or can be judged on the same scale.

It’s the reason a meritocracy breaks down in the face of real community.

Meritocracies are great for tight little projects. There is no reason to argue against them. Communities are great for large amorphous groupings of people that have curiously self-sustaining constituencies (probably because they keep having children!).

Whether the two can be brought together, however, remains an open question.

Learning while you learn

Every day, for at least 20 minutes, and often much longer, I work at building my French vocabulary. No need to detail my regrets for not learning French in my youth. The point is that I am committed now. Some of my effort is directed to reading from different sources be they newspapers, magazines or novels. But a fair bit of my effort is devoted to a near mechanical use of flashcards. Flashcards for vocabulary training are a tried and tested method. The more you use your card set, the more you build the reflexes in your mind to instantly recall the meaning of individual words or phrases. Indeed there is even a system that captures the varieties of algorithms that one might deploy in varying the spaced repetition of a card in a card set. It is called the Leitner system and nearly every computer based flashcard program going instantiates it in one form or another.

There are easily more than 250 electronic flashcard programs out there. The one that caught my eye and which I use on a daily basis is jMemorize. How did I select it?

My first step was to stick “‘open source’ flashcard” in Google just to see what would pop up. Go ahead, try that. You will find that there is an article from NewsForge on jMemorize that tops the list. Next step for me was to check out the jMemorize project site on SourceForge. SourceForge is not the home of all free and open source software projects. But it is an awfully large starting point. From a project summary page in SourceForge you can tell at a glance how large a project is (number of developers), what licence the software is released under which in the case of jMemorize is the GNU General Public License, the programming language and the operating system for which the program is intended (java and thus operating system independent), the bugs that have been reported (if the project is using SourceForge’s bug reporting system) and even a quick browser view of the subversion code repository.

Perhaps most important though is the pace of the project. It doesn’t really matter for something as small as this whether there is one developer or 10. What matters is whether the project is moving forward. Is there any momentum? Do new releases appear reasonably frequently? Are bugs being squashed? Are there any users out there sending in feature requests, contributions of code (even if they haven’t joined the project as a developer), or at least questions about how to use the software? It all adds up to a judgement about whether a project is healthy or moribund.

Of course the state of a software project is probably not the criterion you will want to use in selecting your flashcard program. The real test is whether it does what it says on the tin.

I am delighted to report that in over 6 months of using jMemorize, I have never been disappointed with it. That doesn’t mean it will do everything you might want it to do. It only means it does everything I want it to do. So it wins on functionality for me. Plus it wins on not have any superfluous functionality. I confess I (usually) like lean software. It also wins for me on being multi-platform. I’m constantly switching between machines with Windows operating systems and Linux operating systems. I needed a flashcard program that wouldn’t get in the way of my jumbled life/work arrangement. And of course it does make a difference to me that it is open source.

jMemorize is the project of a single dedicated developer, Riad Djemili, of whom I know virtually nothing. Nothing, that is, except that he does good work. Long may that continue.

Update: On 23 January 2007, Riad posted notice on the jMemorize blog that he was setting up a development mailing list for the project. So far it is a very low volume list, so why not consider signing up.