Interview with the GNU Directory's Janet Casey

A: The Directory was started from scratch in late 1999. It was originally funded by a grant from the Cordelia Corporation, but there was enough interest in it that the FSF has continued to fund it on an ongoing basis (our membership program is particularly valuable in this respect). UNESCO joined us in April of 2002. It is run from the FSF's offices in Boston, and accounts for between 40 and 45% of the traffic on the FSF's Web site; in a recent five day period, it had almost 2.5 million total hits. It has more than 3,400 listings, each one individually license-checked.

The scope of the Directory has broadened considerably over its lifetime: when Richard Stallman and I designed the original template for an entry, it had 30 possible fields; the current template has 47. The additional fields reflect changes in free software in general; for example, adding irc-help and irc-devel fields, and a bug-database field for packages that use (for example) bugzilla, reflects the general movement towards real-time interaction. Packages using Qt or written in PHP4, originally excluded due to licensing issues, are now included. We now list packages written in Java or Perl, which we did not when the Directory began.

I'm the only FSF employee working full-time on content for the Directory. I'm not a techie, so our sysadmins, Paul Fisher and Jim Blair, handle all the technical demands for the Directory (for the entire FSF, in fact). Bradley Kuhn, our Executive Director, did the Perl coding for some of the backend software.

Developers can submit packages and update packages already listed through the Web interface at the online entry submission form. I will still vet all information (to make sure it conforms to our specs) and license check all entries. We will consider any package that is under a license we consider acceptably free (see the Various Licenses and Comments about Them document), that runs on a free OS, that does not depend on non-free software, and that is reasonably stable.

A: The current FSD runs on a dual-P3 900Mhz machine with one gig of RAM. That machine runs other GNU services as well, and in the near future, to keep up with increasing demand, it will be moved to a quad-Xeon 2.8Ghz machine with six gigs of RAM.

A: I am a full time salaried FSF employee, hired in October 1999 specifically to work on the Directory (I have the longest tenure of any current FSF employee). From time to time volunteers have contributed (and I always need more volunteers). I'm not a technical person; our sysadmins handle that end of things.

I decide which packages go into the Directory, license check them, write up entries, and update existing entries so the Directory is as accurate as possible. In the beginning I never had to chase down dead links, but now the Directory has been around long enough that packages disappear, and I have to find them. I also answer user email, both what comes to me personally and what comes in through our trouble ticket system (we use RequestTracker).

The single most important of these tasks is license-checking; it's what sets the FSD apart from other free software directories. I open each package and check the license of each source code file. Almost 90% of the packages in the Directory are under the GPL or LGPL, but we will include any package under a license we consider acceptably free (see http://www.gnu.org/licenses/license-list.html), that runs on a free OS, and that does not depend on non-free software.

I also have to keep long terms development in mind, such as deciding when our classification system needs updating to accurately represent the growing width and depth of the Directory. We're always looking to expand the Directory's exposure; our partnership with UNESCO is an example of this. I've just started talking with the Wayback machine people about archiving not just the current version of the Directory but all the versions of source code that we have listed in the past.

A: It just involves making links. Sourceforge is a very valuable resource for the free software community, but they serve as a repository for all software, whereas we want to pick out packages that are already functioning.

A: I'm heartened by the growing interest in free versions of two particular programs: a free Flash, and free Java Swing. Neither project is complete, but both are under steady and active development. Anyone who spends any time on the Web knows that more and more sites these days are using Flash; a free version will be particularly valuable for the free software desktop, since it's mainly commercial and consumer sites that use Flash.

Classpath (see also classpathx, cp-tools, and mauve), the free version of the Java Swing GUI, is being consistently improved. I've had to exclude many Java packages from the Directory because Swing is non-free.

A really exciting and creative area is free software for video artists. There are packages available for real-time processing/manipulation (FreeJ, MoB, EffecTV, PiDiP, veejay), editing (LiVes), and a set of general tools and libraries (piksel).

The authors of these packages, originally developers, have moved into the artistic arena through their software. This isn't surprising; the ideals of freedom that underlie free software are the same as those that drive artistic creation. The ability to create (or hire someone to create) tools to create exactly the effect you want, without having to depend on the development whims of a software corporation, will attract video and multimedia artists, people who might not otherwise choose free software as their platform.

In general, the development of the Directory has mirrored the trends in free software. In the early days of the Directory, standard software had a command-line interface and was written in C; GUIs were just coming into vogue. Now, almost all packages have some kind of GUI interface, whether native or a front-end. In the past couple of years the Web interface has come to the fore. This reflects an increase in live/interactive communications in general, as we see in the growth of blogs and forums for both personal expression and technical support.

C remains the predominant language, but scripting languages have really taken off. I rarely saw Apache/MySQL/PHP programs in the first couple of years I worked on the Directory. In the last two to three years, however, that combination has become standard for Web applications.

There's an interesting licensing issue here also. When the Directory started, I regularly found licenses, named after the company that wrote them, that were simply minor variations of standards licenses like the GPL. I felt that these companies were trying to "brand" their license to make people believe that it was something unique, perhaps to attract the investment money that was still floating around then. I rarely see such licenses today; companies are returning to the GPL because it is a generally accepted standard that has stood the test of time.

A: The changes you'll see in the future will be refinements of the Directory as it now exists. For example, the fourth iteration of the classification system, one that reflects the growing diversification and depth of free software, will be rolled out in a few weeks.

The number of packages will increase steadily, but we always need volunteers to write up packages. I license check each package before it goes into the Directory, so writing them up is more time consuming than it might seem at first.

I'd like to tweak the Directory's home page. Right now it has a listing of "most recently updated" packages; I'd like to break that into "updated" and "new" packages, and add a sidebar that regularly features a different group of software: i.e. software for video streaming, software from one research facility, even fun stuff like a list of software by French developers for the week of Bastille Day. The Directory has more than 3,400 packages; I want to use the front page to tell users about *all* of them, not just the well-known ones.

We will, however, keep the interface as simple as possible. Many people still have slow or expensive connections; we don't want to make free software less accessible by making it slow or expensive to download.

A: We will implement, probably through a link to the changelog, a field that lets users find this information out. It looks like this will happen at the same time the new version of the classification structure goes live. Thank you for pointing this out, by the way. The FSF doesn't have the resources to do usability studies, so this kind of feedback is particularly valuable to us.

The editorial also revived an ongoing internal discussion about how to mine the deeper levels of data (possibly down to the file level) that are collected in the Directory. We've got a huge amount of data, and I know that, properly presented, it would be of great value to our users.

It's no secret, however, that documentation is not always the most important priority for free software developers. I urge developers to keep changelogs up to date. It would also be useful if a package's home page listed the changes for the most recent version, if not the changelog itself.

A: I don't want to stifle the creative anarchy that has always been a hallmark of free software, but there's a certain amount of repetition in the kinds of programs that exist. Believe me, the world does not need another window manager, and pretty soon there's going to be more image viewing packages than there are images on the Web!

I know a lot of great software was written because a developer couldn't find a package with certain features. That's great, and if in the end you decide you want to write something from scratch, go ahead. All I suggest is that you first take an unbiased look at the package you're planning to write. If only a few features differentiate it from what's already out there, consider contributing those features to a package that already exists.

Last, please pay attention to proper licensing. Put a license header with copyright date, name of copyright holder, and a statement telling what license the package is listed under in each source code file. The full text of a short license, such as the X11 license, can go right in the header. With the GPL or LGPL, please include a full copy of the license in the distribution. Since the "How To Enforce These Terms and Conditions" text is legally considered part of the GPL and LGPL, please be sure that it's in the copy of the license that you include in your software.

The more popular and economically viable free software becomes, the more it will come under attack. A trail of legal bread crumbs, in the form of a clear statement that the software you've written is free, is the best way to ensure that it remains free.

A: Thanks for giving me this chance to talk about the Directory!