Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
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.
Reply to: