Aspects of Developing With, and Using, Open Source Software
It may seem a little odd to suggest that open source has some problems with standards, especially given that open standards were almost a pre-requisite for the emergence of open source. Open source was built on open standards - TCP/IP, the Internet RFCs, ISO/ANSI 'C', and a host of others. None the less, this is the case. Some of the lack of conformance issues are deliberate choice - others are a result of the way open source program development works. A lot of people are surprised when they first hear that Linux is not, in fact, fully POSIX compliant. Even when they do know, the usual assumption is that this is something that will happen over time. In fact, what seems to have happened is that a small subset of POSIX features are considered unnecessary or inappropriate and have been ignored or not implemented. I doubt that it will prove to be a problem in most cases, but you should be aware of it. Of course, the beauty of open source is that if you really need those features, then you have the code, and if you have the expertise, you can retrofit them yourself for your own use. If you want to do this, then like the Linux developers you will find POSIX a moving standard! Even more problematic, if you wish to go down the open source route, is the matter of ISO9000 series compliance. How do you document how a bunch of people you have never met, working from home in their free time, and not being paid, have developed the code you are using? It's simple - you can't. Now, as we all know, this is something we can't just ignore or avoid. Most companies are ISO9000 compliant not because they themselves chose to be, but because it was part of their customers' requirements. So how is it that your customers have painted you into a corner? A corner which prevents you from using one of, if not the, most cost effective and reliable method of producing high quality software that has yet been devised? The answer is very straightforward. Your customers have mistaken the ISO9000 documentation standards for a quality assurance standard. To digress for a moment. You may remember hearing about the Firestone factory that produced all those millions of defective tyres five or six years ago. It had a huge hoarding outside proclaiming that it was ISO9000 certified! Presumably they have the best documented process in the world for producing defective tyres... This problem isn't going to go away (customers demanding ISO9000, not defective tyres), although given the general level of dislike - perhaps hatred would be a better word - of ISO9000 by programmers, I don't doubt that many shut their eyes to its problems. The answer lies on two levels, I suspect. First, customers have to be educated to understand what they are asking for. Second, we have to develop a non-intrusive documentation process which meets the intent, even if, perhaps, not the letter of, the ISO9000 standards. I'm sure I'll get a lot of flack from certain elements of the open source community for even suggesting that we should be concerned with these issues. However, for those who have to juggle the conflicting demands of customers, schedules, and the real world, the luxury of ignoring what customers will pay for is not an option. |
If you have any questions or comments about the articles on my web site, click here to send me email. |