As is the case of many free and open source software projects, GNOME’s planning
and discussions mostly happen online, on a variety of mediums, like IRC, mailing
lists, and issue trackers. Some of those mediums fade out over time, replaced by
other, newer ones; or simply because they become less efficient.
The first 10 to 15 years of GNOME can be clearly traced and reconstructed from
mailing list archives, which is a very good thing, otherwise this podcast would
not be possible without spending hundreds of hours in compiling an oral history
of the project, with the chance of getting things wrong—or, at least, wronger
than I do—or simply omitting details that have long since been forgotten by the
Nevertheless, it’s clear that some of the planning and discussion cannot really
happen over a written medium; the bandwidth is simply not there. Shared,
physical presence is much more efficient for human beings, in order to quickly
communicate or iterate over an idea; the details can be summarised later, once
everyone is on the same page.
By the year 2000, the GNOME project was already more than 2 years old, had its
first major release, and it was now encompassing various companies, as well as
volunteers around the globe.
While some of those people may have ended up sharing an office while working
for the same company, and of course everyone was on IRC pretty much 24/7, the
major stakeholders and contributors had yet to meet in one place.
Through some aggressive fundraising, what was supposed to be a small conference
organised by Mathieu Lacage in March for the benefit of the students of the
Ecole National Supérieure des Télécommunications in Paris was scaled up to
allow the attendance of 40 GNOME developers from around the world for four days
of presentations and discussions.
The main theme of the meeting was fairly ambitious: laying down the foundation
for the next major release of GNOME, starting from the core platform libraries,
with a new major version of GTK; the introduction of a comprehensive text
rendering API called “Pango”; and a more pervasive use of Bonobo components in
Additionally, it allowed companies like Eazel, Ximian, and Red Hat, to present
their work to the larger community.
Owen Taylor and Tim Janik presented their plans for GTK 1.4, including a new
type system and improved integration with language bindings; Owen also presented
Pango, a library for text rendering in non-Latin localisations, with Unicode
support, and support for bidirectional and complex text. GTK was also going to
be available on Windows and BeOS, thanks to the efforts of Tor Lillqvist and
Shawn Amundson, respectively. Havoc Pennington was working on a new text editing
widget, based on Tk’s multi-line text entry. Language bindings, for C++, Python,
and Ada, were also presented, as well as applications targeting the GNOME platform.
Out of the four days of presentations, planning, discussions, and hacking came
two major results:
- the creation of a “steering committee”, with the goal of planning and
directing the development efforts for GNOME 2.0
- the push for the creation of a legal entity capable of collecting donations
on behalf of the GNOME project, and act as a point of reference between the
community and the commercial entities that wanted to contribute to GNOME
As a side note, Telsa Gwynne’s report of GUADEC’s first edition is also the
first time I’ve seen an explicit mention of the “Old Farts Club”, as well as
the rule of being over 30 in order to enter it; I think we can add that to the
list of major achievements of the conference.
After GUADEC, in May 2000, GNOME 1.2 was released, as part of the stabilisation
of the 1.x platform, and GNOME 1.4 was planned by the steering committee to be
released in 2001, with the 2.0 development happening in parallel.
The process of creating the GNOME Foundation would take a few additional months
of discussions, and in July 2000 the foundation mailing list was created for
various stakeholders to outline their positions. The initial shape of the
Foundation was modelled on the Apache Software Foundation, as both a forum for
the technical direction of the project, and a place for corporations to get
involved with the project itself. The goals for this new entity, as summarised
by Bart Decrem, an Eazel co-founder, were:
- Providing a forum to determine the overall technical direction of GNOME
- Promoting GNOME
- Foster collaboration and communication among GNOME developers
- Manage funds donated to the GNOME project
There was a strong objection on having corporations being able to dictate the
direction of the project, so one of the stated non-goals was for the Foundation
to not be an industry consortium, similar to The Open Group. The Foundation
would also not hire developers directly.
In order to avoid corporate dominance, no company would be allowed to be a
member of the foundation: if a company wanted to have a voice in the direction
of the project they could hire a Foundation member, and thus have a
representative in the community. Additionally, there would be a limit on
directors on the board working for the same company.
As the Foundation was going to be incorporated in the US, one way to avoid
both under-representation of non-US members and the potential of fragmentation
through separate entities in each large geographical region, was to be more
open about both the membership and the board election process. GNOME
contributors would be able to join the Foundation as long as they were actively
involved with the project, and each member would be eligible to be elected as
a director. Companies would be part of an advisory organ, not directly involved
in shaping the project.
The idea of having the Foundation be the structure for setting the technical
direction of the project was dropped fairly quickly, replaced by its function
to be the place for settling controversial decisions, leaving the maintainers
of each module in charge of their project.
It is interesting to note that many of the discussions that were part of the
Foundation’s initial push have yet to be given an answer, more than 15 years
later. If the Foundation is meant to be a forum for module maintainers, how do
we define which modules should be part of GNOME, and which ones shouldn’t? Is
being hosted on GNOME infrastructure enough to establish membership of a
module? And, if so, who gets to decide that a module should be hosted on GNOME
infrastructure? Is GNOME the desktop, or is that just a project under the GNOME
umbrella? Are applications part of GNOME? The GNOME project is, to this day,
still re-evaluating those questions.
Alongside the push from Eazel, Red Hat, and Ximian to get the Foundation going,
came the announcement that Sun was going to support GNOME as the desktop for
their Solaris operating system, in order to replace the aging CDE. To that goal,
Sun was going to share the resources of its engineering, design, and QA teams
with the GNOME project. Additionally, IBM, HP, and Dell wanted to support GNOME
through the newly created Foundation.
Surprisingly, the discussions over the Foundation proceeded quickly; the
self-imposed deadline for the announcement was set for August 15, 2000, three
years after the first announcement of the GNOME project, to presented at the
Linux World Expo, a trade fair with a fair amount of media exposure. The
creation of the actual legal entity, an initial set of bylaws, and the election
of a board of directors would follow.
Having a few of the hot startups in the Linux space, as well as well
established companies in the IT sector, come together and announce they were
putting their weight behind the GNOME project would, of course, be spun in a
way that was adversarial to Microsoft, and so it was. The press release at
the LWE pushed the angle of a bunch of companies joining together to challenge
Microsoft, using a bunch of free code wrote by hacker weirdos to do so.
The announcement of the GNOME Foundation did not impress the KDE project, which
released a statement trying to both downplay the importance of GNOME and of the
companies that pledged resources to the GNOME project.
In November 2000, after finalising the initial set of bylaws for the Foundation
and opening the membership to the people contributing to the project, GNOME held
the first ever elections for the position of director of the board. With 33
candidates, a pool of 370 possible voters, and 330 valid ballots in the box,
the first eleven directors were:
- Miguel de Icaza (Helix Code)
- Havoc Pennington (Red Hat)
- Owen Taylor (Red Hat)
- Jim Gettys (Compaq)
- Federico Mena Quintero (Helix Code)
- Bart Decrem (Eazel)
- Daniel Veillard (W3C)
- Dan Mueth (Eazel)
- Maciej Stachowiak (Eazel)
- John Heard (Sun Microsystems)
- Raph Levien (Eazel)
Additionally, the advisory board was thus composed:
- Free Software Foundation
- Helix Code
- Object Management Group
- Red Hat
- Sun Microsystems
- VA Linux
After the election, the new board started working in earnest on the process for
incorporating the foundation and registering it as a non-profit entity; this
took until March 2001, after a couple of false starts. In the meantime, the main
topics of discussions were:
- the foundation bylaws, needed for the incorporation, the tax-exempt status,
and for opening a bank account in order to receive membership fees from the
- the GNOME 1.4 release management, handled by Maciej Stachowiak
- the preparation for the 2nd edition of GUADEC, to be held in Denmark
Additionally, the GNOME Foundation was going to work on establishing a trademark
for the project, both as the name GNOME and for the project’s logo.
Originally, the GNOME logo was not a logo at all. It was part of a repeating
pattern for one of the desktop backgrounds, designed by Tuomas Kuosmanen, who
also designed Wilber, the GIMP mascot. Tuomas reused the foot pattern as an
icon for the panel, namely the button for the launcher menu, which contained
a list of common applications, and let the user add their own.
In a typical free software spirit, and with a certain amount of bravery
considering the typical results for such requests, Red Hat decided to host a
competition for the logo setting as the prize for the winning submission a
graphic tablet; they also asked contestants to use GIMP to create the logo,
which, sadly, precluded the ability to get vector versions of it. In the end,
many good submissions notwithstanding, the decision fell to a modified version
of the original foot, also done by Tuomas—only instead of a right foot, it was
a left foot, shaped like a “G”.
Leaving aside the administrivia of the Foundation for a moment, let’s go back
to the technical side of the GNOME project, and take small detour to discuss
the tools used by GNOME developers. Over the years these tools have changed, in
many cases for the better, but it helps to understand why these changes were
made in the first place, especially for newcomers that did not experience how
life was way back when developers had to bang rocks together to store the code,
use leaves and twigs to compile it, and send pigeons to file bug reports.
GNOME code repositories started off using CVS. If you know, even in passing,
what Git is, you can immediately think of CVS as anything that Git isn’t.
CVS was slow; complicated; obscure; unforgiving; not extensively documented;
with a terrible user experience; and would fail in ways that could leave both
the local copy of the code and the remote one in a sorry state for everyone.
No, hold on.
Sorry, that’s precisely like Git.
Well, except “slow”.
Unlike Git, though, all the operations on the source revisions were done on
the server, which meant that you didn’t have access to the history of the
project unless you were online, and that you couldn’t commit intermediate
states of your work without sending them to the server. Branching was terrible,
so it was only done when strictly necessary. These limitations influenced many
of the engineering practices of the time; you had huge change log files in
place of commit logs; releases were only marked as such by virtue of having
generated an archive, as tagging was atrocious; the project history was stored
per-file, so you would not have the ability to see a change in its entirety
unless you manually extracted a patch between two revisions; conflicts between
developers working on the same tree were a daily occurance, and made integration
of different work a pain.
It was not odd to have messy history in the revision control, as well as having
to ask the CVS administrators to roll back a change to a previously backed up
version, to compensate for some bad commit or source tree surgery.
Due to how GNOME components were initially developed — high level modules with
shared functionality which were then split up — having commit access to one
module’s repository allowed access to every other repository. This allowed
people to work on multiple modules, and encouraged contributions across the
whole code base, especially from newcomers. As a downside, it would lead to
unreviewed commits and flames on mailing lists.
All in all, though, the “open doors” policy for the repositories worked well
enough, and has been maintained over the years, across different source
revision control software, and has led to not only many “drive by” patches,
but also to a fair number of bugs being fixed.
Talking about bugs, the end of 2000 was also the point when the GNOME project
moved to Bugzilla as their bug tracking system.
Between the establishment of the project and October 2000, GNOME used the same
software platform also used by Debian to track bugs in the various modules.
The Debian Bug Tracking System was, and still is, email based. You’d write an
email, fill out a couple of fields with the module name and version, add a
description of the issue and the steps to reproduce it, and then send it to
email@example.com. The email would be sent to the owner of the module, who
would then be able to reply via email, add more people to the email list, and
in general control the status of the bug report through commands sent, you
guessed, by email. The web interface at bugs.gnome.org would show the email
thread, and let other people read and subscribe to it by sending an email, if
they were experiencing the same issue, or were simply interested in it.
By the late 2000, the amount of traffic was enough to make the single machine
dedicated to the BTS keel over and die; so, a new solution was being sought,
and it presented itself in the form of Bugzilla, a bug tracking system
originally developed by Mozilla as a replacement for the original Netscape
in house bug tracker once Netscape published their code in the open.
The web-friendly user interface; the database-backed storage for bug reports;
and the query system made Bugzilla a very attractive proposition for the
GNOME project. Additionally, Eazel and Ximian were already using Bugzilla for
their own projects, which made the choice much more easy to make. Bugzilla went
on to be the bug tracking system for GNOME for the following 18 years.
By the end of the millenium, GNOME was in a good position, with a thriving
community of developers, translators, and documentation writers; taking
advantage of the licensing woes of the “Kompetition”, and with a major release
under its belt, the project now had commercial backing and a legal entity
capable of representing, and protecting, the community. The user base was
growing on Linux, and with Sun’s committment to move to GNOME for their next
version of Solaris, GNOME was one step away from becoming a familiar
environment for millions of users.
This is usually when the ground falls beneath your feet.
While GNOME developers, community members, and companies were off gallivanting
in the magical world of foundations and transformative projects, the rest of
the IT world was about to pay its dues. The bubble that had been propelling
the unsustainable amount of growth of the previous 3 years was about to burst spectacularly.
We’re going to see the effects of the end of the Dot com bubble on the GNOME
project in next week’s episode, “End of the road”.