Hello. And welcome to the History of GNOME. Episode 1.4 Founding the Foundation 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. All 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 be impossible without spending hundreds of hours on compiling an oral history of the project, with a chance of getting things wrong, or at least... wronger than I do or simply omitting details that have long since been forgotten by the people involved. 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 summarized later once everyone is on the same page. By the year 2000, the GNOME project was already more than two years old, had its first major release, and it was now encompassing various companies as well as volunteers around the globe.
While some of these 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 organized by Mathieu Lacage in March for the benefit of the students of a university in Paris whose name I won't even try to butcher with my terrible French.
turned out to be the first real GNOME conference. With travel sponsorship allowing the attendance of 40 GNOME developers from around the world for four days of presentations, panels, and informal discussions. The main theme of the meeting was fairly ambitious, laying down the foundation for the next major release of GNOME, starting for 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 the stack. Additionally, it allowed companies like Easel, Ximian, and Red Hat present their work to the larger community. Owen Taylor and Tim Yannick 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 localizations, with Unicode support and support for bidirectional and complex text. GTK was also going to be available on Windows and BIOS, thanks to the efforts of Thor Lilquist and Sean Amundsen, respectively. Havok Pennington was working on a new text editing widget, based on TK's multi-lines 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 of course hacking,
came two major results. The first was the creation of a steering committee with a goal of planning and directing the development efforts for GNOME 2.0. And the second was 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, Telso Gwynn's report of Guadag'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 WADEC in May 2000, GNOME 1.2 was released as part of the stabilization of the 1.x platform. and GNOME 1.4 was planned by the steering committee to be released in 2001, with a 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 modeled 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 the new entity
as summarized by Bart Dekrim and Ezel co-founder were 1. Providing a forum to determine the overall technical direction of GNOME 2. Promoting GNOME 3. Foster collaboration and communication among GNOME developers. And number four, manage funds donated to the GNOME project. There was a strong objection on having a corporation being able to dictate the direction of the project, so one of the stated known goals was 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 of 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 main 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 model maintainers, how do we define which modules should be part of GNOME, and which one shouldn't? It's being hosted on GNOME infrastructure enough to establish membership of a module? And if so, who gets to decide a module should be hosted on GNOME infrastructure? Is GNOME the desktop, or is it just another project under GNOME umbrella? Are applications part of GNOME?
The GNOME project is, to this day, still re-evaluating those questions. Alongside the push from Easel, Reda and Ximian to get the foundation going, came the announcement that Sun was going to support GNOME as the desktop of 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 discussion 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 be 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 will 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 that we're 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 brought by hacker weirdos to do so.
The announcement of the GNOME Foundation did not impress the KDE project either, which released a statement trying to both downplay the importance of GNOME and of the companies that pledge resources to the GNOME project. In November 2000, after finalizing the initial set of bylaws of 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 11 directors were Miguel de Casa from Elixcode. Have a pennington. from Raidat. Owen Taylor from Raidat. Jim Geddes from Compaq. Federico Mena from Helixcode. Bart Decrem from Easel. Daniel Veillard from W3C. Dan Meweth, from ESL. Machai Stachovia, from ESL. John Hurd, from Sun Microsystems. And Ralph Levien, from ESL. Additionally, the advisory board was thus composed.
a portable device manufacturer, IBM, the Object Management Group, Red Hat, SAN Microsystems, and 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 topic of discussions were the foundation bylaws needed for the incorporation, the tax-exempt status, and for opening a bank account in order to receive donations and membership fees from the advisory board. the GNOME 1.4 release management, handled by Maciej Stakovje, the preparation for the second edition of WADEC, 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 logo at all. It was part of a repeating pattern for one of the desktop backgrounds, designed by Thomas Guasmanen. who also designed Wilbur, 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 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 contestant 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 food.
also done by Tuomas. Only instead of a right foot, it was a left foot, shaped like a G. Leaving aside the atmosphere of the foundation for a moment, let's go back to the technical side of the GNOME project. and take a small detour to discuss the tools used by the 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 lives and tweaks 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 with failing 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, at least, 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 you couldn't commit intermediate state of your work without sending them to the server itself. 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 changelog files in place of commit logs. Releases were only marked as such by virtual webbing generating 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 occurrence, and made the integration of different work a pain.
It was not odd to have a 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 3 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 of the module repositories allowed access to every other repository.
This allowed people to work on multiple modules and encouraged contributions across all codebays, 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 work 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 various modules. The Debian bug tracking system was, and it still is, email-based.
You'd write an email, fill out a couple of fields with a module name and version, add a description of the issue and the steps to reproduce it, and then send it to submit at bugs.gnom.org. 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 command send, you guessed, by email.
The web interface at bugs.num.org would show the emailed 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 2000s, 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, Easel and Zymian 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 millennium, GNOME was in a good position, with a thriving community of developers, translators and documentation writers.
Taking advantage of the licensing rules of the competition with AK, and with a major release under its belt, the project now had a commercial backing and legal entity capable of representing and protecting the community. The user base was growing on Linux, and with Sun's commitment to move to GNOME for the 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 a 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 three years was about to burst. Spectacularly.
We are going to see the effects of the end of the .com bubble on the GNOME project in next week's episode, End of the Road.