[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
Adrian Midgley wrote:
On Friday 19 March 2004 02:51, Simon Waters wrote: I know where a portion of the notice came from, and I was there. Score a point for part of the NHSIA actually.
I guess they aren't all bad then ;)
Me I'd go for mandating all major government software purchases must be dual supplier, in terms of support - immediately taking the "trade secret" nature out of the software supply arrangement. Not specifically a FLOSS issue - just standard supply chain management in most industries - IBM did it, that is why Intel isn't the only PC CPU supplier even if it has a dominant position in some other chip supply areas.Simon, that is a very clear idea which I have not seen in FLOSS literature previously. Would you write a bit more on it, perhaps, and the meme can get started.
As I said it isn't "FLOSS" it is standard supply chain management. A quick Google for "supply chain dual sourcing" will get you everything from an MIT thesis downwards. There is a great deal of theoretical modelling on supply chain redundancy, mathematicians love this kind of maths, it makes them feel useful. Strangely enough Google for "supply change dual sourcing software" and you get mostly links to software to help you manage physical component suppliers. I think the issue is software (and related services) is not seen as part of the supply chain. It comes once on a CD, and that's it, right? The idea you might be reliant on a steady stream of patches, or technical support, or even development, to keep government running smoothly requires either experience or a bit of thinking. (I dare say the treasury understand it after each budget, when all the logic changes). It is probably fairly obvious if you are a director at the NHSIA that your big projects are reliant on various key suppliers, in various ways. The assumption in supply chain management is that a supplier may cease to be able to supply goods. Similar risks exist in software, be they financial, contractual, or even classic disaster (Redmond struck by asteroid) - (didn't Microsoft claim to have misplaced relevant chunks of the DOS 3 source code in one legal case). Most common is loss of support, or loss of vendor, you become hugely dependent on products that the single supplier no longer is able to, or wishes, to support, inflicting painful upgrade paths. Less obvious ones are where technical support can't fix a bug in a timely fashion. It isn't a FLOSS issue as the classic enterprise solution was "Open Systems", whilst HP-UX and Solaris aren't identical, they are close enough to be fungible for most purposes. The first issue that usually arises was relational databases - as although SQL has a standards body interoperability was a big issue in the past, especially for big projects. Maintaining an application to suport multiple databases is expensive, and rarely succeeds if there aren't regular users for all the implementations. You occaisonally hear of IT projects brought to their knees by a stupid database bug (it is rare most enterprise databases used solid products with solid suppliers like Oracle or IBM). But if your banks database suddenly starts corrupting, and you can't figure out why you get some "exciting" database recovery scenarios, rarely are people in a position to say "obscure bugs in database from vendor A, let's restore the backup to vendor B's database to see if it worksaround the problem". Where big government branch out on big projects these kind of risks should be managed and reviewed. Whilst you'll never lose entirely the pain of software upgrade cycles, if we want to build truely large computer systems we need to use open standards, and interchangable components from multiple suppliers. Because with business and product lifecycles so low, the components an break a project or force it into some leacy state where key components are no longer maintained. Free software is just one way of breaking the natural monopoly that software copyright provides a supplier. It may even be the best way. You've already experience of what can go wrong with soure escrow - but there is also the other issue of getting your hands on the source, but having no developers who have any experience or knowledge of a system. So FLOSS is not a sufficient solution of itself, you need suppliers with adequate capability on a product. In some safety critical systems (space shuttle and other avionics), the deployment is multiple vendors meeting an agreed specification, with voting. Although I understand this model was considered too expensive and is falling out of favour. Here of course it is vital each implementation is as independent as possible, you woudn't want them all plaguarising the same bit of code, or even perhaps using the same published algorithmns for common mathematical tasks (unless they are well proven and free of implementation issues (Pentium bug style)). Of course sometimes the mathematicians will tell you it is better to take the risk of an unreliable single supplier who is cheaper.
Attachment:
signature.asc
Description: OpenPGP digital signature