Wandering Thoughts archives

Why organizations buy software from commercial companies

One of the things that you hear over and over again is that organizations, including universities, often prefer to buy commercial software instead of using open source (or building something themselves). Often the ostensible reason is that when you buy from a company, there is a legal entity that will provide support, or be held accountable when something doesn't work, or the like, and open source doesn't have that.

System administrators often find this laughable, peculiar, and idiotic, and cannot understand why the bureaucracy would be taken in by this sort of sales job. We've read the 'warranties' on your typical piece of commercial software and can recite how open source actually provides better quality and support at the drop of a hat.

(The specific situation where this came up here was in a discussion of disk encryption solutions for laptops. There is a strong argument that open source systems are intrinsically better than the commercial ones, yet the university is mostly or entirely looking at commercial products.)

Many years ago at a Usenix conference, I heard Dan Greer speak about computer security in Wall Street firms. One of the things he said then has stuck with me ever since: he had come to understand that the purpose of computer security measures at Wall Street firms wasn't to keep things secure, it was to keep the firm's name from ever appearing above the fold on the front page of the Wall Street Journal.

Organizations buy commercial solutions for much the same reason. Provided that they did due diligence, it is not their fault if something goes wrong. Even if the product turns out to be intrinsically flawed, well, the vendor lied to them and it's not their fault.

(I suspect that the warranties do not protect vendors who lie in a typical RFP process from legal action, because I expect that part of the resulting contract between the vendor and the university is an assertion from the vendor that their proposal satisfies the RFP requirements.)

System administrators generally find this attitude extremely irritating, because our drive is to actually solve the problem. My personal opinion is that it does us good to remember that our priorities are not necessarily the organization's priorities.

A thought about attitudes towards support requests

I would feel a lot more positive about vendor support if I didn't wind up wanting to grind my teeth most times I had to interact with it. And one of the most teeth-grinding aspects of it is the almost invariable feeling that the vendor support people are interacting with me not to solve the problem but to pawn me off with some (formulaic) answer.

One of the most glaring ways that this shows up is the general assumption by front line support people that I don't actually have a problem. It is difficult to write any specific indicator of this down, but to me it shines through in any number of ways.

(One of the ones that really irritates me is when support people don't read the existing information in the problem report, and either ask me for it again or jump to conclusions that are clearly contradicted by the available evidence.)

Now, I dare say that this happens because often the support people are right: the typical person talking to them really doesn't actually have a problem, they have a misunderstanding or pilot error or the like. But the result of treating everyone this way is that you alienate the people with actual problems (who would praise you to high heaven if you solved them without the customer having to club you into doing so).

An alternative is to start every support interaction with the assumption that the customer is seeing a real problem and you're working with them to narrow it down and solve it, and proceed from there. This will cost you some extra time when dealing with the people who don't actually have a problem, but I suspect that people will feel much better about your support because they will feel that you are respecting them right from the start.

(I think that a lot of this is as simple as phrasing your words the right way: you can still ask for all of the same information, but wrap it in phrases like 'to narrow down the source of the problem' and so on.)

Writing this has had the useful effect of making me think about how I deal with users reporting potential system problems, because this is just like my vendor support situation but with the shoe on the other foot. I think I need to take my own advice about approaching problem reports with the assumption that there's a real problem to be solved.

Why the University of Toronto can't just use Google Mail

A lot of people like Google Mail, and it's not hard to see why; they have the best webmail interface, offer lots of storage, and so on. So why not just cut to the chase and make our users happy by outsourcing our email to Google Mail?

The answer in a nutshell is that we'd like a Google Mail Appliance, but the university is not in any position to make Google Mail our email provider.

There's a bunch of pragmatic reasons why outsourcing email would be hard to set up: we'd need a contract, a service level agreement, various features (and lack of features like Google Ads), a way to manage user accounts ourselves, and so on. But none of those are the real problem, because we could overcome them with money and negotiation (assuming Google was sufficiently interested).

The real issue is that both morally and legally, the University can't hand physical control of its private and internal email over to a third party, especially a third party located in America. Apart from the moral issues, these days we actually have a specific legal requirement to keep people's personal information private and, as part of that, in our direct custody.

(Direct custody is important because it is the only way that we can assert with a straight face that we even have a chance of knowing who everyone is who has access to the data.)

No service level agreement can fix this for two reasons. First, no SLA can overrule an American court order. And second, all that an SLA would do even in theory is let us collect some amount of money from Google, and money is often a poor compensation for a privacy breach.

(You might think that the court order issue is a small bagatelle. Think again; the University has a significant number of international students, and we take the associated issues quite seriously.)

A Google Mail Appliance wouldn't have these problems; Google would just be supplying the software (and the physical machine), and the email would stay under our physical and legal custody, in our machine room.

Users don't really benefit from filing bug reports

It's practically an article of faith in the open source world that it's to your benefit to file bug reports. However, it isn't really so; with many packages, users actually derive very little practical benefits for going through the effort.

The problem is that to file a bug report, you necessarily need to have found a bug. Since people are generally not software testers, this means that you have found the bug in the process of actively trying to use the package. Unless you have found an unimportant bug, you need to solve the problem before you can go on; unless you have found a major, gaping bug, the odds of it getting fixed before you have to come up with a workaround (or have to abandon the package to get real work done) are almost always low. 'Fixed in the next release' is almost never fast enough, unless the next release is also the next day or the next week.

(This is especially the case with big, popular, important programs, which have lots of bug reports already and make new releases slowly.)

Filing good bug reports still has at least two indirect benefits:

• it may attract someone with a better workaround than yours.
• it builds up good karma with the program's developers, which can often be useful later.

Meanwhile, getting bug reports is to the benefit of the program's developers; they get part of their testing and debugging done for them, and ultimately they wind up with a better product. In fact, I believe that it is precisely the middle of the road bug reports that they benefit the most from; unimportant bugs are, well, unimportant and major bugs get stumbled over very fast anyways, while middle of the road bugs are both hard to find and important to fix in the aggregate.

Social problems are the real problems

From a blog entry on the problem of email spam:

Charging even $0.0001 per message would make spam uneconomic, but as with signing and other proposals, it seems socially infeasible.

There is a widespread attitude among computer people that it is a great pity that their beautiful solutions to difficult technical challenges are being prevented from working merely by some pesky social issues, and that the problem is solved once the technical work is done. This attitude misses the point, especially in system administration: broadly speaking, the technical challenges are the easy problems.

Social engineering is a much more difficult field than computer engineering; it is much easier to build something that works than to build something that people want to use. Solving the technical problem without considering the social ones around it is like designing a beautiful house without bothering to find out where in the world it's going to be located.

The corollary of this is that all too often computer people proceed by solving the technical problem first and then attempting to deal with the social side using their technical solution as a lever. Rather often, they are surprised when this fails to work very well, and sometimes they get rather disgruntled about it.

(Almost everyone who is convinced that better PR will get their technical solution to be more widely adopted falls into this category.)

The right way to design practical solutions to real problems is to start with the social constraints and then build a technical solution that works inside them. This does require more work and cleverness than just solving the technical problem, but that's what it takes to get real solutions to tough problems.

Thus, if charging for email is socially infeasible it is not actually a solution to the spam problem; you can only solve the spam problem by starting with what is socially feasible and working forward.

(Disclaimer: I believe that the author of the original blog entry is much more of a computing humanist than I am making him out to be here; I am, after all, using one sentence of an entry as a springboard for my own rant.)