The History of Tech History: Why This Category Exists on This Blog

Every other category on this blog centers on a system or operational discipline: how FreeBSD jails isolate processes, why Haiku schedules work the way it does, or how a Kubernetes controller responds to changing state. Tech History asks a different class of question. It examines the products, organizations, standards, court decisions, failures, and market transitions that explain why those systems exist in their present form.

The goal is not nostalgia and not a complete encyclopedia. It is evidence-first reconstruction. A launch date should come from the announcement or a contemporaneous record. A lawsuit should be described from complaints, opinions, and settlements rather than a winner-and-loser slogan. A famous invention story should distinguish a preserved artifact from a later attribution. When sources disagree or cannot establish a popular detail, the uncertainty belongs in the article.

What belongs in Tech History

The category covers bounded historical subjects with enough evidence to answer what happened, when, who participated, and what changed. A news post may reconstruct one announcement, release, acquisition, or ruling. A deep dive follows a technology or institution across several stages. A fix post audits a specific misconception whose corrected version changes the reader’s understanding.

The subject can be technical without becoming a how-to. The Ethernet history explains why collision detection disappeared from ordinary switched links; it does not teach switch configuration. The IBM PC history separates published interfaces from copyrighted BIOS code; it does not recommend a current motherboard. Architecture appears when it explains the historical consequence.

Video games belong when their history intersects computing, semiconductors, distribution, preservation, or law. The 1983 market crash was not merely a list of unpopular cartridges. It involved retail inventory, licensing, consumer confidence, and platform control. Technical emulation instructions remain in the dedicated retro-gaming category; the industry event belongs here.

A date is a claim, not decoration

Technology timelines are full of dates that refer to different events. A product can be demonstrated, announced, shipped to selected customers, released generally, and discontinued on separate days. An acquisition can be announced months before it closes. A court can issue an order before judgment becomes final. Source code can be promised in January and actually published in March.

An article must name the event attached to its date. The World Wide Web announcement treats August 6, 1991 as Tim Berners-Lee’s public Usenet summary, not as a magical instant in which the internet or hypertext was invented. The AOL–Netscape deal separates the November 1998 agreement from the 1999 closing and from later changes in the stock transaction’s market value.

Precision also prevents anniversary mythology. A convenient commemorative date may be useful, but it should not overwrite a development process that lasted months or years. “First” requires a defined criterion: first prototype, first commercial product, first single-chip implementation, or first widely deployed system can identify different candidates.

Primary sources establish different things

This category prefers original announcements, specifications, source code, filings, transcripts, artifacts, and court records. Primary does not mean infallible. A company press release reliably establishes what the company announced and how it framed the event; it does not independently prove every marketing claim. A complaint shows what a plaintiff alleged, not what a court found. A standards document defines required behavior, not whether every product interoperated.

The source has to match the sentence. SEC filings are strong evidence for transaction terms and disclosed risks. The RFC Editor preserves protocol documents. Court opinions establish procedural history and holdings. Museums can document an object’s provenance and physical features. Archived corporate pages preserve contemporaneous language when the original site is gone.

Later institutional histories help connect those records, but retrospective accounts are checked for compressed chronology and corporate self-credit. Good sourcing is not a contest to place the largest number of links at the bottom. It is a chain in which each consequential claim can be traced to evidence suited to prove it.

Secondary sources still have a role

Primary records often assume their reader already understands the context. A filing may define an exchange ratio without explaining why a browser company mattered. An engineering paper may describe a protocol without showing its later market effect. Responsible scholarship, oral histories, and museum interpretation can connect those fragments and identify disputes.

The hierarchy is therefore not “primary good, secondary bad.” It is claim, evidence, corroboration. A contemporary source can repeat an error. A later historian can discover a better archive. When a secondary source supplies a contested detail, the article should either find the underlying evidence or describe the attribution as an interpretation rather than settled fact.

Wikipedia is useful for discovering names, dates, and references, but it is not the last evidentiary stop for a central claim. Search-result snippets are leads, not citations. Repetition across unsourced articles does not create independent confirmation when they all derive from the same anecdote.

Myths are usually compressed truths

The most durable technology myths often contain a real event. A moth was taped into a Harvard Mark II logbook, but Grace Hopper did not thereby coin “bug”. Apple engineers saw PARC’s graphical systems, but the Lisa and Macintosh were not copied as finished products from one stolen demo. IBM documented the PC architecture, but its BIOS was not open-source code.

Correction should preserve the interesting core while removing the unsupported addition. It should also resist replacing one hero with another. Inventions emerge from teams, manufacturing, standards, predecessors, and commercialization. Naming collaborators is more accurate than moving the same lone-genius crown.

Technical language receives the same treatment. “Open architecture,” “bug,” “recall,” “standard,” and “public release” have context-specific meanings. The article defines the operational meaning instead of relying on the emotional force of the label.

Historical impact is not inevitability

A product that later dominated did not carry its future market share at launch. Participants acted under uncertainty, with incomplete technology and competing standards. Writing backward from the winner makes every choice look obvious and every failed product foolish.

This category examines alternatives and constraints. USB required operating-system support, controllers, hubs, peripherals, and certification before it became universal. Wi-Fi required radio regulation and interoperability testing beyond the IEEE specification. Mozilla required years of redevelopment after Netscape released source. Those outcomes were constructed, not activated by the first announcement.

The same rule applies to business survival. A company that endured a crash was not necessarily disciplined in every respect, and a failed company may have built useful infrastructure. Social value, technical influence, and investor return are different measurements.

Internal links form an argument, not a content loop

History is easier to understand when related events connect without duplicating one another. A short news reconstruction can link to a company history, a standards deep dive, and a myth correction. Each page should still answer its own question; links provide scope rather than compensate for missing explanation.

The Netscape company history follows the organization from founding through AOL and Mozilla. The IPO post concentrates on one financing event. The browser-wars post examines competitive distribution. Repeating the same paragraph across all three would create apparent volume without new knowledge.

Links are checked against real slugs, and descriptions remain unique. Duplicate posts are avoided by defining a distinct historical question before drafting. Two articles can share a date or company when their evidence and purpose differ.

What this category promises

Every article should leave the reader with a chronology, causal explanation, explicit limits, and sources worth opening. It should say when a number is an announcement value rather than final cost, when a quotation is corporate positioning, and when a settlement is not an admission. It should distinguish source compatibility from binary compatibility and a trademark from code ancestry.

The category will never be complete. Computing history is too large, and new archives can revise old conclusions. The promise is narrower: what appears here will be dated carefully, corrected when evidence changes, and written so a reader can inspect the record rather than trust the author’s memory.

Related:

Sources: