Andrew Plato wrote: >>It's about giving the State choice in who to outsource >>support to. No, I >>don't expect the State IT staffers to actually do very much with the >>source other than turn it around to whoever won the support contract >>this year. >> >> >And who would that be? Now you're talking about the state having to engage >not only suppliers, but also support organizations. And most support >groups don't have the programming prowess to take on the complexity >of re-engineering source code. > I'm talking about the State having the right to kick a supplier out and swich to some other supplier, without having to burn a half-finished project to the ground in the process. Similarly, I'm talking about the State being able to decide that provider X built a good product, but provides crappy support, so they would like to hire (say) Anitian :) to support it. As Alan said, and it's what I was thinking about when I proposed this a few weeks back, this would have prevented a large part of the Portland Water works software problems. >>And the quality of the support you can provide suffers as a result of >>not having the code. The support you can offer for closed-source >>products amounts to a really good user's manual: you know how to >>configure & use the software really well, and thus can help with >>configuration & usage problems. This is a very valuable >>service, hence the thriving industry. >> >> >That's what customer's want. They want and need people who are "a >really good user's manual." This is particularly relevant when you >consider that most user manuals are utter crap. I know - I wrote some >of them. :-) > Sure, I didn't say that customers don't want the service you offer. I'm just saying that you could offer higher levels of service (at higher prices :) if you had access to the source. >Organization aren't looking for source code, they're looking for >capability. Its the manufacturer's problem to make sure the >products work correctly. And where the manufacturer can't do it >VARs and consultants fill in the gaps. > Here we seem to agree. But my point is that if VARs have source, then they can offer greater capability. >Moreover, very few (if any) VARs have the software engineering capabilities >to modify, test, and deploy customized version of software. And in some cases >customers don't even WANT that. They WANT the "blessed" version from the >manufacturer. > In an industry where source code availability is rare, it does not surprise me that ability to make use of source code is also rare. >I think the State should want practicality, simplicity, and sustainability >combined with security. > ... and motherhood and apple pie. Sure. We're talking about ways to achieve these lovely attributes. >Source code would open the door to excessive "tinkering" which is exactly >what kills large IT shops. > That is highly context dependent. I suspect that you are right, for the kind of commodity products that Anitian supports. However, when the application is fully custom, developed from the ground up for the Oregong Department of FooBar, then it is not "tinkering" to implement necessary changes when the system does not meet the State's needs. With proprietary systems, the State is at the mercy of the initial vendor to get it fixed. With Open Source licensing of such systems, the State can entertain competitive bids to implement an enhancement or a fix. >Maybe a good analogy is due: > Maybe not: because an analogy is often like a goldfish, having nothing what so ever in common with the subject at hand :) >>Because screwing around with binary patches is an expensive >>waste of time :) >> >> >Okay, so let me see if I understand this: > >Installing a point and click binary patch wastes more time than >cracking open the source code, learning how the product was >coded, coding a change, recompiling, testing, and implementing. > Sorry, terminology problem. By "binary patch", I meant "reverse engineering some binary code to figure out how to patch it, because the vendor won't", not "vendor supplied patch to a system." Vendor supplied patches are not really binary patches: they just wholesale replace files with new ones. They are developed using the source code. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX http://wirex.com/~crispin/ Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html
This archive was generated by hypermail 2b30 : Tue Sep 24 2002 - 17:29:03 PDT