bits.

FREE HISTORY OF COMPUTING COMPANIES LESSON

1969: Software separates from the machine

IBM unbundling, Unix licensing, and an independent market

IBM's1969 unbundling decision changed how certain software and services were priced relative to hardware. It did not create every independent software business from nothing, and not every program suddenly became a separately priced product. Burton Grad's participant recollection provides evidence about the decision and its business context. Unix began in the same year through a different path, described by Dennis Ritchie as the evolution of an internal computing system.

Bundling makes several capabilities appear as one purchase. If hardware includes a translator, operating support, and application assistance, customers may not know the separate cost of each. An outside software vendor then competes against something apparently included at no additional price. Separate pricing can make alternatives economically visible. It also forces the supplier to define support obligations, upgrade rights, compatibility, and what counts as a separately delivered product.

Use a fictional package costing 100 units: hardware costs the supplier 60, software development allocated across customers costs 20, and service costs 10. The remaining 10 is margin under this simplified accounting. Unbundling into hardware 70, software 20, and service 10 does not change the total bill. Its immediate effect is to make substitution possible: a customer could choose different software or support if technical and contractual boundaries permit it. Transparent prices alone do not guarantee competition when replacement is incompatible.

Software has a distinctive cost structure. Creating and maintaining a program can be expensive, while making an additional copy may be comparatively cheap. But delivery is not costless: documentation, testing across configurations, security maintenance, distribution, and user support continue. A per-machine license, subscription, support contract, or source distribution allocates those costs and rights differently. Avoid assuming one model necessarily maximizes innovation or user freedom.

Unix illustrates the importance of portability and licensing together. Rewriting much of the system inC reduced dependence on one instruction set, while source access allowed institutions to study and adapt behavior. That did not make every version identical or every recipient free to redistribute without conditions. Interface differences, local modifications, hardware assumptions, and licensing terms could still divide the ecosystem.

A useful comparison separates four questions: Can the user run the program? Can they inspect and modify it? Can they redistribute the original or changed version? Can they obtain compatible support from someone else? The answers come from the actual license and implementation, not from the word “open” or the fact that source is visible. Legal rights and practical maintainability also differ: a permitted fork can still be expensive to sustain.

The historical mechanism is a boundary change. Pricing identifies a product; interfaces make it substitutable; licensing distributes decision rights; support makes it dependable. To explain an independent software market, trace all four. Treat a participant's retrospective as valuable testimony with a viewpoint, and compare it with the software artifacts and dated contracts when making stronger claims.

Reconstruction exercise

A bundled system costs 100 units. After unbundling, hardware is 70, software 20, and service 10. An independent software option costs 12 but requires 15 units of conversion once and 4 extra support units each year. Compare the first year and three-year software-plus-service costs, assuming the original annual software and service charges repeat. Identify a licensing or interface condition that could prevent the apparent substitution.

Worked solution

The original software and service cost 30 per year, or 90 over three years. The alternative costs 12+10+4=26 each year plus 15 conversion, giving 41 in year one and 93 over three years. Under these assumptions it does not recover conversion cost within three years, even though its software price is lower. A restriction on transferring data, dependence on an undocumented interface, or lack of a compatible file format could prevent substitution entirely. The calculation also assumes equal capability and reliability; if those differ, price alone does not determine value. A good comparison states recurring and one-time costs separately and checks whether the contractual and technical exit path exists.

Test the limits and transfer the idea

1. Cost calculation · allow 25 minutes

Find the real break-even volume for software

A fictional independent software vendor spends 120,000 units developing a product and 30,000 each year maintaining it. Each annual customer pays 600; distribution and support cost 150 per customer per year. For a one-year horizon, compute break-even customers. For three years with the same customers renewing each year, no churn and no discounting, recompute. Explain which assumption is most exposed if a platform update requires 90,000 of extra adaptation in year two.

Get a starting hint

Subtract per-customer variable cost first; then compare three-year contribution with all fixed costs.

Compare your reasoning with the worked solution

Annual contribution per customer is 600−150=450. Year-one fixed cost is 150,000, so break-even requires ceiling(150000/450)=334 customers. Over three years, fixed cost is 120000+3×30000=210000 and each renewing customer contributes 1350, requiring 156 customers. The extra adaptation raises fixed cost to 300000, requiring 223 customers over three years. This illustrates dependence on a platform contract, not a historical IBM price calculation. Constant renewal and support costs are also strong assumptions; a breaking update may cause churn and increase per-customer support. Grad's participant recollection documents an unbundling decision, while such customer economics need dated cost, pricing and retention records.

Check your reasoning

  • Computes contribution and rounds customer counts upward.
  • Includes development once and maintenance each year.
  • Connects interface changes to unmodeled adaptation and retention costs.

2. Trace a maintenance conflict · allow 25 minutes

Source access does not merge conflicting semantics

A shared library parses amounts as integer cents. Upstream fixes overflow by rejecting values above a stated limit. A local fork previously changed the same function to accept comma decimal separators, but accidentally catches every parse exception and returns zero. Show an input whose overflow rejection disappears if the two edits are combined carelessly. Propose tests and an interface change that preserve both requirements. Ritchie's Unix history is participant testimony about system evolution, not a proof that every source-sharing arrangement stays compatible.

Get a starting hint

A fallback value can erase the distinction between a valid zero and invalid input.

Compare your reasoning with the worked solution

Use an amount beyond the upstream maximum, with a comma separator accepted by the fork. The numeric conversion or range check raises an exception, but the fork's broad handler turns it into zero; a payment request may now appear valid with a different amount. Return a tagged result such as Success(cents) or Error(reason), and catch only specifically expected lexical errors rather than swallowing range failures. Tests should include a valid comma amount, a genuine zero, malformed punctuation, the maximum allowed value and a value one cent beyond it. Review the merged control flow, not merely whether both patches appear in the file. Permission to inspect or fork code makes repair possible but does not provide reviewers, semantic agreement or a maintained compatibility test suite.

Check your reasoning

  • Provides an overflow input path that becomes a false zero.
  • Separates valid zero, parse error and range error.
  • Tests the merged behavior rather than patch presence.

Check your understanding

A vendor lists software separately from hardware, but no alternative can read its data format. What has unbundling achieved so far?

  • Guaranteed lower customer total cost.
  • Automatic rights to modify the program.
  • Complete competition at every layer.
  • Price visibility without establishing practical substitutability.
Explanation

A price boundary needs compatible interfaces and usable rights before customers can readily substitute products.

Source is visible under a license that forbids redistribution. Which conclusion is justified?

  • Every recipient can publish a fork.
  • The implementation is therefore less secure.
  • Inspectability alone does not establish free-software or open-source rights.
  • The software is open source by definition.
Explanation

Readability, redistribution, modification, and operating quality are distinct questions.

Sources and further reading