Being an open source developer, there's a certain branch I have occasionally perched myself on to get a glimpse of the frustrating aspects of development in this field. The frustrations really aren't that much different from that of commercial software development project, but they're amplified by two factors: not getting paid, and having a much more diverse pool of users (including many with no money or social skills). I've dealt with my share of different people. Many are a delight to work with, while others have the tendency to push me to an early retirement. I wrote this article after observing the user base for several of my own projects as well as a few that are not my own and found a very thin line between respecting open source and frustrating it.

 

Granted, part of getting others to respect your open source project involves having a project worthy of respect. The idea of being accountable to users who aren't compensating you for a project is rarely at the forefront of the average developer's mind, and so there are a lot of average (or worse...crummy) projects out there that really don't deserve respect. I don't think they started out this way. Nobody starts an open source project with the goal of ignoring his or her users or creating something mediocre that nobody wants. Most developers start out with a passion about what they're writing and make it open source so they can share it. This suggests that they're at least somewhat open to what others' needs are. So if developers start out with passion, what makes for a crummy open source project? I think a lot of it has to do with the frustration involved in dealing with the community.

 

Much like a bad marriage, a disrespectful user base is like being stuck on the roof of your house. It's the CFO of the project - the evil morale-sucking vortex that frustrates the project and exhausts the developers. Just like any marriage, what started out as a passionate infatuation can very rapidly go downhill if the user base is full of nagging, abusive democrats. There are a few ways to recover from this type of situation. One could just stop liking people and ignore the user base. This shows up all too often in open source projects, which is how the catch-phrase "I like _________, I just hate the fan club" started. Some other well known projects try and separate the developers from the users, but that doesn't seem to work very well either - after all, a successful project is one that gives users what they want, and how are the developers supposed to know what the users want if they're separated from them. The other possibility is to weed out the bad elements. Reputation systems aren't a new concept, but they're usually reserved for wide-area networking or spam filtering, and rarely ever applied to people-based systems. This is done for good reason too - people get hurt. A user base is a tangled, messy thing to deal with and it's very likely that by lowering the credibility of some, you're going to end up making a dumb mistake somewhere. Therefore, to satisfy my moral requirements, I try not to think of it as a means of isolation or favoritism, but a simple survival tactic. If the project is going to remain alive, the more important people need to get more attention and that can't happen unless the less important people get less of it.

 

Identifying the Bad Elements

Like I said, the open source community is a very diverse set of individuals. You can get high school kids with no people skills and you can get highly paid technical professionals (also with no people skills). When you sell a piece of boxed software, on the other hand, your user base is already somewhat determined: users who can afford your product, and users who find it valuable enough to pay for. Now imagine the difference between that and giving away free AOL CDs and think about the change in user base you're likely to encounter. Any open source project is almost guaranteed to experience some set of bad elements. What's important is identifying those bad elements and preventing them from draining the morale of the project.

 

I set out to isolate some of the major frustrations a typical open source project is likely to experience. It just might provide enough information for developers to deal with them more appropriately, and more importantly for the antagonists to realize that they are antagonists (as most people who suck a project dry don't realize they are doing so). There's a way to respect open source that can lead to the cultivation of a project. There are also very similar approaches that can lead to certain flame war. I've forced myself to give my headaches the benefit of the doubt for the time being and believe most who frustrate my open source projects do so unknowingly, and actually believe they're benefiting the project. Of course, I could be wrong, but believing this is one of the ways I've prevented myself from black-holing half the Internet. Below, you'll see the most common types of personalities that frustrate a lot of open source projects. Notice I say personalities and not individuals. This is because some individuals seem to take on multiple personalities. Below is a list of people to not ever be if you're participating in a software project.

 

The Philosopher

The first frustration most open source developers are likely to run into is the philosopher. There's a fine line between someone with valuable input and an annoying blockhead. The former spends considerable time using the project and offers (in moderation) bright and innovative suggestions that would benefit a large group of users, while the latter arrives at a new project and very rapidly develops a list of things the project 'should do' to suit their own needs. The philosopher is convinced that they are benefiting the project by contributing their endless wisdom of how things should work, rather than provide any truly valuable insight. Many times, the issues raised will be issues which have been discussed at length in the past, and abandoned for good reason, thus once again opening up a can of worms and wasting the project leaders' time explaining why it was decided not to go that route. This is very different from desired "idea people", who will peruse mailing list archives and documentation before making a suggestion (and humbly at that). This is very different from the philosopher's overbearing (and occasionally arrogant) manner which usually leads to putting the developers on the defensive. If not properly handled, the philosopher can easily become the next type of individual.

 

The Critic

The critic is the next logical step of evolution for the philosopher. Critics, like philosophers, have their own beliefs about how the software should work, but attempt to go the extra distance to explain why the developers were wrong or why the project is deficient for either not implementing something the critic requested or implementing something they were against. In many cases, the critic actually believes they are doing a service to the project by providing a motivational drive to improve the software (a drive which nobody asked for), when in reality they are providing the negative reinforcement that causes many projects to close up to its users. Typical critics don't code or submit any patches to actually help improve the software, but mistakenly place the value of their contribution solely in their "constructive" criticism. Many critics also disregard the proper bug submission procedures in favor of spamming an email list with their gripes. Once again, there is a very distinct difference between a critic and a positively motivated individual with many good ideas.

 

The Beta Tester From Hell

Beta testers from hell (also known as self-proclaimed "project managers") offer their "skills" by finding several flaws in a project (usually several small ones) and then attempt to project manage their correction on a mailing list or in a support chat. Nobody actually asked them to be a beta tester, and it's especially odd that they would consider themselves as one when a project is already in production, which is probably one of the oddities of their personality that cause them to treat the software as if it were beta. Rather than actually write a line of code to try and author a patch, this type of individual prefers to believe they are benefiting the project by playing "QA Department" and hounding the authors until the problem has been fixed to their satisfaction. The authors usually knew about the minor bugs already or don't consider them important, but this doesn't prevent the troubled soul from ensuring they get fixed, exhausting the authors. The beta tester from hell is the opposite of a healthy tester who, upon request, tests certain features in a project and reports back with directed feedback relevant to that sought. Healthy testers are also interested in testing features they don't necessarily use, while the project manager is typically only interested in ensuring the features they use the most work.

 

The Patch Overlord

Everyone loves good patchers. Patchers have the ability to zone in on bugs nobody ever knew were there and submit a full patch complete with notes and pre/post debug output. The patch overlord, however, exhausts developers rather than assists them. This type of individual usually comes out of the woodwork and hangs around until their welcome has expired (usually forcefully). And since most developers feel a bit weird about booting people at least trying to contribute patches, they are usually around for a long time. Overlords attempt to benefit the project by "rapid development", which leads to hitting the project with several new, untested, and undocumented patches they've written for the software. These are usually to fix issues related more to "the philosopher" type issues than actual bugs. Most of the time, the patches haven't even been very well thought out or even tested, requiring the project leaders to either drain considerable time reviewing them, or most of the time just throwing them in the TODO bucket. While some patches may be small, a large and significant rewrite of something is almost always likely to show up which will be philosophically based rather than functionally based.

 

The patch overlord has been frequently known to associate with the project manager and the philosopher, introducing patches to tweak the philosophy of the software to his or her liking, and then project managing their submissions. This results in only bugging the project leads with very minor benefit to the actual project. The litmus test for differentiating between a patch contributor and a patch overlord is this: do their patches help make things run the way they were "intended" to be, or do they change the functionality to put things the way the patcher thinks they "should" be.

 

The Leech

Free software is free, so you can't leech it by means of downloading. You can, however leech free support and other resources. Asking for support alone doesn't make you a leech. After all, a healthy individual in need of support first shows their respect for the project and the time of others' by thoroughly reviewing the documentation included with the project, reading mailing list archives, and trying a few things on their own before asking. The support leech, on the other hand, is usually an inexperienced user who hasn't yet learned the value of the documentation (and therefore skimmed it or disregarded it entirely), and has gotten themself in a jam. You can't feed the leech because once you help them with a single problem, another will immediately pop up. The solutions are almost always documented, or at least obvious if they had read the documentation or used a search engine. The leech is one of the worst types of individuals as it not only uses up the resources of the developers and/or users, but a bitter leech can morph into a philosopher or a critic very easily and then provide negative press about the project (essentially becoming the next type of personality). The leech believes they are contributing to the project simply by using it, and it is therefore the community's responsibility to both support and applaud their efforts.

 

The [D]Evil Reporter

We've all seen some negative article about an open source project that just made you think, "this dude must have used it for ten minutes". There are good reporters and evil reporters. The good ones take the time to not only install and use a project, but to make it a primary tool for a few weeks at least while conversing with the user base to answer questions about any problems they're having. Good reporters somehow manage to find a positive and supportive way to write about your project, even if your project completely sucks. This is because they know that somewhere out there is an individual looking for the exact sucky project you're providing. Evil reporters, on the other hand, are the ones who drain the morale of the project's users and developers. The evil reporter will download and install the project, use it for a little while in a secondary capacity to whatever it is they're currently using (which they presuppose is better anyway or they've made the mistake of choosing the wrong tool), and then make their write-up based on the level of frustration they experienced while doing it all in a vacuum with nothing but ignorance to guide them. Evil reporters come in many forms from plain old journalist types to self-proclaimed members of a "scientific" community who want to test the project's performance. Whatever background the bad reporter comes from, you can usually identify them not only by their lack of understanding of the project (which, unfortunately, only its users can identify) but also by their seething bias. When you'read an article about an open source project (or any project for that matter), look for tell-tale signs of biased reporters - words like "poorly" and "worse", subtle references to other projects (most likely one that they are using themselves), or a hidden agenda (such as the reporter also being in a group that sponsors a competing project).

 

Dealing with the Bad Elements

Once you've identified the drains on a project's morale, it's remarkably easy to deal with them. This can be done in many ways ranging from simply ignoring them to publicly flaming and humiliating them. I've tried both, and I must say ignoring them works quite well and makes you look like less of a jackass too. Ignoring project antagonists seems to have the same effect as router black hole lists for spam. Many of them (except perhaps the project manager) seem to allow prolongued delays in their follow-ups if you simply don't reply to them. It keeps their wheels spinning and uses up their resources so they can't move onto the next topic to annoy you with. As a developer, ignoring these individuals can be very healthy for your project and actually improve the quality of the feedback you'receive.

 

If you're a user and not a developer, public or private replies are a great way to express your esteem for the project by putting an end to ignorance and stupidity. Private replies are usually good for first-time offenders. As much as people hate a flame war on a mailing list, there comes a time when it's either flame or be flamed. In my experience, publicly expressing your respect for a project by flaming critics and evil reporters can be a good thing if done in moderation and with the factual information to back up your claims. The idea is to either correct the situation privately or make it known publicly that the behavior being experienced does not in fact represent a majority of the project's user base. It also helps the developer by not making them feel obligated to get involved.

 

Helping Projects Thrive

Just as there are many ways to tear down an open source project, there are also a lot of ways to help it thrive. Flaming the morons on a mailing list will only get you so far. Contributions to projects you love are positive reinforcement and should regularly take place. This can be done in forms of financial gifts, solid and tested patches, volunteering for specific types of testing, new and fresh ideas (when they're welcome), or even just basic encouragement and spreading positive feedback about the project to others. Ideally, every zealous user should be doing all of these. If you really like a project, you should at least kick in some beer money. And if the developers don't drink beer, they'll spend it on pizza, caffeinated beverages, books, or anything else that will ultimately end up benefiting the project (and you) in the long run.

 

If you're using (or developing) a project that has already had the morale sucked out of it, dealing with the bad elements and giving more attention to (or becoming one of) the good elements is probably a good start to digging it out of the ditch it's in. Even among the projects with extremely high suckage, there are surely a few quality users who have something useful to contribute. After all, if your project is no longer interested in any user contributions, there's no point in being an open source project any longer – take it offline and save yourself the frustration. If it still has a spark of passion in it, all it takes to help restore it is a little care and feeding by the ones who care about the project - the creme de la creme of the user base.

 

So don't hesitate any longer. Go out and give your favorite projects a hug today. Developers need love too.