Russell Beattie writes a short lament on the realities of releasing code as open source.

The executive summary: it can turn into a real hassle. People ask you to fix things, you don’t have time, or don’t want to, or don’t think it ought to be done, or…

Name it. Honestly, it’s not limited to open source. Anyone who gets involved in a project or runs something that other people use runs into this. We dealt with it back when the Backbone Cabal was trying to figure out how to run USENET. Laurie and I deal with it with the mailing list systems and other sites we manage. It’s one of the reasons I mothballed hockeyfanz.com, and why it hasn’t come back to life yet.

Russell Beattie writes a short lament on the realities of releasing code as open source.

The executive summary: it can turn into a real hassle. People ask you to fix things, you don’t have time, or don’t want to, or don’t think it ought to be done, or…

Name it. Honestly, it’s not limited to open source. Anyone who gets involved in a project or runs something that other people use runs into this. We dealt with it back when the Backbone Cabal was trying to figure out how to run USENET. Laurie and I deal with it with the mailing list systems and other sites we manage. It’s one of the reasons I mothballed hockeyfanz.com, and why it hasn’t come back to life yet.

People tend to forget that the people doing all of this have lives, and those lives aren’t dedicated to waiting around for people to come up and say “hey! I wish your thingie did this and that!” — and most folks are actually pretty reasonable about it, to be honest. but there’s a small subset that seems to have taken “the customer is always right” completely to heart, and now honestly believe that really means “you shall give the customer anything they ask for, now, without questions”.

Those people get upset when I say “maybe that’s how your site will run when you build it, but not here…” as if their asking for something means I have no say in the matter. A few folks go so far as to think we’re somehow slaves to them, and get upset when we refuse to accept that.

And that gets really frustrating. Sometimes it gets frustrating when people ahve good ideas, but not ones you want to implement. Or wish you could, but know you’ll never have time — and yet they won’t implement it, either. (It’s fun, at times, to watch the reaction to people on the various open source lists making enhancement request when the reply is “great idea. start typing, submit a patch”. Some do. Some — don’t. Some — don’t, very loudly.

What we’re really talking about is — tech support. Which in real companies is generally a separate group of people, dedicated to that task. and those folks (I did it for about a decade, because I love the customer focus) are generally overworked, underpaid, not given the resources or access they need, and somehow find a way to mostly make it work anyway, all the while being one of the more visible faces of the company to the customer. Bad tech support can kill you in oh so many ways, so fast — but it’s usually one of the first to see budget cuts (or never get the budget in the first place). I’ve never understood that attitude, but I think it comes down to companies not really understanding what tech support is for a company, and instead seeing it as a way to use cheaper talent to keep the engineers focused on project work. (personally, I think ALL engineers ought to have tos pend time talking to customers who actually are trying to use what they built, but many engineers can’t handle real people, and can’t deal with finding out that what they wrote is crap, or merely incomprehensible to anyone but the author. That’s why engineers tend to hate tech support folks — because it’s tech support’s job to make sure everyone knows who isn’t wearing any clothes, and that creates conflict. So support ends up, politically, somewhere just above tech writers in the political scheme of things in companies. Which explains why manuals generally suck, too…)

hackers (and admins) need to understand that anything thy put out there for people to use — will get used. If you don’t want to manage or maintain it, you probably don’t want to put it out there. (with software, put it out public domain instead of open source, and make it clear they’re welcome to it, but don’t expect you to do anything with it. On a couple of projects I did a while back, that’s exactly what I did, and — others took up where I left off and made it even better…)

and users? Please: the relatively few percent of the net building stuff that the majority of you use don’t like being treated like your slaves. Most of us, in fact, want little more than an occasional “thank you”, or at least understanding when we don’t respond to email within 30 minutes (when I’m putting in 50-60 hour weeks, a guaranteed way to PISS ME OFF is send me email asking about your list subscriptions here at home, and then start complaining that I haven’t answered you yet. I get frustrated enough when I’m 200 pieces of email behind that I don’t need hourly reminders I’m not caught up yet…….). We’re all in this together, at least in theory, but if you piss off the builders and they stop building, there won’t be any fun toys to play with any more…