Title: Editorial

This being the April issue of C Vu, some of you will be reading it at ACCU's Spring Conference. If you are at the conference, use your time wisely: have fun, talk with your peers, attend some of the most educational sessions to be found, and do not spend too much time reading the journals. The chance to meet with so many motivated developers is rare, and this magazine will wait patiently until you have a quiet moment.

I will have to offer my apologies for absence from this year's conference. My reason is a good one. This being a publication about programming, I will say only that the reason is 5' tall and well worth moving my life halfway around the world for. By the next Spring Conference I might be able to spend a week away from her, or make a case that a vacation in the UK is too good to miss.

Look for the piece later in this issue (page 26) for some information on new annual prizes to be awarded for authors of articles published in C Vu and Overload. For the best piece written by a new author, I will add the incentive of a year's ACCU membership.

Open Source cannot provide enterprise-strength solutions, or so claim SCO, a UNIX vendor whose fortunes in recent years have suffered from competition from Linux.

It may seem that SCO skirt with contradiction when they say this - after all, if Open Source software is not so good then their own allegedly superior, commercial-strength offerings should take more of the market - but SCO have decided that Linux has only become this good because IBM broke agreements with SCO and gave Linux the features it needed.

SCO may have fewer lawyers than Big Blue, but they have more than ACCU, so I shall be careful what I say. I would not want to be in court on charges of having unlawfully acquired the ability to express opinions in an editorial without legitimate commercial backing.

Those who wish to read the complaint in SCO's own terms can see it online at http://www.sco.com/scosource/complaint3.06.03.html

Focus on the technical issues. (SCO's incorrect use of "whom" may infuriate me, but that's not the real problem.) The real problem ishttp://www.nist.gov/public_affairs/releases/n02-10.htm the lack of plausibility in SCO's claims.

Take two examples:

It stretches credibility painfully to imagine that SCO can really be so ignorance of their x86- based competition. At least, if they know this little of what does exist in the marketplace, it is hard to accept that they are authoritative on what Linux can do either now or in the past.

For another angle, http://mq.moo.net/Linux03/ScoSource-05_Story01.html is Linus Torvalds holding forth on the subject.

That SCO maybe be using this feeble lawsuit to attempt to be bought out either by IBM (to shut them up) or Microsoft (to step up the battle) is a viewpoint widely seen online. In any case, I hope that IBM will treat this with the contempt it deserves and see that SCO pay for IBM's hefty legal costs. It would also be refreshing if the legal system shows that it will not tolerate this kind of abuse, by fining SCO heavily for acting in bad faith.

If you care about freedom (in computing or in general) then look into this a little, make your own mind up, and consider it if you have dealings with SCO. Remember: SCO say that Linux is taking their business. Maybe there are reasons for that.

Much though I would love to recommend "Zen and the Art of Motorcycle Maintenance" to all C Vu readers, let me write with more focus on Software Quality Assurance. It's a magical phrase, suggesting as it does that a group separate from programmers can somehow inject Quality into a product. There is no need to take more than a sentence here to remind us that QA is only effective when it is woven right through the fabric of our development processes.

All but the worst software engineering groups recognize that Quality Assurance is an important aspect of delivering good software. There is considerable variation in how much this recognition translates into action. Many small companies do not have a separate QA role as such; they do some testing, but that is as far as it goes. Often most of the testing is done by developers - which can work, but relies not only on them being professional enough to try to do adequate testing but also on them being able to find their own errors. Finding our own errors is harder than finding those of others, for a variety of reasons, and the record of our industry is not good.

Figures I can find online in articles claiming that programmers are starving because of software piracy estimate the annual cost of software piracy worldwide at US$11-12 billion [BSA,Microsoft1999,asia-news], and there is plenty of reason to suspect that they overstate the amount of revenue actually lost quite heavily. Losses to business caused by software defects: close to US$60 billion [NIST]. And don't think the problem is just with one player; security alerts for Linux based defects are on the increase now as Linux is more widely deployed and attacked. The free software community will need to address security more actively still if it is to continue to be seen to be more secure than mainstream commercial software.

ACCU members being ethical programmers, the problems caused by our industry should concern us all. Producing the best products we can within the constraints imposed by business realities is necessary, but not sufficient. We also need to do what we can to change those constraints. At present, commercial and legal realities mean that companies are rewarded for shipping software they can call "good enough". Good enough to avoid legal liability, possibly. Let us suppose that there are as many as ten million software developers worldwide [statistic]. Then each of us is, on average, responsible for software defects leading to a loss to business of $6000 per year. That's not good enough. It will not get good enough until software companies are forced to accept responsibility for the quality of their work. Shrink-wrap and click-wrap agreements that strip away normal consumer protection are not ethical and should not be legal. Software should be fit for the purpose for which it is sold. A license to run a piece of software should not be tied to a particular piece of hardware - hardware becomes obsolete more quickly than software. Bug fixes should not come with licenses allowing the software vendor to take complete control of the machine on which you install them. Take a look at some of the license agreements you routinely ignore, and then look at what you can do to add your voice to those who are trying to move the law in the right direction. Even if you're not in the US, look at the UCITA legislation which aims to move in the wrong direction, providing legal protection to companies seeking to avoid responsibility for their own products, and look at http://linuxtoday.com/news_story.php3?ltsn=2000-02-06-001-05-NW-LF for Richard Stallman's take on it.

My final word on Quality, for now: read Robert Pirsig's book (ISBN 0553277472).