Thou shalt have no other gods before the ANSI C standard 1507

some open source topic drift.

in the '60s you found lots of software being distributed for free, in many cases along with the source.

federal gov. was bearing down on big mainframe about charging for the computer but giving away the software ... as a form of bundling. so june 23rd, 1968 plus 1 was the big "unbundling" announcement ... helping to satisfy the federal gov. wishes. application software started being charged for separately from the computer hardware. kernel software continued to be free (or bundled) on the theory that the kernel was a part of being able to operate the hardware.

one of the projects i worked on as an undergraduate was reverse engineering the mainframe channel interface and building our own channel board and putting it in an interdata-3 that was programmed to emulate a mainframe telecommunication controller. this gotten written up someplace as the four of us spawning the pcm-oem-clone mainframe controller business.

later the future system project was spawned to create a brand new mainframe product offering ... radically different than the existing. one of the main driving factors behind FS project was the pcm-oem-clone controllers ... and that FS would provide a degree of integration between all the system components that would make it extremely difficult for individual pieces to be subsbreastuted by other vendors.

in the early 70s, gene amdahl gave a talk at mit auditorium about starting his new mainframe clone computer company. when asked about the VC business justificaion one of his points was that there had already been at least $100b spent on software applications by customers and even if ibm totally walked away from the existing mainframe business that day (can be construed as vieled reference to the future system project), there would be still customer demand for buying 360-370 mainframes thru at least 2000. there are various other rumors that what prompted gene to leave and start his clone computer company was the FS project ... he wanted to build a better, faster 360 and disagreed with the FS direction.

So by the time gene started shipping his clone mainframe, there was started to be some pressure to take a new look at whether to price for kernel software. You were just starting to see the leading edge of hardware technology where it was becoming significantly cheaper to design and manufactor a new computer than it was to design and develope a new operating system (kernel). Up until that time, the majority of the operating systems had been mostly proprietary to the mainframe vendors. You are now just starting to see hardware vendors producing a new computer and not wanting the expense of also doing a whole operating system from scratch.

about this time they were deciding about making my operating system resource manager a product. I got to do it almost like a one person startup; algorithms, architecture, design, develope, code, test, validate, benchmark, document, teach clbuttes, releases, maintenance, business cases, pricing, etc ... except i got to do it within a large corporate infrastructure and needing to interface with the established processes. So the resource manager got elected to be the first guinea pig for pricing kernel software. i got to spend some amount of time over six month period doing business, pricing and forcasting stuff for kernel priced software. This particular exercise resulted in policy that kernel software could be priced (analogous to application software) as long as it wasn't directly required for hardware support (aka stuff like device drivers).

Over the next several years, more and more stuff fell into the "priced" category and less stuff in the "free" category ... until the policies had changed so that the complete kernel was priced. Part of the issue was that for some components, the issue of independent pricing resulted in billing costs (given the billing processes at the time) compareable or larger than the actual revenue stream.

also, with pricing for all components, there started to be a big push for object-code-only ... no more shipping source and-or using source maintenance processes.

in this period there were studies that claimed things like there were as many lines of "kernel" code (enhancements) on the share-waterloo "tape" (distribution) as there was (lines of code) in the base kernel product shipped directly from the vendor.

so much of the '80s and 90s was object-code-only and priced software (as opposed to the earlier period of freely distributed software and source).

misc. posts related to resource manager:

and benchmarking-validation ...

some topic drift about pricing-forcasting .... there was a floor limit from the federal gov. that the price had to cover the costs ... people design & development, ongoing support, etc. Major part were upfront costs which then were amortized over the per unit sales. Given some experience and a lot of data, typically there was a "low", "medium" and "high" price selected and then a total number of unit sales forcast based on price (in part to see if there was any price elasticity in the market). Each price level times the forcasted market size had to at least cover all the (including significant upfront) costs.

there were a number of other pricing guidelines. in the mid-70s one of the reasons for killing the VAMPS (5-way smp) project

was that we could only show something like $8b total revenue over five years ... and the supposed corporat requirement for any distinct mainframe offering was minium $10b revenue over five years (if you couldn't show at least $10b revenue, it wasn't worth doing).

there was a totally different problem that showed up with the kernel software pricing policy. I was designing the VAMPS 5-way smp architecture and also including some of the design features in the resource manager code. The resource manager shipped as standard kernel product and VAMPS was end. However, it was later decided to do a more convential purely software SMP implementation. in vamps i got to have some labreastude with implementing SMP constructs in the microcode of the machine. This required some remapping when it was decided to do a purely software only kernel implementation supporting SMP.

Then it came time to ship the release with SMP support in it. It is fairly obvious that kernel multiprocessor support is directly supporting hardware features and therefor according to the policy at the time had to be "free". The problem was the design and implementation had been done buttuming a lot of the code in the resource manager, which was already shipping to customers as "priced" software. Having "free" software with a prerequisite on "priced" software was a violation of the pricing policy for kernel software. The eventual resutl was that something like 80-90 percent of the code in the resource manager was repackaged as part of the "free" kernel.

--