On Wednesday, September 25, 2002, at 01:09 PM, Shaun Savage wrote: > If two companies make "chairs" and if one company chair is softer, > last longer, and cost the same, the other company will need to make > better chairs in order to sell chairs. The niche example is an > exception not the rule. If the first company sells their chairs from a garage and the second company sells them through Costco, the first company is losing. In other words technical advantages (better-made chair) can and frequently are overcome by marketing advantages (better distribution, advertising, sales). How many articles of handmade clothing do you own? >>> 1A- "shorter development time reduces software quality" >> Does not follow. Good design can lead to shorter development and >> better software quality. And this does not appear to have anything to >> do with monopolies. > Correct it does not relate to monopolies, but on average it is true. > When a project reaches a large size, the good design will only help so > much. On average, if competition forces the release of a project > before it is ready, the software quality will be reduced. The more > "man years" put into software the better the software ON AVERAGE. Your assertion isn't supported by the evidence of fifty years of software development. For examples refer to "The Mythical Man-Month" by Fred Brooks, "Peopleware" by Tom DeMarco, "Rapid Development" by Steve McConnell, and any number of other books. Given the orders of magnitude measured differences in programmer productivity, major variations in schedule pressures from one organization to the next, and many other factors that influence development time, you simply can't use development time to say anything about software quality, assuming we can even agree on what that means and how to measure it (we'd be the first). Even if what you say is true, the developers taking longer lose a big advantage: having anything to sell against their faster competitors. Being first to market is a huge advantage, sometimes a big enough advantage to effectively kill competitors who may have superior products. In what other discipline would you conclude that taking longer to finish produced a superior product? And what does "average" mean when applied to measurements of quality? > I keep hearing about companies giving away IP if they move to open > source. I keep hearing about what is the motivation is write open > source software? > If the state pays for a custom software, does not the state owns that > custom software? If companies know they are working for money writing > open source software, then there should be no problem. When you get > paid for programming, does not the payor own what you programmed? Only if the contract is negotiated that way. In most states the paying customer owns the software by default UNLESS a contract makes other arrangements. But the software may have value (actual or imagined) beyond the initial customer. A client may pay me to develop an e-commerce engine. After defining requirements I may conclude that I can resell the e-commerce engine to other clients, so I negotiate with my customer to retain rights to resell the engine, and in return I give them a reduced price for development. It happens all the time. > OK, BUT all protocols and file formats should be OPEN and published. > By requiring open protocols and file formats, that allows prevents > monopoly on software and locking user into poor software. When it comes to protocols or formats in the security realm I agree; secret protocols are no basis for security. In other areas I'm not sure. Industries have tended to develop common protocols and file formats among themselves because it makes business sense, without open source advocates telling them to. Protocols and file formats are much more open than you may think. From the format of magnetic strips on credit cards, to UPC bar codes, to how bills of lading move between trucking companies, the protocols and formats are frequently standardized by the ISO and publicly available (though of limited interest). That was happening back in the '60s, before more most open source geeks were born, because the government started forcing contractors to follow the same standards. Have you ever heard of the programming language Ada? As for APIs, one could argue that APIs are part of the source code and may reveal proprietary information. Personally I don't really care whether Microsoft publishes the "secret" Windows APIs or not, though I do see how it gives them an advantage over their own developers. Those secret APIs only give them an advantage in the realm of Windows software, though, not in the software market at large. Office doesn't dominate because it is better than the competitors (though I think it probably is), and it doesn't dominate because MS kept the APIs secret. It dominates because MS has always been better at strong-arming their distribution channels (PC manufacturers and retailers) into bundling their software and only their software. The advantage comes from marketing and management savvy, not from technical secrets. > NOw the open source software needs to open to the public. This allows > new people/companies to learn the software and compete in the bidding > process for maintaince. If the software is only open to the state > then the same old people will keep bidding and winning the contracts. For government software I agree that we need some way to fairly open up bidding for maintenance and support. And we need some way to protect the public interest in case the software vendor goes belly up. You need to accept, however, that "the same old people" get the contracts more often because of who they golf with or who they went to school with, not because of any technical advantage. Life's not fair. -- Greg Jorgensen PDXperts LLC, Portland, Oregon, USA
This archive was generated by hypermail 2b30 : Wed Sep 25 2002 - 00:58:54 PDT