Summary

The bot wanted a rate, not a platform

The project's own chronology begins with a modest irritation. Stenberg was working on an IRC bot for an Amiga-related channel and wanted it to calculate currency exchanges. The exchange-rate data existed on the web; getting it into the bot automatically was the problem. He found HttpGet, a small open-source command-line tool first released by Brazilian developer Rafael Sagula on 11 November 1996. Stenberg adapted it, and a release with his additions followed on 17 December. The bot's need did not create the original tool, but it gave the tool a persistent new caretaker and a reason to grow.

This origin matters because the later brand can flatten the sequence. curl was not born fully formed in 1998. HttpGet already had a useful job, a code base and an author. The version record preserves the succession of names rather than pretending that each rename created an unrelated product. The first problem was a specific data fetch. The enduring asset was code that could repeat the fetch without human intervention.

In 1997, HttpGet accepted HTTP URLs on the command line and gained proxy support. The currency data Stenberg wanted were not confined to HTTP: the history says Gopher support was fixed and FTP downloads were added. An HTTP-only name stopped describing the tool. In August 1997, the project became urlget 2.0. Its scope had moved from one protocol toward retrieving resources by URL. Later that year it gained FTP uploads and HTTP POST. A name built around getting was beginning to sound like a job description written before the promotion.

The second rename followed the new verbs

The project history dates curl 4 to 20 March 1998. The new name followed upload capability; version numbering continued from urlget. That continuity is more revealing than a birthday slogan. A utility for pulling one rate now spoke several transfer languages and could send data as well as receive it. The user still had a command-line tool, but the conceptual unit had changed from “fetch this page” to “perform a network transfer.”

Features continued to collect around that unit: the project history records SSL support, cookies and more browser-like operations in 1998. These were not all present at the moment of the rename, and the chronology matters. A tool that transfers data on behalf of scripts must handle the real conditions of the network it meets: proxies, authentication, state and different schemes. Each addition widened the number of jobs that could be entrusted to the same code.

The more consequential change came in 2000. The curl history describes a spring overhaul to make a suitable library interface. Version 7.1 was released on 7 August and offered the easy interface. The 7.1 change log shows the mechanical work behind the claim: public libcurl symbols, option-setting calls, shared-library building and installed header files. A program could now call the transfer machinery instead of spawning a command and parsing its output. The transfer engine had become a part another developer could bolt into an application.

The project's history says a third-party libcurl binding appeared that August. That is evidence of a new boundary being crossed: people who did not maintain curl could make their own software depend on its interface. The original bot had needed a helper. The helper had become a helper for other people's programs. A tiny exchange-rate errand had purchased a reusable network component, with years of protocols and build work on the receipt.

The interface was the durable invention

The current libcurl documentation explains the easy interface as a direct sequence of setting options, performing a transfer and cleaning up a handle. Current features should not be projected backward onto the 2000 release. The historical point is the shape of the boundary: the caller supplies a URL and options; libcurl owns the difficult conversation with the network. Once that boundary exists, improvements inside the library can serve many callers.

The three names are a compressed history of changing authority. HttpGet promised HTTP retrieval. urlget promised URL retrieval across schemes. curl no longer tied the project to one protocol or one direction. libcurl then moved the useful work behind an API. Each rename followed running code that had already crossed the old boundary. The paperwork chased the machine.

The bot's question was small: what is this amount in another currency? The lasting question was who should implement the fetch every time a program needs data from the internet. curl's early record shows one answer forming through practical additions, not through a grand platform announcement. First the tool learned another protocol. Then it learned another verb. Finally it learned to be called by someone else's program.