Wikipedia: The Page Is Only the Latest Version

A printed encyclopedia has a useful trick: it cannot change while you’re reading it. A mistake can remain impressively consistent across an entire edition. Correcting it requires another printing, a supplement, or a reader with a pencil and unusual confidence.

Wikipedia made the article into an editable web page. The project launched on January 15, 2001, a date commemorated by its own community as Wikipedia Day.¹ Readers could become contributors, and an entry could change without waiting for the rest of an edition to be finished.

That shift created a new publishing problem. If people can improve an article immediately, they can also damage it immediately. The interesting software question is how to make changes inspectable and recoverable without making every contribution wait outside a locked editorial door.

History is part of the answer. The page a reader sees is one state of an ongoing document. Behind it is a sequence of edits, comparisons, and decisions. An encyclopedia becomes a process with a public working surface.

Begin with a project, not a finished institution

Wikipedia emerged alongside Nupedia, an earlier encyclopedia project involving Jimmy Wales and Larry Sanger. Sanger’s participant memoir describes Nupedia’s peer-reviewed ambitions and his work organizing both projects. It also expresses his dissatisfaction with how the relationship between them developed.²

The memoir is valuable because its author participated. It is not a neutral verdict on every later disagreement. A founding history should preserve roles and competing interpretations rather than appointing one retrospective account as the official memory of everyone involved.

Wales and Sanger were central to the launch. The contributors who began writing and revising entries were central to turning the launch into an encyclopedia. A site can begin with a small founding group; its contents require many more people.

The software also changed. Wikipedia initially used UseModWiki. The MediaWiki project’s own history describes the move to new software during 2002, with Magnus Manske associated with the second-phase PHP implementation and Lee Daniel Crocker with the subsequent phase.³

Modern Wikipedia is therefore not the original engine with twenty-five years of articles poured into it. Claims about current database tables or editing facilities need their own dates. This article uses a general revision model to explain the mechanism, rather than assigning today’s schema to January 2001.

A revision is an object worth keeping

Suppose an invented encyclopedia article begins with this sentence:

The Cedar observatory opened in 1902.

An editor checks a source and changes the year to 1903. Another adds a location. A third replaces the whole paragraph with nonsense. If the system stores only the latest text, the first two editors’ work has become dependent on somebody having kept a copy elsewhere.

A revision system preserves earlier states. Each save can have an identifier, an author or recorded contributor identity, a time, and a comment describing the edit. The current page selects one state for ordinary reading, while the history makes other states available for inspection.

These are conceptual properties, not a reconstruction of UseModWiki’s exact files. Wikipedia’s current help documentation explains page histories, comparisons and restoration, while MediaWiki documents its later revision storage.⁴⁵

The distinction between a page and a revision is useful. A page has continuing identity: the article about the Cedar observatory. A revision records a particular version of its contents. Renaming or editing the article doesn’t require pretending it is an entirely unrelated intellectual object.

It also changes the cost of a mistake. A destructive edit can be visible, but its arrival needn’t erase every earlier state. Recovery can select known text rather than reconstruct it from memory. The software has made a bad edit less permanent, which is more realistic than making every editor infallible.

Four versions and one repair

Here is an original teaching history. The observatory, dates and editors are invented.

Revision	Text	Relationship
1	Cedar opened in 1902.	Initial version
2	Cedar opened in 1903.	Corrected year
3	Cedar opened in 1903 in Northfield.	Added location
4	Cedar is made of cheese.	Destructive replacement
5	Cedar opened in 1903 in Northfield.	Restored revision 3’s text

Revision 5 can have the same text as revision 3 while remaining a different event. Someone performed a restoration after revision 4. Keeping that event in the history allows a reviewer to see both the damage and the repair.

Original CC0 teaching diagram, 2026. Invented article and revision identifiers; not a screenshot or reconstruction of Wikipedia’s 2001 data files.

This is one reason an edit history isn’t just a pile of backup copies. The sequence records actions. Two identical text states can mean different things at different points in that sequence.

Now compare revision 2 with revision 3. A text comparison, or diff, identifies the location phrase as an addition. Compare revision 3 with revision 4 and the replacement is much larger. A reviewer can concentrate on the changed material instead of rereading an entire long article after every save.

Our example was checked with Python’s text-comparison library and a small revision model. That verifies the invented strings and restoration relationship. It doesn’t reproduce MediaWiki’s comparison algorithm, storage format, or original UseModWiki behavior.

A diff also has an epistemic limit. It shows that the year changed from 1902 to 1903. It cannot decide which year is historically correct. The source used by the editor still matters. Efficient inspection is a contribution to judgment, not a substitute for it.

Two editors can start from the same past

A more subtle problem arises when two contributors begin editing the same revision. Alice opens revision 2 and adds the observatory’s location. Bob also opens revision 2 and adds an architect’s name. Both changes could be useful.

If Alice saves first and Bob’s later save blindly replaces the current page with his copy, the location can disappear. Bob may never have seen Alice’s addition. This is a lost update: one valid contribution overwrites another because the software fails to account for the shared starting state.

A general solution compares the editor’s base revision with the current one. If the base is no longer current, the system needs a policy for detecting, combining, or asking a person to resolve competing changes. That is a general collaborative-editing mechanism, not a claim that every 2001 edit conflict behaved like today’s system.

Original CC0 diagram, 2026. A general lost-update model; no claim about the original wiki engine’s exact conflict-handling implementation.

Changes in different places may combine cleanly. Changes to the same sentence may require judgment. Even a mechanically clean combination can be wrong: one editor may change a date while another adds a sentence referring to the old date.

Textual compatibility and semantic compatibility are separate questions. A merge tool can preserve both strings while producing a contradictory paragraph. People are still needed to notice when the article has become an argument with itself.

The software’s useful contribution is to expose the situation before one person’s work vanishes silently. Preserving the base and current states gives the conflict a concrete form. It turns a vague accusation of “you deleted my work” into something inspectable.

Publication and discussion have different jobs

An encyclopedia article aims to tell readers what can be supported about its subject. A discussion space allows contributors to negotiate how to present it. Those two activities need a relationship without becoming the same page.

A technical edit may fix punctuation. A substantive edit may change a claim’s meaning. The history helps distinguish their size, but contributors still need sources and a shared understanding of the article’s purpose. The mechanism for saving text cannot settle a disagreement about evidence.

The possibility of restoration also changes social behavior. Contributors can try a correction knowing that another person can inspect it and recover previous text. That lowers the irreversibility of an individual action. It doesn’t lower the need for care.

Repeated restoration can itself become conflict. Two editors can continually return the article to their preferred state. The history preserves the loop; it doesn’t make either participant correct. Software can make a disagreement unusually well documented while leaving it entirely unresolved.

That is the tradeoff I find most revealing. Open participation increases the chance that someone notices a problem and the chance that someone introduces one. Revision machinery makes this bargain more manageable, but the bargain remains a social and editorial commitment.

The early archive doesn’t preserve everything

The original wiki’s history cannot be treated as a complete laboratory record. Wikipedia’s project account of the early UuU page explains that early histories were incompletely preserved and that later recovery of archival records changed which edit was considered the earliest surviving one.⁶

That matters when assigning “first” claims. A surviving timestamp establishes evidence about a surviving record. It doesn’t necessarily establish that no earlier edit occurred. Absence from an incomplete archive is a poor basis for certainty.

The early CamelCase naming convention also affected page names and links. UuU is a reminder that technical link syntax can leave strange visible artifacts in an encyclopedia. Software conventions sometimes become history’s filing system.⁶

These details prevent a polished modern interface from washing away the project’s provisional beginnings. Reliable revision storage was itself part of the system’s development. The explanation above describes the value of that machinery, not a claim that it arrived fully formed on launch day.

A reference work that can show its work

Wikipedia’s consequential change was joining reference publishing to ongoing, broadly accessible editing. The article became revisable, while the surrounding software supplied ways to inspect and repair the process.

Its importance doesn’t require claiming it invented the wiki or solved the reliability of knowledge. The site inherited an existing web-editing idea and developed it in a demanding setting: an encyclopedia whose topics, contributors and disagreements could all grow.

The worked revisions show why the history belongs beside the article. A current paragraph tells us what the page says now. The sequence explains how it arrived there, and a comparison narrows the work needed to assess a change.

That is a powerful publishing instrument, provided the reader remembers its limits. A recoverable error remains an error until somebody checks it. An edit summary remains an editor’s description, not a warranty. The computer can keep the versions; the difficult part is deciding which version deserves to be read.

Sources

Footnotes

1. Wikimedia community, Wikipedia Day, project record of the January 15, 2001 anniversary. ↩

2. Larry Sanger, Essays on Free Knowledge, preview, 2020 revision of his 2005 origin memoir, printed pp. 3–7 inspected. Participant account, explicitly treated as a memoir; the full book was not read. ↩

3. MediaWiki project, MediaWiki history, project account of UseModWiki and the 2002 phase transitions. ↩

4. Wikipedia, Help:Page history, current project documentation used for revision/comparison concepts, not a 2001 interface specification. ↩

5. MediaWiki, revision table documentation, later schema documentation; no modern table layout is assigned to UseModWiki. ↩

6. Wikipedia project, UuU archival account, includes surviving edit records and contributor testimony. The preservation qualification is retained; no definitive first-edit claim. ↩ ↩²