I continue to grapple with the concept of how to treat users of Open Source projects. Should you be cruel, or kind?
It sounds like a dumb question - rude hackers who rip users apart for daring to ask a question in a not perfect way are just arseholes who need to get off their high horse. Right?
I’m not convinced. And I’m someone who usually over worries about being polite. Mostly because the voice inside my head is, I suspect, the kind of stormtrooper who after the Death Star blows up for the second time, will be found out of uniform at the Rebel party selling little burgers of ‘forest meat - mind the blaster marks on the fur’.
Anyway, the question about whether you are cruel or kind is linked in to the required resource on your project.
A project that is not widely successful yet (notice how my polite overmind changed ‘a useless project’ into something rosy and smelling of fluffy bunnies) needs, first and foremost, users. Preferably users who ask questions and raise bug reports. This project needs to be nice to their users, pamper them, get bugfixes back out quickly, grow in user base and bug reports.
The alternative is a successful project, a project that has spread like a virus through the grass roots and up the trees of corporate computing to the point where even the CEO of the company could guess that the company might use that product. In that case, the constrained resource is not users, they’re falling out of the trees. Instead the project needs contributors; committers; leaders. Being kind is not the classic way to create these wee beasties, instead you have to put your BOFH hats on, roll up your sleeves to expose your clue-sticks and get ego bashing. It’s the classic mentoring method, usually involving reducing your recruits down to their constituent parts and then building them up again. It works. Casualties are expected.
There are two paths to choose, and I’ve described the happy direction in both. Let’s cover the “Oh No” direction now.
If you are a pathetic little piddly project with crap all hope of going anywhere (help, where’s the polite censor??), and you treat your users like, well, little fluffy lambs - they’re going to remain as little fluffy lambs. As little fluffy lambs are wont to do, they’ll go off engaging in grass root discussions and your project will spread like wildfire. Or maybe like a small spark in a refuse tip, quick sometimes, but other times it gets to the tyres and smoulders and smells for months. Point being - your lambs never step up.
If you are a well known project, full of arseholes who think they’re God’s gift to the ego; and you treat your users like, well, goats in training - you’re going to have a high attrition. You don’t really care as long as you get some goats, but for many of us, especially those of us in baabaa suits, there’s got to be a catch. I continue to believe that there is - that the stink travels and your well known project’s products will start to get a bad name, losing you users. If you look at the way it seems to work - the users you seem to lose are noticeably the potential goats. I’m not sure why - maybe it’s just because no one notices users leaving, but when contributors start leaping ship into a competitive product, that’s noticeable.
This may all sound rather familiar - I refer you to the goats/sheep matrix. Thinking of sheep as ‘potential user’ and goats as ‘potential contributor’ might be a better way to view it.
The question is…. how to balance the two?
There’s an easy answer with regards to mailing lists. Treat your users@ list like users, and your developer list like trainee developers. Phrased like that, it sounds pretty damn obvious.
The harder one seems to be how to handle your issue tracker. I’ve seen users bludgeoned to death on these while I was monitoring a lot of them in my SourceLabs days, and it’s obvious there’s a problem. I think the answer is still staring us in th face.
- Treat the bug reports as users. Be kind to the fluffy user. You want more bug reports. Fix those bugs.
- Treat enhancements and new features as noise. Ask for a patch.
- Once you have a patch, pull out that clue stick and pound away. These users are self selecting themselves as potential contributors and if you lose them as users while trying to pound them into contributors, then it’s not a huge loss to your user list.
- Keep a good eye out for contributors who are experienced at contributing already - treating these people like newbies will backfire. Expect more from them and nudge them when they are not getting your community.