Phil, who is the publisher of the Linux Journal, was involved in the startup of the Seattle Community Network. He can be contacted at [email protected].
When you first hear about either a Freenet or free software, you might think of them as similar. Both offer something for free: Freenets allow free access to information, while free software is software that's freely redistributable. And free software and Freenets both have to be paid for, probably in a combination of time and money, before they can be made available free to anyone.
However, they aren't the same at all. Still, with some minor changes in the Freenet movement, the two movements could be combined to offer something bigger and better than each movement could offer on its own.
How Freenets and Free Software Differ
A Freenet is a local computer system or network that can be accessed by anyone. It may (and generally does) contain a connection to the Internet, which offers a source for nonlocal news as well as the ability to correspond electronically using the mail-transport capability of the Internet.
The user interface for a Freenet should be designed to let a person who is unfamiliar with computers access the information. I say "should," because the human interface on many current Freenet systems is more difficult to use than many DOS-based BBSs
The common Freenet interface also doesn't address the special needs of groups who cannot use a regular keyboard and character display.
Freenets are generally created by a group or organization that sees a need for a community computer system and seeks funding of the project through donations and grants to purchase hardware, software, and support. Generally, Freenets also get involved with local government and community organizations.
According to the Cleveland Freenet, for instance:
The key to the economics of operating a community computer system is the fact that the system is literally run by the community itself. Everything that appears on one of these machines is there because there are individuals or organizations in the community who are prepared to contribute their time, effort, and expertise to place it there and operate it.
This can create two groups: the maintainer of the system, and the information providers. Expenses related to hardware, software, and operations (telephone lines, for example) are considered hard costs, but the cost of getting information is free. In the case of the National Public Telecomputing Network (NPTN), a nonprofit Freenet umbrella organization established by Thomas Grundner, Freenets are encouraged to join NPTN, resulting in either a payment of $2000/year or the release of local users' names and addresses for fundraising. This, added to the perception that hardware and software must be bought, can widen the division between the system itself and the local community. (For more information, refer to National Public Telecomputing Network: A Guide to the Development of Free-Net Community Computer Systems, published by the NPTN, Moreland Hills, OH, 1993.)
Free software generally starts in quite a different fashion. Much (probably most) free software starts with the individual's or group's idea of making a piece of software to meet a need. The project usually evolves, and if the software delivered is good and useful, interest increases.
Most free software comes from universities, either as part of a school-sponsored effort or from individuals who get interested in something and just start writing it. The Ingress and Postgres database systems are examples of the former, and Linux is an example of the latter.
But, in the end, these two things are on the same track, right? I say no. They could be, but they are not. Here's why: Once free software is written, it is free. That is, it's freely redistributable. This means that anyone can get it, fix it, give it away, or even sell it. Usually, a community forms around the software in which bugs and enhancements are discussed and issues are addressed in a cooperative way. There needn't be an organization in charge (although there certainly is in the case of the BSD distributions, and even with GNU software from the Free Software Foundation). Not having an organization in charge is what is important.
Current Freenets are usually based on software called "FreePort II." How do you get FreePort II? You lease it for $850.00 for five years. Can you give it away or share your work with others who haven't licensed it? No. Immediately, you have quite a different situation. Add to it the fact that you need to join an organization (NPTN) in order to be "official," and that you cannot pass along data you get from NPTN to non-NPTN sites, and you find that Freenets generally are not free in terms of purchase costs or freedom to redistribute the software and data.
What Services Exist on a Freenet?
Freenets generally offer a city motif where you "travel" to various buildings by selecting menu items. For example, the top- level menu on the Cleveland Freenet offers the following choices:
- The Administration Building
- The Post Office
- Public Square
- The Courthouse & Government Center
- The Arts Building
- Science and Technology Center
- The Medical Arts Building
- The Schoolhouse (Academy One)
- The Community Center & Recreation Area
- The Business and Industrial Park
- The Library
- University Circle
- Teleport
- The Communications Center
- NPTN/USA Today Headline News
These menu choices then offer sub-menus to access particular information or capabilities. In all cases, you use your keyboard to select specific items and read them or interact with them.
An example of a menu choice where interaction is encouraged is the Medical Arts Building, where you can correspond with a doctor directly, or read prepared information.
Added to these basic local choices, you may see the ability to read and post Usenet news, and possibly post and read advertisements.
What's Technically Wrong with Current Freenets?
Many current FreePort II-based Freenets do have shortcomings, including:
- The software is extremely inefficient, thus inflating the operational cost.
- The user interface is not good enough.
- The software was not designed to allow multiple user interfaces, such as one for the visually impaired.
The inefficiency issue is best illustrated by comparing FreePort II to Community Information Exchange (CIX). CIX is a commercial system used by TriState Online (TSO), a project of Cincinnati Bell Directory. It has a user interface that looks much like FreePort. Even though both CIX and FreePort run on UNIX-based Sun computers, the design of the two systems is quite different.
FreePort is a conglomeration of shell scripts, C programs, and calls to UNIX utilities to perform the required tasks. CIX is a program designed from the ground up to do nothing but act as a Freenet. This means that FreePort spends an amazing amount of its time loading new programs and transferring control between tasks.
Statistics from operation of TSO indicate that ten times the number of users recommended by the hardware manufacturer can easily be supported using the CIX software. On the other hand, Freeport-based systems offer performance at or below the number of users recommended by the hardware manufacturer. In simple dollars, this means that you need to buy ten times as much hardware to do the same task.
If you only want 3--4 users, a dedicated, low-end, 386-based system should be able to handle your task, but once you approach the tens or hundreds of users, these dollars start adding up fast. Besides, why dedicate a complete computer system to the task?
One serious problem with the FreePort user interface is a function of the implementation method--it just isn't consistent, and it can't be. For example, the UNIX more utility is used to page through files. (The average FreePort user doesn't know this.) What this means is that when a FreePort user is paging through a file, the command to return to, for example, the main menu, is not available. Users must exit more (which they don't know they are in) by either completing the read of the file or entering "q" before traditional FreePort commands become available again.
Another problem with using UNIX utilities as the bailing wire to hold FreePort together is that users will occasionally see a UNIX error message. This doesn't happen all the time, but it can happen, and it certainly can be confusing.
Finally, although the software was designed with the intent to let sites write their own user interface, the ability to implement these user interfaces just isn't there in FreePort. But this programmable interface is important. Without it, we excluded the visually impaired, as well as those who do not read English.
If FreePort had a programmable interface, the shortcomings of the current interface could be addressed without having to discard the complete system. Without it means starting from scratch.
Can these problems be solved? Yes.
All of them have been solved with CIX. Unfortunately, this solution is offered at a cost: The software isn't free. Although I think CIX is a step in the right direction in terms of implementation, and is something that I could recommend for commercial situations, I would hesitate to recommend it for Freenets. It just doesn't fit with the Freenet concept.
Where do We Go from Here?
I suggest that we design and build a true Freenet, where "free" means both free in cost and freedom to share. This effort could substantially increase the size of the Freenet movement and be a real feather in the cap of free software. And, for those who want to know if anyone will make money from it, the answer is yes: More Freenets mean more computer hardware, modems, telephone lines, and generally more computer users, requiring more computers.
If the system is inexpensive enough, Freenets will be set up by organizations that don't have computer expertise, resulting in configuration and support contracts. Money will be spent on local salaries that, under the old Freenet model, would have been spent on nonlocal hardware and software.
So, what are we waiting for? Let's build a "free" Freenet. If you see the need for a new sort of Freenet, here is a chance to get involved. The Linux Journal will be documenting the ideas, and, we hope, the development. E-mail your input to [email protected], or mail it to Linux Journal, P.O. Box 85867, Seattle, WA 98145-1867.
