Subject: Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Date: Thursday 22nd July 2010 15:26:44 UTC (over 7 years ago)
Bastien ROUCARIES writes ("Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling"): > For isntance the bug sytem could be made simplier for joe > simpler user, using an http interface than reportbug-ng [...] I think what's really underlying many of the complaints about the difficulty of reporting bugs in Debian is this: People think it is unfair that naive users find it difficult to report bugs in Debian and that they're not encouraged to do so. People feel that those users are being disenfranchised, or ignored. I want to tackle this head-on, because while it has some emotional appeal if you don't think about it too hard, it's criticial to understand the fallacies it's based on if you're going to try to understand how a software development effort like Debian has to work. Firstly, we need to understand the context, and why it is that socioeconomics of software development so magically allow everyone to share, for free, in hugely sophisticated high-quality systems. This works because reproducing the software has negligible cost to the people who develop it. Free software works because one person's afternoon's hacking can improve the lives of many millions of people, by a very small amount each, without the programmer having to think about each of those users. But you knew that. The corrolary is that anything which _does_ involves a per-user interaction with the developers is extremely difficult to deal with. If my afternoon's hacking session is going to be sent to ten million people, one in a thousand of whom send me a message which takes me ten seconds to deal with, that's a further 27 hours of of my time. It doesn't scale. So, what's wrong with the feeling that it's unfair not to want bug reports from certain users ? 1st fallacy: The point of bug reports is to listen to users or solve their problems. This is not the case. The point of bug reports is to help developers improve software. If a particular user's bug report is unlikely to help developers improve the software then to encourage the user to report bugs is useless, and is therefore a waste of both the developers' and the user's time. It's dishonest to the user, even. 2nd, related, fallacy: Everyone has a useful contribution to make to Debian. This is not the case. We have limited resources for communicating with, educating, and reviewing the contributions from our users. Very limited, compared to the number of users. Some users are already able or nearly able to directly improve the software or documentation, or already have the skills necessary for diagnosing and investigating problems. But for other users the small positive effect of their contribution will be far outweighed by the need to nursemaid them, undo their mistakes, etc. Once again, to encourage such users to try to "help" is a waste both of their time and ours. I'm reminded of my sister's 3-year-old child "helping" with the cooking: good for the kid's development, but not necessarily for the dish and certainly not less effort for the parent. We don't have the time to play parent to all our users and we shouldn't try. Incidentally, Ubuntu have written the contrary statement into their Code of Conduct. It may be doctrinally very encouraging to have a policy saying that everyone can make a valuable contribution, but that doesn't make it true. 3rd fallacy: Free Software is free and good because users can join and contribute to the projects that produce it. No. Free Software is Free because it allows users to modify the software _for themselves_, _downstream_, and to share their changes. It is no less free if it is produced by an opaque cabal. There is no inherent need for users to be able to participate in its production; indeed, for the reasons I've explained such participation can be counterproductive. Of course the quality of the software benefits from open and public development, and the quality of our own interactions benefit from doing things in public. I'm not suggesting that we should close down our public BTS or move everything from -devel to -private. But, users do not need to be "enfranchised" or empowered by us inviting them to become "involved". The way we empower our users is by providing them with high quality and sophisticated software which does what they want, and by making sure that they have the freedom to share and modify it. Often empowering our users means _avoiding_ encouraging them to communicate with us, because we can't do our work if they all do. Ian.