Today I devoted an unusually large amount of time doing free user support for BuddyPress and WordPress (in IRC, over email, through some Trac tickets, and on WordPress StackExchange, the latter of which I’ve been experimenting with for the first time, and I find pretty cool). I say “unusually large” because while I used to do a lot of this sort of thing, it now falls to the bottom of my list of priorities – I do paid work, and when I’m not doing that I do free software development, and when I’m not doing that I try to get the hell away from my computer. As one of the leaders of the BuddyPress project, I usually justify this balance to myself by saying: There are lots of people who can provide user support for this software as well as I can, but there are few who can do productive development for it like I can, so my time is better spent developing. Generally, I think this is a pretty good argument. But I’m glad that days like today come along occasionally, because they remind me of some basic things about the nature of the community around a piece of free software that you can forget when your head is buried too deep in the codebase.
As an aside, I should note that I use the word ‘community’ in a measured way. The word is often overapplied, as if calling a bunch of people working on similar things “the WordPress community” or “the Digital Humanities community” or “the CUNY community” will, in a feat of performative metamorphosis (like how the Queen’s saying “I dub thee Sir Boone” would ipso facto make me a knight), bring into being the thing it purports to describe. Terminological misgivings to one side, there is an undeniable sense in which the work that we do – and by “we” here I mean specifically free software developers, though the point is quite a bit more general than that – is done in a community, or at least (more formally) a network, insofar as those who work on a common piece of free software never really work in isolation from one another. The development process that underlies these software projects depends on the existence of feedback loops, from the end user to the administrator of the installation to the community leaders to the developers themselves, in the form of bug reports, software patches, feature suggestions, support requests, blog posts, and so on.
These feedback loops are not unique to free software development; they’re not even unique to software. But in free software circles the loops are perhaps uniquely malleable, and the distinctions between user and developer uniquely permeable. Each user is a potential contributor, be it through code or advocacy. But the potential is not realized automatically. It’s obvious enough that users who hate using the software and developers whose patches are ignored will never become part of the community. More interesting is the case where a newbie approaches the community with enthusiasm and skill, but where their offerings are not nurtured and so never become real contributions.
I think this happens more than we would care to admit, and I am happy to take my share of the blame. As a developer, I become emotionally attached to the project, and as a result I sometimes interpret criticism as a personal attack. The parts of development that are least exciting – hunting down and fixing the obscure bugs that affect only a small number of users but, for those users, are ruinous – these make me defensive and sometimes angry, as they take my attention away from the more generative work I’d rather be doing. I value my time so highly that I occasionally get annoyed when someone requests some of that time to answer a “simple” question. In each instance, my attitude as a developer and leader of the project could have the effect of chilling what might otherwise have been a fruitful engagement.
Taking the time to do some “support” is the ideal way to fight these tendencies. People ask questions about the software, contribute patches, suggest improvements, etc, because they like the software and want to use it. These people are friends of the project, and should not be treated as enemies. Taking the time to work directly with users is a way of closing the feedback circuit, of sowing the seeds of future collaboration and contribution. If one out of five people recommends the software to someone else, and one out of a hundred contributes back to the software in the form of documentation or code or advocacy, that’s fruitful enough to make the engagement worthwhile.
Nice post, as always, Boone. I couldn’t agree more. Still, no matter how you slice it, providing support is a bitch.
Thanks, Zach. I agree. Support is a bitch because writing good software is hard. What I (and other developers) should always remember, though, is that while frustration about the process is totally justified, it’s *not* justified to direct that frustration toward newbies, just in virtue of the fact that they are the ones turning up and reporting the bugs. (When the newbies are also jerks, then it’s justified 😉 )
Writing good documentation is hard, too. And though you can lead an end user to an answer, you can’t make them
take 45 fucking seconds to readcomprehend it when they’d rather call you on the phone andhave you wait 15 minutes while they try to recover their fucking passwordsget a more personal response.In short, doing support is noble, often thankless, but occasionally useful work. Doing support while including your phone number is idiotic.
I’m one of the moderators of WordPress Stack Exchange (not stackoverflow.com ;)).
I noticed some time ago how many unanswered questions we have about BuddyPress. That’s very unfortunate because some of these questions are really interesting; they may even give you core developers some ideas for new or better features.
If we, the moderators, can help you to help your users we will do it. Just ask us per email or chat.
Hi Thomas – Thanks for the comment, and sorry for the SO/SE flub. Fixed in the post 🙂
There is a lot that I like about the SE model. But there are relatively few BP experts, and there are so many different places where people are asking BP questions (bp.org, wordpress.org forums, SE, WPAnswers, etc etc etc) that it becomes very hard to keep track. I like that SE has a developer focus – there’s definitely a market for that – but fracturing is still a problem.
As you have worked on the Academic Commons, have you seen faculty engage one another in a similar way?
I am not quite sure if the comparison is accurate, but it seems that developers have figured out pretty amazing ways to share information/expertise and similar academic communities could be great for any discipline.
Hi Evan. I intentionally wrote some of the above in vague terms *because* I think it applies just as equally to the way faculty engage with each other. I think about, for instance, the cultural snobbishness that often stands in the way of true interdisciplinarity, or the way in which established leaders in a given community often don’t have the time of day for “newbies” like grad students or early-career proteges.
The advantage that free software has here is that we have formal channels in place – like the bug tracker – that are both key to the way that development works and are also designed to maximize the feedback loops I describe above. These don’t really exist in the case of academia at large (or at least the humanities); the journals where scholarship is moved forward are (by design) much more tightly controlled than bug trackers and support forums.
Excellent point. This makes me wonder what cultural elements have to be in place for these channels to work. I haven’t pursued installing BuddyPress at William & Mary only because I have yet to wrap my head around the cultural part of it.
If a discipline might be a little slow to adopt some of the practices of developers, I wonder if a smaller group might be better suited. I have been several conversations recently about the idea of crowd-sourcing grading and eLearning. Now, I don’t think there is a lot of consensus about what those things mean, but I immediately thought of how the Stack Exchange network functions and how it might apply to higher ed. Thanks for the post–it leaves a lot of interesting things to think through!
Sir Boone,
Terminological misgivings aside, awesome post.
P.S. WordPress Stack Exchange rules.
Some FOSS projects develop an attitude that the project is bigger than the individual. The problem with that, is that people are less likely to make contributions unless it benefits them in some way. This could be directly, as with bug fixes or enhancements, or indirectly, as with notoriety or gaining colleagues.
As far as the software itself, I think the key is to make sure it is flexible enough to allow the small nuances required of each end-user’s project to be met in a way which does not require adding bloat to the “core.”
In my experience it often boils down to a battle over what is bloat, and what is not. Providing a clear and flexible API can go a long way to avoiding heated standoffs over enhancement requests, by removing any doubt about what is or is not possible to create as a plugin/extension.
I’m not sure I see the conflict between a project with a “bigger than the individual attitude” and direct benefit to contributors. The fact that a project has a “higher mission” (whatever that means), it seems to me, makes it *more* likely that contributors will find a way in that benefits them directly, since the presumably the software will be applicable in a wider variety of circumstances (creating more opportunities for consulting projects, for instance). But maybe I’m missing your point.
I interpret your API comments as suggesting that there is a technical component to the idea of cultivating contribution, and I totally agree – no one will contribute to a piece of software if the software is not technically set up to allow for contribution (ideally third-party contribution, like in the case of WP plugins).
My point about the attitude (when it happens) is that if someone has a problem they need solved in “core” to make the software usable at all, or more usable to them, any blow back about their “small” problem not benefiting the greater good can completely kill their desire to contribute. Hence my point about flexibility being extremely important, so that “small” issues can be worked around without adding to core, avoiding any confrontation in the first place.
The way the BuddyPress support forums are set up is a failure for users of the software. Things are not categorized enough and are not searchable. The same topics get asked trillion times over because people can’t find answers they need. I was completely turned off after the last “redesign”, made my voice vocal about it and got disdain from the lead developer. I’m sure I have not been the only one to throw my hands up over these issues.
Maybe I’ll answer some questions on stack exchange 😛
I agree that the buddypress.org support forums have problems. In their defense, I think that building a decent support environment is not obviously easy at all. Something like Stack Exchange works well because it is very focused on what you might call “canonical answers” to fairly specific technical questions. Support forums like those at bp.org need to be able to handle somewhat of a broader swath of discussion types, including open-ended conversation, showcases, etc.
But if your underlying point is that the underlying infrastructure of a support community has an effect on whether users become contributors, then I agree 100%.
Yup. Exactly.
I can say for a fact that you’ve helped me with atleast 4 questions I asked on wordpress.stackoverflow.com and I was extremely grateful for that. I think only about 10% of all questions I asked on the buddypress.org forum have received answers which has been frustrating because Im really trying to do some cool things with buddypress but struggle with advanced issues being a beginner.
Thanks for stopping by, Jared. Glad I could help you on some of your issues.
Pingback: Teleogistic / “I am not a programmer”
Pingback: Building a Place for Community: City Tech’s OpenLab