Wandering Thoughts archives

Open source projects and programs versus products

One of the things that the situation with security fixes and the Linux kernel changelogs illustrates is the difference between programs and products. With a program, what you get is the program; with a product, what you get is the program and a whole ecology of things surrounding it, ranging from documentation to backporting security fixes into older versions.

(This is why it takes a significant amount of effort to turn a program into a product, as Fred Brooks and others have noted. I credit Fred Brooks because I believe The Mythical Man-Month is where I first read about this.)

Some open source projects deliver products, so you get coordinated security fixes for old versions, planned release schedules, and so on (I would say that one example is Firefox). Other open source projects deliver programs, and leave it to other people to create products from them; I would say that these days, the Linux kernel is definitely an example of this. Understanding what you are getting from any given open source project is important, because otherwise you are asking to be disappointed (either in the lack of the niceties you expect from a product, or in a relatively plodding development schedule).

It might be nice if all open source projects delivered products, but there are two problems with this. First, turning a program into a product take extra work, which means that other areas of the project are getting less work; if you demand a product, you are implicitly demanding that the project move slower. Second, much of the work of turning a program into a product is tedious and thankless, which means that it is very hard to find volunteers to do it; at the extreme, if you demand products instead of programs, you get nothing.

My intuition is that the larger, more complex, and faster moving your program is, the more likely it is that you are going to deliver a program and not a product; you simply won't have the resources (in both time and interested people) to do anything else. (In light of this I am impressed with Firefox's ability to deliver an actual product. I suspect that Firefox is not quite as complex and fast moving as the kernel, but it is still pretty big.)

We don't really control user desktop machines

Here is something important: regardless of what people in IT like to think, we don't really control user desktop machines if the users feel strongly about it. We can try to dictate hardware and software standards and we can often get away with it for a while, but in the end if the users want something badly enough they are going to win.

This has really been the case for quite a while, but it is especially acute these days with desktops; the ultimate issue is that the users just have too many alternatives to whatever you supply, and thus too many ways around your limits. At the extreme, not only is perfectly capable desktop hardware available for a price that is almost within reach of the petty cash budget but many people have personal laptops that they can bring in and work from, basically ignoring your desktop.

Yes, you can start making policies and enacting technical barriers to keep these 'unapproved' machines off the network. That's the path to a scorched wasteland, where everything that IT provides is stacked up in a corner with a dustcloth thrown over it and the actual work all gets done entirely off your pristine network in whatever anarchic environment the users have built.

What you select for when you make something harder

There is a general belief that when you make it harder for people to do something, you will get better results; better bug reports, better blog comments, and so on. This is simplistic and, I am convinced, false in practice.

The basic principle is simple: when you make things harder, you do not select for quality; you select for people who care enough.

(Well, not entirely; you also select for people with lots of spare time and for people who don't realize how much effort they're expending.)

Only sometimes will the people who care enough also be the people who will give you the sort of better results that you want, because there are all sorts of reasons that people wind up caring enough about something. (Conversely, not everyone who will give you quality results will care enough to do the extra work, although this may be considered acceptable.)

This leads to a corollary: if you are stuck with undesirable people, making things harder will not necessarily make them go away. Instead you may refine your crowd of undesirable people down to just the most fanatical (and thus annoying) ones, because those are the ones that care enough to stick around despite the all the annoyance you are putting them through. And in the process you may have lost most everyone else, because as a general rule the fanatics will care more than the regular people and thus the regular people will drop out sooner.

(See, for example, the relentless evolution of CAPTCHAs under the pressure of spammers into completely unreadable things that only spammers will bother to decode.)

Why it matters what users like

In theory, you can force a lot of things down the throats of users, whether or not they like it; you provide what you provide, and the users have to live with it. (I will assume that the 'you' here includes management.)

In practice, this is not so, and you ultimately do need the support of your users to survive and prosper. No system can last unless the users actually like it and it does what they want. If users dislike your system or are just indifferent to it, you either become irrelevant, ignored in a corner, or the users consider you damage and route around you (to steal from a famous quote).

In the long run it does no good to 'force' people to use your system or to starve them of alternatives (for example, by trying to deny them funding to buy them). Either the users win in the end, one way or another, or you destroy everything worthwhile in the process of fighting the battle and wind up presiding over little more than a scorched wasteland. (My impression is that scorched wastelands are surprisingly popular, and I will admit that in retrospect I have been involved in one or two in my time.)

(Any time you are trying to tell users that they don't actually want what they're asking you for and they certainly can't have it anyways, watch out. There may be a wasteland in your future.)

This is ultimately why things like user exposure to Ubuntu matter. Users generally wind up liking what they are exposed to (assuming that it is decent to start with), and whether you like it or not their likes wind up driving your technology.

How to tell when your bug reporting system is at its limits

There reaches a certain point in the life of many projects, especially open source projects, when your bug reporting system just doesn't work any more. By 'doesn't work' I don't mean that your systems fall over and the software stops working; I mean that the system stops doing any good and instead becomes the place where bug reports go to die. (Actual important bugs get reported and often tracked by different channels.)

So how can you tell if you've reached this point? Speaking from an outside perspective, I have a suggestion on the boundaries of when a bug reporting system is still useful:

• when you are getting more bug reports than you can fix, your bug reporting system is pretty much done for. Although you can still extract some use from it, you should start thinking about what's next.

• when you are getting more bug reports than you can even sort and triage, your bug reporting system is dead. Give up entirely.

If you are in the second situation, ideally you'll remove your bug reporting system entirely so that innocent people are not deluded into spending their time filing bug reports that no one is going to read. If you keep your bug reporting system running anyways merely to divert people's attention so that they don't bug the developers, well, I will just say that I would rather that you were honest about the whole situation.

To be fair, I think that a lot of projects that wind up in the second situation keep their bug reporting systems running out of inertia and the idea that they have to do something to enable bug reports, instead of any deliberate cynicism. The Sam Ruby entry that started me thinking about this issue suggests that projects should take a different view, and as you might have guessed, I agree with him.