I smite thee! ...The Diary of Nod

A Failure in Product Design (Fedora 12 and PackageKit)

An example of product design failure:

On Tuesday, Fedora 12 was released. This included major changes to both PackageKit and PolicyKit; the changes to PolicyKit were incomplete and intermediary but the PackageKit changes were completed first and decided to ship as-is.

On Wednesday, a PackageKit maintainer informed a bug requester that PackageKit in Fedora allowed console users to install signed packages from Fedora repositories, without any other privilege mechanism (root password, sudo, group membership). Users countered that this ran contrary to decades of UNIX security models and was difficult to resolve.

Later that day, that information hit major attention via Slashdot and LWN.

On Thursday, the Fedora Project Leader announced that the PackageKit maintainers would revert the changes seen in Fedora 12 back to the behavior in Fedora 11.

Why (and how) is this a failure in product design?

Essentially, the persons maintaining the software didn't have any clue what their users wanted. On Wednesday and Thursday, users explained (repeatedly) what they wanted and why; the maintainers responded (repeatedly) that the users were incorrect about facts (the users were correct) and that these users were a small group and could "trivially" modify the software to the behavior they preferred. When asked for details, it was stated that "trivially" required PolicyKit scripting experience; response from users countered that this was not trivial because it was something few people had needed to use previously or would otherwise use.

This back and forth continued until the persons responsible for larger Fedora design stepped in; the result was the rollback to the behavior in Fedora 11, which was what these users had requested.

So...

• The maintainers did not know what their users wanted.
• The maintainers were incorrect in assumptions about how the software worked/was deployed.
• The maintainers made design decisions, specifically related to security, that were contrary to decades of precedence.
• When confronted on those three points, the maintainers refused to concede any ground and laid all fault on the users.

That's not how you make software that people WANT. If you're making a product for other people to use, you must listen to your users and you must be open to criticism, even when it goes against your personal preference (which is a opinion, not a matter of fact).

[Caveat: Very often, making software that is secure requires ignoring user feedback; security often makes tasks harder to accomplish or disabled entirely. However, this is the reverse of what was done with PackageKit, where users requested making a task more difficult in return for a more secure system.]

How could this have been done better?

When it became apparent that PolicyKit would not be released with the features needed to "trivially" modify PackageKit, the changes to PackageKit should have been reverted. When users asked for the changes to be reverted, citing both security and preference, maintainers should have better weighed the issues at hand and revered the changes.

Should PackageKit allow console users to install packages without any other privilege mechanism? On a single-user system, almost certainly. On a multi-user system, never. The maintainers also failed when they presumed a single-user system and created default settings for such. The better way to make this decision is to presume the system is multi-user and allow the administrator (who may be the single-user) to modify the setting during and after installation.

Labels: fedora, lwn, packagekit, policykit, product design, slashdot

posted by Lachlan @ 11:18 PM