Preventing developer burnout: it is OK for your open source project not to have a public bug tracker

TLDR: you don’t owe your users, they owe you. A public bug tracker is neither mandatory nor the only way to accept bug reports. It is just the easiest way to meet entitled users on their terms and to get coerced into working for free.

(A follow up to No, “Open Source” does not mean “free support”)

So, conventional wisdom these days apparently has it that all open source projects must, in the very least, offer a public issue tracker, where users may report bugs, so project maintainers can fix them. Fixing bugs is not their job (they don’t get paid for it), but an ethical obligation.

Oh boy. A gift becoming an ethical obligation… how did we get there?

Conspiracy theory time

I imagine, the problem of deliberately ignoring the license agreement (in particular the AS IS clause, found in every OSI approved license) might have started about one and a half decades ago (probably earlier), when one of the GitHub (or SourceForge) founders said something along the lines of:

Look, I have no idea either how we could convince companies to pay us for hosting their private source code. Every manager with half a brain will immediately conclude that keeping it in-house is the cheaper, easier and safer solution. So how about we make it our business model to cater to open source projects, instead? Just burn venture capital on growth till we are big enough that someone will buy us out?

Now, I don’t know if it was ever said exactly like that, but assuming it was. What would it have taken then for the open source community to get hooked on this service?

Flashback to 1999 (before SourceForge)

Imagine an Internet before web 2.0, social media and big data silos. You wanted to publish something? You did it yourself - from scratch. You hand build the website. You paid for your domain, you paid for the hardware, you paid for the traffic. Back then, being altruistic had a heavy price tag attached to it, so a lot of open source software was simply dumped on university FTP servers instead. You just had to know a guy.

It was also the era of dial-up internet, which forced people to heavily rely on store and forward technologies. Email and mailinglists were the default means of communication during that time. When users had a problem, question or contribution, regarding a software package, they either mailed the author or, in case of larger projects, joined the mailinglist. Naturally, this could cause friction: cluttered grouplists, resulting in exploding inboxes (because everyone felt a need to publicly educate the new guy about the house rules) and software authors quickly finding themselves pushed towards doing secretary chores.

The easiest solution was often to simply split into a developer and a user list. Make one invite only and ignore the other as best as possible, which brings us back to the problem, Github and Sourceforge set out to solve…

Fastforward to 2008 (let there be GitHub)

Welcome to a new age of productivity!

Your software package is now called a project. You are also no longer just an author, but a software developer! Everything sounds much more professional these days, doesn’t it (do take a moment to ponder the semantics, those new terms hold)? Publishing has become free of charge and you can finally reclaim your inbox by telling users to post their issues on GitHub instead of directly contacting you. It is a major improvement over the situation, ten years ago, except:

• Your bugreports are now embarrassingly public and highly visible.
• Most of them are still rubbish, lacking even the most basic information to reproduce the problem. Unsurprisingly, people don’t just magically get better at writing these things, just because you forced them to sign up with GitHub. You just switched from email client to browser based, but the process of remote debugging stayed the same. Only now you also have to clean up after your users because they vanish without closing their ticket, once the problem is solved (or when they silently give up).
• The bug tracker, you supposedly must have, because it is your ethical obligation to fix bugs, is officially called an issue tracker. Did you notice how that sneakily broadened the scope? In addition to bug reports, you also get feature requests and, of course, support questions (including the kind that could be answered by reading the docs). You are under no obligation to process any of them (your ethical obligation is to fix bugs, remember?), but if you do nothing, they’ll clog things up.
• Not handling issues, results in people asking again and others posting “me too” comments. So now there’s also pressure to do something. And, oh shit, there’s even that accompanying activity tracker widget, showing that you haven’t done any coding this month. It used to give you approval and satisfaction in those busy early days, but now it is punishing you for being lazy?! Better start working on those tickets soon! If you postpone things any longer, your project will look abandoned!
• Of course, not everyone is civil. Remember that asshole from yesterday? The one who opened an extra issue just to call you a lazy bastard, which you immediately deleted? Guess what? He’s back! More furious than ever and hell bent on having a discussion about free speech. He also brought buddies. Congratulation, your issue tracker just turned into a forum, you have been promoted to community manager and you are now very engaged. Do whatever you think is right, it will turn out to be wrong and reflect negatively on your public image. Aren’t you just glad, you got that free hosting right next to a drama magnet?
• Maybe the thing you need to deal with hate speech and trolls is a code of cuntduct? Hold that thought, you just hit the jackpot! Meet your endboss: a social justice warrior on a mission, who just handed in a giant patch, refactoring half of the code base because phe didn’t like the master/slave terminology, you used. Of course, the patchcode is shit, but it is morally without question and a categorical imperative to apply (you were socially irresponsible for using such language in the first place). Who cares if it breaks stuff in twenty odd places? You got a public bugtracker, right?

Any of that sound familiar? Let’s sit back for a moment to think about what happened there.

Mind reset

The crucial point of all OSI approved open source licenses, and likely the reason why you picked one, is the “no warranty” clause: you provide the work for free. If the user breaks it, he gets to keep both pieces. That’s it. You are under no obligation to fix anything, add features or even listen to his requests. Some very entitled and silver tongued people may think otherwise, that’s their opinion, they have the right to express it and you have the right to ignore them. Legally, they don’t have a leg to stand on and ethically you have nothing to gain from being their hero (which is just an euphemism for “peon” anyway).

Anything a user wants in addition to the source code is a job and you can ask payment for that (selling support was always the idea for funding open source projects. The idea of having to have a public bug tracker robbed us of even that).

The thing which happened, when you opened your bug tracker to the public, is that you put yourself on a stage and thus accidentally gave all those entitled users leverage to guilt trip/shame/bully you into doing the one thing, the open source license was suppose to protect you against: gifting yourself away into slavery.

So, here’s the sixty-four-thousand dollar question: What is having a public issue tracker to you? An asset, helping you and your team to coordinate and flourish or did you really just allow to get yourself talked over into adopting a cleverly designed engagement mechanism for platform growth that benefits everyone else by nudging you to handle unpaid jobs, you did not sign up for and were never obligated to do in the first place?