In 2000, putting together a free working stack meant compiling half the tools by hand; in 2010 the same stack installs with one command and holds up a project in production. That is the concrete gap between two decades of open-source practice, and it is measured in hours saved on every job.

I write as someone who assembles sites and applications for a living, not as someone who studies licences for a profession. This is a reckoning from the trade: what changed in the free tools between the start of the decade and now, and where the changes genuinely shifted the way work gets done.

The context

The Open Source Initiative set down the Open Source Definition in 1998, drawing it from the Debian Free Software Guidelines, and in 1999 published its first list of approved licences (https://opensource.org/about/history-of-the-open-source-initiative). By the start of the decade, then, the vocabulary was already fixed: ten criteria, an approval procedure, a clear line between what is free and what is merely free of charge.

Back then the problem was not licence theory but having the tools ready to use. A LAMP server — Linux, Apache, MySQL, PHP or Perl — you could stand up, but each piece had to be configured on its own, and upgrading one risked breaking the others. What matured over the following decade is distribution and integration, not the principles: those were already settled by 1999.

Distributed version control

In my day-to-day work the most visible change is the move from centralised to distributed version control. For most of the decade the practical standard was Subversion, heir to CVS: a single server, one working copy each, no local history.

The shift has a precise date and cause. In April 2005 Bitmover withdrew the free licence of BitKeeper, the proprietary tool used until then for Linux kernel development. Within weeks two distributed systems appeared that were here to stay: Git, whose first commit dates to 7 April 2005, with version 1.0 released on 21 December that year under Junio Hamano’s care (https://en.wikipedia.org/wiki/Git); and Mercurial, announced by Matt Mackall on 19 April 2005, with the first 0.1 tarball on 27 May (https://en.wikipedia.org/wiki/Mercurial).

What sets these tools apart from Subversion is the data model, more than the speed — though the speed is there too. In a distributed system every working copy carries the project’s complete history: branching, merging and digging into the past are local operations that need neither the network nor permissions on a central server. A branch thus stops being a costly thing to plan and becomes the ordinary way to isolate an experiment or a fix.

What a free stack looks like in 2010

The stack I use today for a typical site is entirely free, and I install it as a coherent whole through the distribution’s package manager.

  • System and server: a Linux distribution with Apache httpd or, increasingly, nginx, which appeared in 2004 and was adopted because it handles many connections in parallel well.
  • Persistence: MySQL or PostgreSQL, both mature by now, with the latter preferable where referential integrity and transactions are needed.
  • Application language: PHP for most content-driven web work, with free frameworks now settled; or Python or Ruby where the domain warrants a more structured framework.
  • Version control: Git or Mercurial, with the repository doubling as the release mechanism to the server.

What changes from ten years ago is not the individual bricks — nearly all of them were already there — but the fact that the distribution keeps them aligned. A security update arrives signed and tested against the rest of the system; dependencies are declared; a second developer rebuilds the environment by reading a list of packages rather than a sheet of instructions.

The critical point: the licence is an architectural choice

The part of the decade easiest to underrate concerns licensing. On 29 June 2007 the Free Software Foundation published version 3 of the GPL, after eighteen months of public consultation and four drafts (https://www.fsf.org/news/gplv3_launched). GPLv3 addresses three matters that the 1991 version 2 could not foresee: compatibility with other free licences, software patents, and so-called tivoisation, the use of hardware signatures to stop modified versions of a free program from running.

For those who build — and do not merely distribute — a component’s licence decides what you can do with the work that rests on it. A library under the GPL dictates the terms to the program that links it statically; the same library under the LGPL, or under a permissive BSD- or MIT-style licence, leaves other paths open. Choosing a free tool without reading its licence means putting off an architectural decision to the worst possible moment, that of delivery. In 2000 a minority paid attention to this; in 2010 it is a routine line item in the technical assessment of every dependency.

What changes for working small

For a studio of a few people the cumulative effect is this: the entry barrier to quality tools has fallen close to zero, while the responsibility to choose them with judgement has risen. Ten years ago the constraint was the cost and effort of standing up the environment; today the constraint is the discipline of keeping track of what you use, understanding its terms, and keeping it current.

Distributed version control has made it normal to work with the full history at hand, to branch without ceremony, and to keep release inside the same tool that tracks the code. Licensing, clarified by GPLv3 and the OSI’s work, has made explicit what was previously taken for granted. These are two distinct maturations, yet they lead to the same outcome: less time building the scaffolding, more time for the client’s problem. This is also the reckoning noze starts from in closing out its first ten years of activity (https://www.noze.it/en/insights/noze-ten-years-2010/).

What remains open

This reckoning looks at the tools from the assembler’s side, and is silent on two fronts still open in 2010. The first is the sustainability of those who maintain free projects: software being available does not guarantee that someone tends it over time, and many tools I take for granted depend on a handful of people. The second is fragmentation: the coexistence of Git and Mercurial, of several equivalent frameworks, and of free licences not always compatible with one another, loads onto the user a cost of choice that the decade has not removed, only made more visible.

Cover image: Linus Torvalds, creator of Linux and Git, photographed speaking at the Linux.conf.au 2009 conference — photo by Christopher Neugebauer, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:Linux_Torvalds-Linux_conf_au-2009.jpg