Social conflicts
BSD is over twenty-five years old.  In that time it has evolved from a simple redistribution mechanism at the University of California, Berkeley, then a research project, to a family of some of the highest-profile free software projects.

As I've noted before, I came to BSD from System V, the "professional" UNIX. When I did, I came with the expectation that free operating systems were toys, less professional.  As we've all discovered, that's not the case: even in my first article about BSD, in the June 1992 issue of iX, I wrote that BSD/386 Beta 0.3.1 was more stable than the Interactive UNIX System V I had been running up to then. Still, the development methodology is different, and we're still learning about it.  There's no doubt about the quality of the software, but how about the environment in which we develop it.  Are we being "professional"? Do we want to? One thing we expect of "professionals" is their social behaviour: they should treat each other with respect.

This is a delicate topic, especially at present.  I should make clear here that, although I am a member of the FreeBSD core team, the opinions I express here are my own.  All the information presented here is freely available elsewhere.

The bad old days

It's no secret that the origins of the individual BSD projects are closely related to interpersonal problems.  It's unlikely that the NetBSD and FreeBSD projects would have become a single project but for personality conflicts, but it's not beyond the bounds of imagination that the OpenBSD project might never have been started if it hadn't been for some serious disagreements in the NetBSD project.

Since then we've learnt a lot about running projects on the Internet, and the relationship between the BSD projects is now much more relaxed.  I like to think that Daemon News has helped contribute to a sense of communality.

That doesn't mean that people within the project always treat each other with respect, though.  Over the last several months I've seen some things happen which I find worrying.

Some people are just plain hard to get on with.  They have personality problems which make them arrogant or aggressive.  It's not surprising that more clever, successful people are arrogant than are stupid, ineffectual people, and we have enough clever, successful people on the project for arrogance to be a problem. On the other hand, of course, developing software can often be frustrating, and that can promote aggression.  In addition, the main means of communication in the projects are electronic, and we've repeatedly seen how some people have difficulty expressing themselves in electronic form.  Let's look at the problems that occur:

Email communication

For people outside the project, the initial form of communication is by email. Email has been around for a long time--I've been using it personally for well over 20 years--but there are always newcomers who have difficulty with the medium, and some take a long time to learn how to behave on Email.  One of the most common, of course, is annoying people.  Spam is relatively easy to deal with, and we're learning to ignore trolls, people who make deliberately inflammatory remarks with the intention of creating unconstructive argument.  [1].  But there are a number of other problems:

Off-topic posts

The FreeBSD project currently lists over 50 mailing lists, some of them moribund.  NetBSD has even more, while OpenBSD has few enough to assume that they're all active.  All lists have one thing in common: they're there to serve a particular purpose.  Some messages generate significant followups, and it's easy to get off topic.  Often enough somebody pipes up and says "Off topic! Please go elsewhere".

This kind of issue is usually harmless until somebody insists on continuing. It's disrespectful of the other participants, of which there may be many: for example, the FreeBSD-questions mailing list has over 2000 members, many of which are themselves distribution lists.  Normally this is an unintentional disrespect, but we've seen some flames on the lists as a result.

Interminable threads

Some on-topic threads seem to go on and on for ever.  Threads with several hundred messages are not uncommon.  Most such threads have two main senders, both of whom refuse to take the matter offline and quickly irritate the majority of the subscribers.  

Inflammatory posts

The most unpleasant are of course insulting, threatening, obscene or just plain nasty messages.  I suspect that most of them are born of frustration, sent by people who know how to behave themselves, but for some reason in the heat of the moment choose to ignore this detail and attack some other participant on the mailing lists.

IRC: complete anarchy?

I have been on a FreeBSD-related IRC channel for over three years now.  It's supposed to be private, which is why I'm not mentioning the name.  Traffic on this channel has changed significantly in that time.  I joined up shortly after the first FreeBSDCon in Berkeley, October 1999.  At that time, the channel was mainly technical in nature.  People talked about the work they were doing, though of course there was a fair amount of other traffic as well.  And yes, you'd see some off-the-cuff remarks, but on the whole the tone was friendly and cooperative.

It doesn't seem like that any more.  Yes, people still talk tech stuff, but there's a certain underlying feeling of hostility there.  It almost seems as if some FreeBSD developers use IRC as a tool for flaming, and some with operator privileges use them to throw other people off the channel.

Much of this opinion is subjective, of course, and I certainly have no intention of giving examples.  I'm not the only one who sees things this way: there have been a number of messages in the FreeBSD lists recently complaining of the same problem.  Gradually a subliminal feeling of hostility has grown up in the project.  Why is this?

The developers: the inner circle

FreeBSD and NetBSD are now round ten years old.  Many of the developers on both projects have been there for that long; I've been involved with the FreeBSD project for over 9 years, and sometimes I still feel like a newcomer.  People get to know each other during that sort of time, especially if they're working on similar parts of the project.  That doesn't mean that they always get to like each other.  People vary in character, and people with different characters can get on each other's nerves.  Add to this possible differences in viewpoint on how to advance the project, as well as a certain level of frustration, and it's not surprising that people tend to flame each other.  The larger the project gets, the bigger the problem.

How should we deal with the problem? Years ago, the NetBSD core team removed one of their number from the team.  One result was the OpenBSD project.  While there's still a noticeable amount of tension as the result of this decision, the results haven't all been negative: without it, the OpenBSD project in this form might never have developed.  At one level, though, it seems to point to the fact that like personalities work better together, and that this might be a good solution for such problems.

Growing pains

To solve the problem, we first need to understand it.  I mentioned arrogance and aggressiveness above, but that doesn't explain the increase in tensions.  One obvious reason for tension is simply the size of the project.  I mentioned this in April 2002 and June 2002. Things don't seem to have improved.  They haven't got worse either, but that's small comfort.

What can we do about the issue? Obviously the FreeBSD project has got too big for voluntary self-control, and I suspect it's only a matter of time before the other BSDs follow suit.  It's interesting to note that this kind of problem is more common in volunteer organizations, and I've seen a number of such organizations (not necessarily software projects) disintegrate as a result of interpersonal conflicts.  It doesn't happen in any well-run company: one of the first tenets of personnel management is that trouble-makers need to go, no matter what their technical merits.  In badly-run companies, financial considerations tend to limit the damage it can do.

Working around the problem

We don't have much experience in solving interpersonal problems, but in the FreeBSD project, we have gradually come to realize that there are people who will never behave themselves.  We have removed a small number of people from the mailing lists over the past year or two, mainly for continued off-topic posting or trolling.  We still suffer from people who use anonymous mail addresses, frequently copying or mimicking names of people in the project, who send trolls or flames to the mailing lists.  It's difficult to control these people, since we don't know who they really are.  It's worth mentioning: if you see abusive mail from a project member, check if it's not forged.  If it is, ignore it: that's the only way to handle the problem.

Things are a little different in the developer community.  We can't just throw out developers because they're abusive.  Or can we? The FreeBSD project has a Big List of Rules for developers, and it includes the possibility of expulsion from the project in this case.  In the past the core team has been extremely reluctant to use this "Big Stick": it's not good practice to throw out volunteers.

But what alternative is there? I suspect that as free software projects grow, it will become increasingly necessary.  It's important to keep expulsion as a last-ditch resort, but it's important to keep it.  In general, as projects get larger, they become require more discipline and rules than the original group of "amateurs" who started the project.  In this respect they resemble commercial companies.

At the beginning of this month, the FreeBSD core team finally decided to expel a member of the development team, Matt Dillon.  We didn't take this decision lightly: Matt has been a significant contributor to the FreeBSD project, but his personality has been disruptive.  Little of this is evident outside the project, and we have been roundly criticized for doing so.  As stated in the link, for the sake of the people involved we keep the details confidential.  It's possible that this is a mistake, but it's our current policy.

Not all feedback was negative.  We also received a lot of positive feedback. Interestingly, the positive feedback was in private messages, whereas the negative feedback was mainly public.  Less surprisingly, the positive feedback came from developers who had worked with Matt.

The future

Did we make the right decision? We're still feeling decidedly uncomfortable about the situation, but we believe it's for the best of the project.  The months that come will show whether the decision was correct.
[1] I stole this definition from http://c2.com/cgi/wiki?TrollDefinition and modified it a little.  I haven't read the entire discussion there, so I don't know if it ended up being the definition they chose.