edja...@phoenixsoftware.com (Ed Jaffe) writes: > So-called "free" software is rarely, if ever, functionally competitive > with priced offerings. > > For example, I know from experience that demonstrating real > productivity gains derived from (E)JES functional superiority over the > "free" TSO/E OUTPUT command (i.e., ISPF Outlist aka 3.8) is trivially > easy. > > I suspect comparisons of z/XDC, TDF, etc. full-screen debuggers vs > TSO/E TEST are equally compelling. > > Perhaps more important than functionality to a small shop is the issue > of intended user base size. It's hard to justify a product that will > be utilized by only two or three users, no matter how functionally > superior it is, unless the purveyors of the product offer a low, per > seat pricing model - which can be somewhat uncommon for System z > software.
note that in the "OCO-wars" from the 80s ... the issue of free software and availability of software source was treated as two separate issues. 23Jun1969 unbundling, started charging for (application) software, but made the case that kernel software should still be free. This changed in last half of 70s, with the rise of clone processors (largely enabled by the lack of IBM mainframe offerings during the Future System period) and decision to also starting to charge for kernel software. the OCO-wars in the 80s was there was enormous benefit to source being readily available ... including a huge amount of innovation is enabled with the availability of source (line about if you aren't innovating, you are dieing ... albeit possibly slowly). the recent articles about near total dominance of Linux in supercomputers and large cloud megadatacenters can confuse the two issues: source/innovation and free. An enormous amount of innovation was required for current supercomputers and cloud megadatacenters (which have significant overlap in technologies and both required readily available source, there are even articles about research institutions using credit card to spin up ondemand significant supercomputers from large cloud providers). The source & free issues are confused in this scenario, since once significant innovation has been demonstrated, the proprietary, closed products can copy the innovation ... but faced with providing sufficient added value to compete with something that is also free. IBM was at time notorious of using FUD (as alternative to added value) as countermeasure. This could be seen in the traditional MVS & communication group when the human factors studies were showing cost/benefit of .25sec response for interactive computing (neither MVS system nor 3274/3278 hardware were even close to .25sec response ballpark) also as previously noted, parts of IBM had grossly bloated infrastructures that distorted pricing http://en.wikipedia.org/wiki/The_Mythical_Man-Month earlier posts in preceeding thread: http://www.garlic.com/~lynn/2014h.html#99 TSO Test does not support 65-bit debugging? http://www.garlic.com/~lynn/2014h.html#103 TSO Test does not support 65-bit debugging? http://www.garlic.com/~lynn/2014h.html#105 TSO Test does not support 65-bit debugging? http://www.garlic.com/~lynn/2014h.html#106 TSO Test does not support 65-bit debugging? http://www.garlic.com/~lynn/2014h.html#107 CMS Editors was TSO Test does not support 65-bit debugging? -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
