Ok, the title is a bit exaggerated. It's better to ask "why a free-time opensource developer shouldn't maintain his own software packages in different distros and OS", but it is too long for a title. And it still doesn't mention that I judge solely from my own very personal experience.

So, I'm a long time Gentoo Linux user. I have also been writing a piece of crap called LeechCraft for almost six years now. It is done in C++/Qt and it could be used on pretty any modern Linux distro. It is known to run and work on FreeBSD and Windows (and we have more or less regularly updated packages for the latter), and it even was built on a Mac a couple of times. Being a Gentoo Linux user, I maintain a set of ebuilds for LC (they even got into the main Portage tree about a month ago, but that's a different story), and I guess I shouldn't have even taken this responsibility.

Yes, maintaining packages is a responsibility. A user comes with a report regarding broken build from Gentoo ebuilds — then, as a maintainer, I should investigate it. I should ask the user about his system. Maybe it's some well-known third-party bug. Maybe the user is another ricer and has put every flag he could find in man gcc in his $CFLAGS. Or another hundred of reasons where the problem is in the user's system, not in my ebuilds or my sources. That job is normally taken by distro maintainers, not by core developers. And that takes time, that very precious time, and nerves. Personally, I'd rather introduce another nice small feature.

And even without users, sometimes the environment changes: not so long ago the git eclass had been superseded with git-2, and I had to investigate the difference, evaluate the pitfalls and the known problems and choose, whether/when it's time to migrate to the new eclass. And that also takes time and makes me do things I don't like, I'm not into, I have no expertise in. And yes, this job is also normally done by distro maintainers, not by core developers. Personally, I'd better fix another bug.

Ok, forget Gentoo: it's for freaks without girlfriends. Let's take something more popular: say, Ubuntu. First, I should write the proper scripts for building the package. And I have no experience with Ubuntu, I have no machines running Ubuntu or any Debian flavour at all, so how should I test it? Should I spend time I could be writing code (the thing I really like) or just sleeping for installing Ubuntu to a VM and learning its quirks?

Ok, dealt with scripts somehow. But then a new version of Ubuntu comes out, and it sometimes has renamed some packages, a couple of others have been split, and another couple has unsupported/untested versions. Or built in a strange configuration. Once again, I must spend time for finding all that out and dealing with it.

Ok, no new versions of Ubuntu, just another dependency for the application. It turns out the package with the corresponding library is named differently in different Ubuntu versions, and CMake version in a couple of Ubuntu versions has a bug that makes me write kludges for detection of that library. How should I test it, given that version of CMake is long gone in my good-ol' Gentoo? (Note: I'm so boring here cause this paragraph is based on a true story.)

And for each distro, I must find out what versions of what packages are available, what packages are absent at all, and package the latter ones. Twice as much pain. Or even more, depending on how much dependencies I must pull with LC (typically two at least).

And I won't even tell a word regarding Windows builds, since I prefer to avoid profanities.

What's killing me is the people that are positioning themselves as packagers, or meta-distro-leaders, or such, but who tend to put all that beforementioned pain back on me. Asking me to register on yet another openSUSE Build Service, ShmopenSUSE Build Service. Asking to build packages by myself. Why the hell should I take this job? People maintaining distros (or meta-distros, or anything in a ε-neighbourhood) are exactly those who should deal with all those issues, just by definition of the "distro". Offloading that job back to the developers is a great mistake from the duty separation point of view. What is remaining for you, guys, after all? You'd just put all those applications in one list and proudly call yourself as a new distro/metadistro/Qt-only-distro-initiative leader? Awesome.

I can't do things knowingly bad. I either take packaging and try to do my best or stay away from it completely. And if I register on that OBS and start building packages, then I automatically take the responsibility to deal with problems that end-user could (and will) encounter. And that's not my job, it doesn't give me the pleasure that writing code (and even hunting bugs!) gives. It's yet another pressure. Given only two choices — take the packaging or abandon the project, I'd chose the latter.

I don't like packaging, I don't like dealing with distro changes, I hate dealing with end user bug reports unless it's proven they relate to my application itself and can be fixed by modifying the source. Instead of doing all the things I hate, I'd better write some code or take my guitar and learn another Silent Civilian solo. Then why the hell should I also take maintainers' job that could be done by much larger amount of people than working with LC's sources and implementing the relevant ideas? Ah, forget LC sources, that applies to any non-trivial application.

And for those who like reminding about end users and that packaging would bring more of them — well, I don't do it for users. I don't care how much users actually use my software or do they use it at all. The only thing I care about besides the pleasure of programming — the opinion of other programmers whose opinion I respect, in turn.

And yes, I may be right as a programmer, but I'm surely wrong as project leader, but not that much. As a project leader, I should find the right people: after all, it's completely possible. And this post is for those who tend to think that it's me who must do the packaging.

And yes, this one is written in English, cause I hope it'd rise my self-esteem, of course.