Platform timelines research: practical details and examples

Researching what a service did, and when, is mostly a problem of source quality, and the sources available for this subject are unusually uneven. The best of them were written for other purposes by people who did not expect to be read as history. The worst of them are the ones that call themselves history. This page ranks the kinds of source by what each can establish, and describes a working method that produces entries someone else can check.

It cites no studies, because a study of platform history is a secondary source with the same problems as any other, and the method is what matters.

What to take away

• The best sources were written at the time, for a practical purpose, by people who would have been corrected if wrong: developer documentation, changelogs, help pages, terms.
• Coverage and retrospectives are useful for what was noticed, and unreliable for what happened.
• Participant memory is good for order and bad for dates.
• A research log that records what was searched, where, and what was not found is more valuable than any single finding.

Sources ranked by what they establish

Source kind	Written when	What it establishes	Its trap
Developer documentation and changelogs	At the time, for people building against the service	That a capability existed in a stated form by a stated version	Edited in place; the current page describes the current state and the history is gone unless captured
Help and support pages	At the time, for users	What users could do and were told; contemporary names for things	Same in-place editing; and support pages lag features
Terms and policies	At the time, for lawyers	What the operator claimed the right to do, and when that changed	The published date and the effective date differ; the effective date matters
App listings and release notes	At each release	Release dates for client software, sometimes by region	The client and the service are different things; a client release is not a feature launch
Coverage	Shortly after, for readers	That something was noticed, and how it was described	Later than the event; inherits the operator's framing; copied by later coverage
Operator histories	Long after, for the company	What the operator now wants remembered	Retroactive names, tidy dates, silent omissions
Retrospectives and reference pages	Long after, for readers	The consensus story	Consensus built by copying; origin claims inherited rather than checked
Participant memory	Now, about then	Sequence; what it felt like; what was normal	Dates; anything the participant did not personally see
Complaint threads and community discussion	At the time, for each other	Removals, breakages, unannounced changes; what users noticed	Partial; survives only where the container survived

The top half of the table is primary source material in the strict sense: made at the time, for a purpose other than describing the past. The bottom half is reconstruction. The middle, coverage, is primary about the coverage and secondary about the event, and it is the layer most timelines are built from, which is why they agree with each other and not with the record.

The in-place editing problem

Nearly all of the best sources are edited in place. A documentation page, a help article, a terms of service document: each describes the current state and overwrites the previous one, usually without a visible version history. The page that would have told you what the service did on a given date has been replaced by the page telling you what it does now, at the same address.

This makes captures the only route to the historical state, and the archive kinds described under internet culture archives capture documentation pages unevenly: the popular ones often, the developer pages sometimes, the terms rarely. A research method for this subject is therefore largely a method for finding captures, and for recording, when none exists, that the state on that date is unknown.

Searching with the right words

Search for a feature by its current name and you will find nothing from before the rename, and conclude either that it did not exist or that the sources are missing. Contemporary sources use contemporary names, and the names of features, of the service itself and of the behaviors around it change constantly. The vocabulary problem described under social media slang applies to product names as much as to anything else.

The working fix is a name ledger: for each thing being researched, every name it has carried and roughly when, built up as sources are read. Then search under each name. The ledger is itself a finding, and one that most timelines never record.

The log

The method's output is not a list of dates. It is a log, kept as the research proceeds, that records for each entry:

• The claim, as precisely as the sources support and no more.
• The date type: built, released, noticed, reported, effective. The distinction is the one the platform timelines page treats as the whole difficulty.
• Each source, with its kind from the table, its own date, and where it was found. A capture gets the capture date as well.
• What was searched and not found. A documented absence is a finding; an undocumented one is a gap the next researcher will have to re-open.
• Disagreements between sources, kept as disagreements, with what each rests on.
• The date the entry was last checked.

A log in this form can be handed to someone else, who can reproduce the check, add a source, or dispute an entry without redoing the work. A list of dates cannot be handed to anyone; it can only be copied, which is how most of the existing timelines were made.

Where the method runs out

For the earliest period, the sources in the top half of the table mostly do not exist. There was no documentation because there were no developers building against the service, no terms because no lawyers, no app listings because no app stores, and coverage was thin because the press was not looking. The early social networks page describes the resulting record, which is mostly participant memory and personal collections. The method applies, but its output is a log full of documented absences, and a researcher who is honest about that will produce fewer entries than one who is not.

That is the correct outcome. The purpose of the method is not to fill the timeline; it is to make every entry on it something a reader can check, and a short timeline that meets that standard is worth more than a long one that does not.

Common questions

Which single source is best?

A dated capture of the developer documentation, where it exists. It was written at the time, by people who would be corrected if wrong, using the names in use, and the capture date bounds it.

How much should I trust the operator's own history page?

As a primary source about what the operator now says, which is genuinely useful, and as a secondary source about the past, which is where it needs checking.

What do I do when nothing contemporary survives?

Enter the claim at the confidence the surviving sources support, mark the date type as reported or recollected, and log what you searched. The entry is weaker and the timeline is honest.