| |||||||||||||
|
| |||||||||||||
The Digital Software Security ActThe Digital Software Security ActPosted Aug 15, 2002 22:37 UTC (Thu) by DeletedUser816 ((unknown), #816)In reply to: The Digital Software Security Act by jamesh Parent article: The Digital Software Security Act What do people think about the quality of open source 'software for hire'? Software that's not general-purpose enough to draw all those eyeballs to the code and to attract volunteers to support might not be the best fit for open source development. The contractor develops the stuff as cheaply and quickly as possible and then moves on. Now who deals with all the bugs and security holes? Seriously, this could work if the source code were provided under proprietary license, since there would be an ongoing business for support and for sales beyond the initial sponsor. But is that what this bill has in mind? Or is 'open source' here being used as a code for 'non-monopoly'? In that case, demanding open file formats would be a more reasonable (and maybe more effective) approach. Besides, the kind of custom, vertical-market software contracted out by RFP is exactly the thing that's gonna keep 'the rest of us' gainfully employed once open source takes over all the commodity stuff. And maybe that's how it should be.
(Log in to post comments)
The Digital Software Security Act Posted Aug 16, 2002 1:23 UTC (Fri) by omg_foo (guest, #3276) [Link] "Or is 'open source' here being used as a code for 'non-monopoly'? In that case, demanding open file formats would be a more reasonable (and maybe more effective) approach"This is only part of the problem. I have much first hand experience. Say we take the authors example of a program for "the management of mineral rights". Obviously, there is no COT software for this. Say you send out an RFP, evaluate bids and hired a contractor that writes a large monolithic proprietary application in 1995 using Win 3.1 and Paradox for DOS as a back end. Say the project costs you $500,000 for the product. Now you want to upgrade the product to an new platform, you have little choice but to hire the original contractor for whatever he charges. Otherwise you waste money paying another contractor to rewrite the entire application from scratch. You can't even produce a fair and balanced RFP that multiple contractors can bid fairly. "Software that's not general-purpose enough to draw all those eyeballs to the code and to attract volunteers to support might not be the best fit for open source development. The contractor develops the stuff as cheaply and quickly as possible and then moves on. Now who deals with all the bugs and security holes?" Just because it's proprietary don't expect the developer to not cut as many corners as possible. As you stated they will "develops the stuff as cheaply and quickly as possible and then moves on" independent of the license agreements. After all this maximizes their profit and, if it's proprietary they can lock you in for improvements afterward. I've had contractors intensionally low ball bids, barely meet specifications, and rape me later to make the product functional. In fact my recent experience with specifying some OSS solutions is quite the opposite since the OSS developer has a wealth of available free tools they can apply to the product that simplifies and improves the product without affecting the
|
|
||||||||||||