Read related articles on Computer industry, Internet economics, Linux and Software development

This essay describes the facts and merits of the decentralized form of Linux development and support. It suggests some ways that the continued development and growth of freely redistributable software such as Linux can be encouraged. In many respects, this is not a Linux-specific document; many of the principles should be applicable to other "free software" (or "open source") initiatives such as the free BSD projects and many others that are directed towards applications rather than OS platforms.

Contents

Motivation - Why is Centralization an Issue?
Organization Models in the Linux Community
Mandates and Purposes of a Linux Foundation
In the Interim - Your Fair Share
Sources of Inspiration in the Growth of "Free Software"
Credits

Motivation - Why is Centralization an Issue?

Many people have complained over the last few years that there should be some sort of "central" Linux organization.

Some common reasons that I see include:

• It would be good for there to be some "central" Linux presence on the Web.
• It would be good for there to be some organization holding the Linux trademark to prevent situations like one that recently occurred where an individual named Della Croce claimed a trademark on the name "Linux", and began demanding royalties from anyone using the name.

  Items "in public trust" need to remain in public trust.

• Many companies want and need some sort of central "Linux Authority."

  Companies want a rather more formalized support mechanism than "Go ask questions on the Internet." They want a formal system of Linux Support so that users having problems have some sort of help desk to call. This could involve telephone support as well as more formal consulting.

  All this being said, InfoWorld recently awarded "Linux People on the Internet" their award for InfoWorld B est Technical Support. Evidently there is some value to Internet-based support.

• Linux needs some sort of centralized advocacy organization for marketing purposes. The point here being that other operating systems have marketing machines, while Linux doesn't.
• Every other major operating system has a central organization.
• We need to have a way to encourage financial sponsorship of worthwhi le development projects.
• A less favorable reason is that many people apparently like to be herded by others.

There is little agreement as to what organization should be "king" but there is desire for a "king" nonetheless.

I would like to argue that while there are imperfections in the support presently available for Linux, this does not mandate the creation of an authoritative central Linux organization.

I would argue furthermore that the decentralization Linux displays represents a strength in that it allows support to grow simultaneously in many areas, unhindered by any particular controlling agency.

Real Disadvantages to Decentralization: Linux Support is Fragmented

There are disadvantages to the decentralized nature of Linux development, as it causes support arrangements to be somewhat fragmented. Linux does not have a single organization offering all of the sorts of things on the list below, as is the case for most other operating systems. There is no single organization responsible for the various support roles which are presently distributed across various organizations in the Linux community:

• There are three notable distributions (Red Hat, Debian, Slackware, not to mention more commercialized variants such as Caldera and SUSE) as compared to just one for other systems such as FreeBSD, which does not even consider less publicized Linux distributions such as Stampede, SEUL, TurboLinux, Bogus, Craftwork, and Linux FT.
• There are many Linux Web sites, none being authoritatively the home of Linux.
• The same can be said for FTP sites where Linux software resides.
• There is a lot of duplication of effort in documentation maintenance.
• There are many marketing efforts coming from different directions and organizations, none really organized to help The Linux Community.

  This is an intractable problem, since due to the diversity of interested parties the needs and desires of the community are themselves diverse.

• There are a number of kernels and other "base" system utilities that are of interest as possible application targets.

  This includes kernels in the version 1.2.x "series," which has been stable for a long time to the point of being "ancient", to the more modern 2.0.x series, which is also quite stable, but changes every so often, to the 2.1.x experimental series, which changes on roughly a weekly basis.

  In addition, there have been a number of sets of C libraries (with the recent transition from LIBC 5.x to the FSF "GLIBC"), multiple binary formats (with the transition from a.out to ELF), and, of late, three C/C++ compilers to worry about (GCC 2.7.x, GCC 2.8.x, EGCS). Transitions between libraries have sometimes been painful.

  Critics of Linux often overstate these problems. Most programs do not need to be aware of the distinctions between these system components, and typically do not even need to be recompiled in order to function on a system using a newer kernel/library. Those few that do need coding changes tend to attract a great deal of publicity

  It can still be difficult for developers to select an appropriate target kernel or a special purpose library particularly when some specialized or experimental feature such as resource locking, threading, or multiprocessing is needed.

• Just how many libraries are there out there for GUI development? Which one should I use?

  There are many graphics libraries that run on Linux, including Xt, Motif, Tk, Qt, Gtk, and GNUStep, to name only the most popular ones. This problem is of course not restricted to Linux. It has roughly the same impact on applications running on both "free" and commercial UNIX-like OSes.

  This problem also plagues popular non-UNIX-like platforms. The various Microsoft Windows variants support a wide variety of graphic APIs and libraries that come from a variety of vendors.

• Organizations that use Linux would prefer to have one authoritative Linux organization to look to for support.

Advantages to Decentralization

Despite there being some problems to decentralization, I believe that there is a net advantage for Linux to having the variety of independent organizations fulfilling their various roles. We may view the independent organizations in aggregate as a sort of "virtual corporation."

Here are a number of ways that decentralization benefits Linux:

• Independent organizations can act in their own best interests.

  So long as these various organizations remain legally and truly independent, Linux will not run into some problems that have beset IBM and Apple.

  Apple has the Software or Hardware? problem. Their software operations might make betterdecisions if they did not need to care about the health of the hardware side, and vice versa. And this might well benefit the overall organization.

  IBM has long been noted for spending millions of dollars developing new products, and then dropping them before even trying to release them as soon as another division determined that the new product would cannibalize their own sales. OS/2 is a good case in point:

  • The PC division benefited more from selling computers running MS-DOS and Microsoft Windows, and has never stood behind OS/2. It could be argued that they should have been required to bundle OS/2 with every computer IBM sold, with other third-party operating systems as "extra cost options."
  • OS/2 could not be permitted to be a "threat" to the mainframe or "mini" (e.g. AS400) divisions.
  • There is also the AIX/UNIX group that would also be unhappy about competition from OS/2.

  Trying to come up with real advocates of OS/2 within the company was a problem; there were ample reasons for these and other IBM divisions to actively oppose the use of OS/2. This probably also applies in many other situations. There are, no doubt, times when UNIX-related sales efforts threaten mainframe sales, which begs the question of which "threat" to prefer. OS/2 evidently didn't receive the support needed to compete against Microsoft's operating system products.

• Having independent organizations reduces the incidence of bottlenecks.

  The Free Software Foundation has had the problem that their leader, Richard M. Stallman (commonly known as "RMS") appear to think that they ought to have control over the body of free/GPL (GNU Public License) software. Ignoring the consideration that others may not want to be so controlled, they simply don't have enough staff to manage all of the projects that are active.

  There is the potential for free software to represent a billion dollar a year sort of effort. The Free Software Foundation is certainly not large enough to manage the results that come from that level of activity. I'm not sure that they could grow large enough to oversee it all.

  Linux developers have nobody stopping them from introducing something new. Nobody is waiting for permission from Linus Torvalds for much of anything.

  Moreover, Linux developers can and typically do use standardized protocols that allow projects to work independently, which means we're seldom forced to wait for any particular resource. Since, for instance, the X11 protocol used to implement the X Window System i s a defined graphical standard that is quite stable, development can proceed independently on such things as X servers, GUI libraries, the Linux kernel, and other system components both large and small.

  In contrast, MS-Windows system updates/upgrades have often been painful as system components as well as applications are deeply interlinked. This is good for the careers of consultants that want to have continuing work cleaning up after the problems, but it is expensive for the global community on which the changes are inflicted.

  UNIX-like OSes and Microsoft's OSes can be contrasted nicely from a technical perspective in this fashion:

  • Microsoft Windows (in its various versions) enforces relatively little separation between the different system components. Programs using the Win32 API fairly directly access all pieces of the system, from file systems to GUI to memory management.

    This has the unfortunate result that if the way any system component functions is changed, all programs typically need to be changed to conform.

  • UNIX-like systems enforce a clear separation between kernel and user processes, and furthermore separate users. The X Windows graphical infrastructure is also clearly separated from both kernel and users.

    On UNIX systems, it is typical for component upgrades to not have adverse affects on programs. There are counterexamples, but they are the exception rather than the rule.

    Linux kernel upgrades normally only directly affect the functioning of a small number of programs.

    Upgrading the X Windows System from version X11R4 to X11R5 to X11R6 to whatever other new revision has not normally caused significant disturbance to programs written for the older versions; there may be benefit to rewriting programs to use functionality from the new libraries, but that is not necessary. It is not normally necessary to recompile programs. The existing programs normally continue to function as if their environment had not changed.

    Moreover, running a program using the "new" Gtk GUI does not make the Xt applications stop working. This also displays a valuable and novel thing about the X Window System, which is that it can simultaneously accomodate applications that use different graphical user interfaces.

• When ownership of Linux is distributed to many people around the world, this discourages attempts to privatize Linux as any one person or organization's asset.

  The situation where Della Croce laid claim to the trademark "Linux" pointed out the importance of this. He temporarily had legal control over the name, which caused much concern in the Linux community.

  In contrast, since Linus Torvalds started accepting changes to Linux using the GNU Public License, nobody has had, or will have, sole control from a legal standpoint over the source code to Linux. In order to legally privatize the source code to Linux, thousands of contributors to Linux would need to agree to this. There are enough that are likely to disagree that this is extremely unlikely to happen.

• Independent organizations can agree to disagree, when necessary.

  If Linux remains somewhat fragmented in its support network, this does mean that there may be some problems that fall through the cracks, which is unfortunate.

  The NetBSD Project (building a "free" operating system based on a system called "BSD 4.4 Lite") seems to have fractured due to internal disagreements, where people with dissenting opinions left and created OpenBSD. It is difficult to (without entering into great controversy) establish precise causes. Regardless of the causes, the split has hurt the credibility of both groups.

  

  But by not having a monolithic organization, Linux people are free to work as independently as they want to. They can agree to disagree, and support may grow independently of the political limitations on any of the organizations that are involved.

  The GGI and Berlin graphics projects are good examples of why it is good to have a degree of independence. Both of these efforts to create improved graphics infrastructure have been ongoing for well over a year.

  In a "fully-integrated" Linux.Org, they would either become:

  • Critical path projects which, since they're not done yet, prevent further development of anything else that somehow depends on them (bringing us back to a bottleneck), or
  • Projects discarded because Linus Torvalds did not agree that they should go into the official kernel.

  There are disagreements over the wisdom of these individual efforts; the fact that they're going on independently means that at present, they disturb no one that doesn't want to be so disturbed.

  For instance, while I would personally like to see GGI "succeed," at least as a platform on which X could be run very fast, I think that the Berlin efforts are misguided. My feelings doesn't necessarily hinder either effort; in the decentralized world of Linux development, they are free to succeed or fail independently of what I want or think. Some developments may be a waste of time, but ultimately do not critically hurt other Linux efforts.

  Were the efforts centralized, failure of a critical development project would injure everyone. For instance, if I were the authority, and I, "Great Tyrant Chris", required that the GGI graphical infrastructure be adopted, this would leave continuing work on many other Linux-based applications and subsystems vulnerable to the possibility that GGI may not become stable and useful in a timely fashion.

  With the highly distributed development model, Linux is not generally vulnerable in this fashion.

• There simply does not exist some monolithic or otherwise easily characterized body known as The Linux Community.

  In other words, there is no fixed centre that to Linux, although Linus Torvalds certainly exerts some influence.

  Linux has a whole variety of users with a wide variety of desires, needs, wants, and abilities.

  Some would describe it as a server OS, just like the other UNIX operating systems. Others deny that,claiming that it's the greatest "PC" OS, and that demanding that applications support multiple users is a foolish notion.

  Linux is a very powerful system that can indeed by used in many ways. Writing applications that limit themselves to a particular "mode" of operation if they can be readily extended to provide added flexibility and power is clearly unwise. You can, very often, have your cake, and eat it too with Linux.

Other Beneficiaries of Decentralization

Three companies that have seen fairly spectacular levels of growth come out of the "allow independence" approach are:

• SAP AG

  This German enterprise software organization has not tried to provide all consulting services for care and feeding of their software, but actually has encouraged the use of external consultants. R/3 has received tremendous support from "Big Six" consulting firms as a clear direct result.

  SAP AG and consulting firms actually do work cooperatively because they have all found this cooperation to be profitable.

  It is more common for sales organizations pay lip-service to such cooperation, while working against it in reality. Oracle's manufacturing software has not done so well in the marketplace, and I expect that this can be attributed in part to Oracle being less cooperative.

• Hewlett-Packard

  The independence of the various components of Hewlett-Packard is quite remarkable from organizational, technical, and economic perspectives. The current dominance of the their printing unit in the global market displays the importance and value of independence.

• Microsoft and Personal Computers

  Many years ago, corporate information systems were largely run by IBM. They provided robust systems, but systems development was time consuming and expensive, and departments were often unhappy with service provided by MIS departments.

  Personal computers running MS-DOS and PC-DOS gave departments the opportunity to own and control their own computing environments, independent of central MIS management, at relatively low cost. PCs certainly didn't provide the robustness and scalability of mainframe systems. But it was fairly easy to make PCs do useful things without too much effort using prepackaged word processing, spreadsheet, and database software. From a political perspective, software licenses could be acquired relatively cheaply at the departmental level rather than having to go through the MIS department. This gave departments more power.

  The fact that PCs were neither particularly reliable nor particularly manageable compared to the mainframes (and this can lead to nightmarish problems to this day as organizations try to scale up PC LANs) does not contradict this. PCs have been "good enough" to prove useful and valuable.

Organization Models in the Linux Community

The Linux community (and similar "free software" initiatives) have shown quite a number of organizational models that serve different useful purposes in supporting the growth and improvement of Linux and the Linux community.

This section lists different kinds of organizations that we see in the Linux community.

There is room for all of the existing organizations to grow and thrive; in addition, in keeping with the "decentralized" theme already presented, I suggest that if anything there should be more such organizations. This would be particularly valuable when looking at "project-oriented" groups. Groups that are working on independent efforts can and should remain independent.

Linux Development Corporation

This sort of organization develops software/hardware/documentation products, gaining funding from selling Linux "products."

There are many such enterprises (see: Linux Commercial Vendors). Note that most of these organizations do not place under the GPL (GNU Public License) all of the intellectual property that they produce.

Linux Support Consultants Inc.

The purpose would be to sell consulting services to assist people in installing, improving, and supporting Linux systems.

There are a number of consulting firms, with many more findable through the "LinuxConsultants HOWTO that is part of the Linux Documentation Project.

Red Hat Software has an initiative where they seek to create a Red Hat Linux Certification program. There are also other efforts; nothing fully realized thus far.

Russell Nelson of Crynwr Software has suggested the idea of "The Linux Organization" providing services as a "broker" of Linux support. They could accept technical questions and/or contracts to handle technical issues, and "farm them out" to a group of "Linux Consultants".

My personal feeling is that this can probably be most effectively provided by independent "Linux Consultants Inc. (LCI)" organizations that operate explicitly as a service providers of this sort. Recent efforts at Red Hat Software use this approach. If a consulting firm sees fit to support Linux projects, that is well and good, and this may be something that they should present as a marketing tool:

Not only can we provide good service - we are involved actively in making Linux better.

I think, however, that connecting "all of Linux" (in the form of a not-for-profit organization) is likely to dilute the effectiveness of both organizations. I've seen this happen.

An appropriate "free" initiative would be to provide assistance integrating Linux systems into schools initially as mail/network servers, and perhaps ultimately as application servers. This would most sensibly be organized via regional consulting organizations that might grow out of local user groups (See the User Group HOWTO, which contains some comments from this document).

And don't discount Internet-based Linux support; "Linux People on the Internet" won the 1997 InfoWorld B est Technical Support Award.

2.3 Linux Advocacy International

There is an organization called Linux International that does some advocacy work. It would be nice to have such an organization more formally funded for common efforts. Caldera and Red Hat have both sponsored advertising, which has been generally good for Linux. That advertising has been specifically directed to their own products, which isn't necessarily of general value to all Linux folk.

The two primary activities of this sort of organization would be marketing and "information provision." Specific activities could include:

• Pushing general Linux advertising material

  Perhaps the most outrageous idea I've heard would be to put a Linux TV commercial on SuperBowl '99 (whether that would be worthwhile is another question).

  Low-key items would include submitting product information to computer magazines.

• Responding formally to specific criticisms.

  There have been a few rather uncomplimentary newspaper articles, as well as the occasional "SCO Inaccuracy". It would be good to know that a calm, reasoned response will go out.

• It might make sense for this organization to be a "trademark repository", a central point where things like trademark problems would be dealt with.
• Providing a central Web site allowing people to branch out to the multiplicity of Linux resources.
• Bumper stickers and pins and other "marketing materials".

Relevant existing organizations include:

• Linux International

  Unfortunately, while they have a pretty impressive list of officers and directors, it would be easy to mistake Linux International for a completely inactive organization. Their spokesperson, John "maddog" Hall of Digital Equipment Corporation, is personally quite active in promoting Linux at special events and conferences, but there appears to be little if any other activity in the organization.

• SSC

  The company SSC originally started as a publisher of UNIX-related documents. They publish the monthly Linux Journal that I now see at many US newsstands. Their publication now represents a major source of advocacy and publicity for Linux.

• Linux Gazette
• Linux Advocacy Project
• Linux User Group List Project
• User Group HOWTO,
• Linux CD and Support Giveaway List

Linux Project Development Foundations

There is an existing model that could usefully be emulated that comes from the example of the Free Software Foundation, in the form of a project-oriented development group.

The FSF has provided a number of things used with Linux, most critically:

• GCC, the kernel compiler, along with compiler construction and binary management utilities,
• The CopyLeft license, and an infrastructure designed to help protect this license,
• A variety of file management utilities that are near replicas of traditional UNIX utilities.

The Free Software Foundation (FSF) was founded with a very similar purpose to that which Linux satisfies quite well, that being To create a free operating system environment that can replace UNIX, from whence comes "GNU - GNU's Not UNIX." It started by constructing "system construction" tools, notably GCC and compiler/binary utilities, GNU Emacs, and UNIX-like file utilities.

Unfortunately, by the time they got around to constructing their kernel called Hurd, the organization had hardened into what now looks like a "clique" with what seem (from the outside) to be a strong set of political beliefs that seem rather disparaging of commercial enterprise.

Unfortunately, Richard Stallman, head of the FSF, is very commonly misquoted, and sometimes his actual comments are surprisingly different from what people assume he would say. Many criticisms are based on misguided readings of his statements. This nonetheless doesn't let me agree with everything he says.

Read the texts of interviews with Richard Stallman and Linus Torvalds. Linus' commentary on Stallman and his comments is rather interesting.

Political preferences be as they may; there are most definitely some problems at the FSF. They can be seen most visibly in:

• A general lack of interest in Hurd, the GNU kernel. This may have resulted in the attempts by the FSF to rename "Linux" as Lignux, which caused disagreement between the Linux and FSF communities,
• The split of Emacs development, with the FSF maintaining "GNU" Emacs, while an independent group maintains the closely-compatible "XEmacs" editor,
• The split of GCC (the GNU C Compiler) development, where there is now an FSF tree (that was not publicly updated for a rather long time) and the recent "egcs" Project hosted at Cygnus Software.

These situations parallel the situation where some people split off of the NetBSD project to start the OpenBSD project.

The root causes for these various splits are diverse, but consider the common features:

• Splits and disagreements have occurred and persisted.
• The resulting organizations have had sufficient people and expertise to survive.
• Not only have they survived, but the "children" have successfully built up functionality not provided by the "parents".

I would argue that this shows that there are serious problems with the way the FSF is working.

The world has changed in some substantial ways since the FSF was founded in the early '80s. Their purpose was to build a free version of UNIX. In 1985, the world needed a free UNIX variant, as none existed. In 1997, the presence of Linux and *BSD OSes that are both powerful and robust leaves many wondering why the still highly experimental Hurd is necessary. Hurd expresses some novel ideas, but I think it unlikely that it will ever be more than a curiosity.

I suspect that part of the reason why the FSF has run into trouble is that they have become "old revolutionaries" that are having trouble renewing purpose as the environment has changed around them.

In the GNU Bead Project Portal "manifesto", Lyno Sullivan describes a

GNU project responsible for designing, building and improving a working model of the formal GNU volunteer organization and its software infrastructure.

His commentary on a previous version of this document was that he

was saddened because (I) expressed a lot of frustration with the perceived rigidity of the FSF

That is a fair assessment; his comments to the effect that some degree of "rigidity" is necessary early in the design process is also fair. I would agree that a good design must indeed start with the creation of something of a "Cathedral" by a few people, and that only once the overall design is reasonably stable is it practical to start people working in "Bazaar" mode.

My response to Lyno is that there is a point at which the Cathedral can and should be transformed into a Bazaar, and that the FSF:

• Does not appear to recognize the fact that this transformation should happen in general,
• Does not recognize that there are specific projects that would benefit from the "Bazaar" transformation, and most importantly,
• Doesn't seem to want to let go of control over RMS's "children".

Linux VARS Limited

There are quite a number of Linux systems integrators that sell preconfigured Linux boxes,generally providing built-to-spec-on-demand machines for their customers.

There have been some proposals for user groups to assist local PC vendors in constructing "Linux Box Specs" so that there can be local storefront PC vendors that sell Linux systems as well as the Linux VARS that generally sell by mail order.

Linux Documentation/Information Exchange

The World Wide Web has made it possible to implement virtually any conceivable scheme for organizing Linux information.

Most notable as a source of up-to-date system documentation is the Linux Documentation Project from which Linux HOWTO documents are distributed. I rather like My View of Linux; it contains links to various news and information sources that take many approaches to organizing information about Linux.

Publishers such as SSC, O'Reilly and Red Hat Software (amongst many ) are perhaps the most notable providers of printed manuals and books, including both commercially copyrighted material as well as an increasing variety of copylefted documentation.

A lot of the information for which other companies create "help desks" gets transmitted in the assorted forms of:

• Usenet postings and discussions
• Email responses
• Web pages with things like "HOWTO" documents.

This does not provide the systematic coverage that many need; the fact that there are a whole lot of monkeys out there banging on keyboards means that on the one hand, there are some dumb answers given, but there often are useful answers given out.

Commercial help desk organizations today too often represent expensive 1-900 services staffed by unknowledgeable people that don't have material as good as the Linux HOWTOs to work with.

The Linux Documentation Project is nicely providing organization for documentation so that documentation work is not excessively duplicated. This came via the creation of an SGML DTD originally called "LinuxDOC" now known as SGML-Tools. This document has been maintained using these tools.

Something similar should be done to documen t "packages" on the Web. For almost any given information classification, there are many people replicating virtually the same information several different ways. For instance, there are at least five independent Web pages documenting databases (as with my RDBMS - Relational Database Management Systems page).

One of the best is SAL - Scientific Applications on Linux.

A "souped-up" version of the LSM format ( The Linux Software Map (LSM) used on the Sunsite archive to automatically collect basic information about Linux software packages) could be used to encourage creation of more reusable information in this area.

The New LSM format should contain sufficient information to be able to represent all of the critical information about software packages shown on such pages as My Word Processor Page, the relational database page, my Linux for Finance page, my spreadsheet page and more massive collections of application-oriented links such as Scientific Applications for Linux .

New fields not already provided for in the current LSM format should include such things as:

• Location where prepackaged/preconfigured versions (e.g. in Red Hat's RPM or Debian's DPKG forms) can be found
• Location where configuration information can be found
• Location/name of relevant HOWTO(s)
• Location of an Anonymous CVS server (for shared development)
• Improved "subject" information to make it easier to create a taxonomy categorizing packages
• A unique "key" linked to some sort of database (probably using CGI) so that one could do quick, unique cross-references

  e.g. with Unique-key:5F22C one might do lookups from a "LSM collection" by referring to a URL looking like:

  • RPM link

    http://www.lsm.org/cgi-bin?package=5F22C;type=LINK;ref=RP= M

  • DPKG link

    http://www.lsm.org/cgi-bin?package=5F22C;type=LINK;ref=DP= KG

  • Home page link

    http://www.lsm.org/cgi-bin?package=5F22C;type=LINK;ref=HO= ME

  • Link to a page of links to relevant HOWTOs

    http://www.lsm.org/cgi-bin?package=5F22C;type=PAGE;ref=HO= WTO

The utility rpm2html is a generator of Web pages for RPM packages. It takes RPM files and generates a fairly sizable set of index information, providing various indexed views. Other efforts have been springing up to try to collect and organize these sorts of information, and I anticipate substantial improvement over the next year.

Conclusions

There are a number of efforts corresponding to many of the organizational models models listed in this section.

For some "organization types", extensive support is already coming from software companies, VARs, and other such sources of assistance. Improvement is almost always possible, but in many cases there are good organizations that are growing that require little attention for us to see further improvement.

Commercial products are sponsored by sales because ultimately information and assistance have value.

An area of particular weakness is that of Development Projects for significant pieces of free "infrastructure".

This sort of effort could be strengthened by the introduction what I would call Linux Foundations. The remainder of this document is directed at describing how such organizations might be organized.

Mandates and Purposes of a Linux Foundation

• Purpose: To sponsor a project for the creation, enhancement, and promotion of freely available tools and components for the continuing development and promotion of Linux and other free computer operating systems.
• Delivery: Deliverable materials should be distributable under the GNU CopyLeft, with interim releases being managed using the "bazaar" concept described in Eric Raymond's article, The Cathedral and the Bazaar, preferably using some variant of "Anon-CVS" for source code management.

By using a project-oriented mandate rather than having a fixed goal ("to develop the Linux operating system and related tools"), this may allow the goals of the organization to more readily change as public needs change. If the project becomes complete, the purpose of the organization might well go away.

Regular CVS-based releases would help to maintain the accountability of programmers; it will be quite clear whether or not bozo@lsf.org is working on code based on the daily or weekly archive updates.

In some cases, existing projects and tools could be improved if some people had financially sponsored time to spend concentrating on them.

Desirable Projects for a Linux Foundation

As the organization's mandate is to sponsor projects, it makes sense to think of a list of possible candidates. Here's a few examples including things that are fairly common on wish-lists.

• Providing the authoritative Linux Web site
• Motif (see: LessTif)
• An "Office Productivity" suite (see: Office products)
• A free Web browser with functionality comparable to Netscape Navigator (see: Web browsers).

  Note that Netscape has announced plans to release Netscape Communicator Developer Edition in source code form for free under some scheme based on the GPL by the end of March 1998; see also other free Netscape links.

• I2O support (see: I2O Links)
• A free COBOL compiler (see: COBOL Overview)
• Better File systems (see: Linux File Systems)
• Database systems (see: Linux Relational Database Systems)
• Database query tools - not unlike an "Access" clone. There exist some DBMS-specific tools; it would be desirable to have one that is database independent.
• Integration tools between Linux-based spreadsheets and SQL databases
• "Friendly" sysadmin tools (ala COAS, linuxconf)
• An X server for the new Splotch 9000 graphics card
• A free accounting system (see: Linux Financial Software)
• Support of "Win32 programs" WINE is trying to do this, and Will ows does something similar.
• An ICA protocol server/client (See: Network Computers/ICA)
• An reasonably objective system for certifying "Linux Consultants"
• A "Raytraced-Penguin" commercial for use in television
• A free alternative to Adobe Illustrator
• A free group scheduling tool using the IETF Calendaring and Schedu ling Standards (See: PIMS)

These are generally large projects that are a bit too big to be handled by people doing "evening" work.

Equally importantly, some of these things involve tasks that are tedious so that people that are working to build something "good enough for me to use" won't find it worthwhile to put in the additional effort to polish the results for general use.

If such projects are formally funded by a "Linux Foundation", this encourages creation of some of the fiddly things that require more work than people can do in spare time.

Some would argue that these represent products that can be sold commercially. This is indeed true. Most of the products on the list are already available for Linux in some commercial form. The fact of commercial support establishes that people are willing to put money into such applications.

Some would also argue that free software will discourage the creation of more and better commercial software. Free software has not discouraged the development of commercial databases, Web servers, text editors, and many other sorts of programs.

The presence of good and free software raises everyone's expectations.

It presents commercial enterprises with the question:

Why should I pay for your product when I can get blah for free?

To some "free software extremists," the answer is

If there is a faintly acceptable "free" product, I will not pay for your product.

To others that feel less strongly, a useful answer is more like: like:

Buy our product because we offer better functionality or make it easier for you to use.

The availability of free software tools makes it easier and cheaper to develop good software, both free and commercial. Commercial enterprises can benefit from this.

Economics: How would a "Linux Foundation" be Funded?

We could try to have a Linux Foundation have "departments" involved in various sorts of commercial activities in order to provide funding, thus having "subsidiaries" that are of the various sorts of other organizations previously mentioned. Consulting, Internet Service, selling "Linux PCs", or selling Linux software.

I believe, however, that doing these things would direct attention away from the project activities of a LF.

The simple funding answer: Grants/Donations

A Linux Foundation should be incorporated in much the same form as similar organizations as the Free Software Foundation and The XFree86 Project, as a tax-exempt non-profit organization that can receive grants on a tax-deductible basis from both companies and individuals.

I believe that free development efforts need to be sponsored by freely given grants of funds, materials, and services.

This can include encouraging other Linux-related enterprises to sponsor free software projects either directly or by providing funding or other resources to organizations like a LF or directly to development projects. For instance, a variety of Linux-related companies (as well as some less-related organizations) have been known to sponsor projects under the GNU Public License. To cite just a few examples:

• S.u.S.E. has been sponsoring development of X servers for a whole variety of recent graphics cards that should soon be released as part of XFree86;
• Caldera has contributed various kernel code, is working on the administration tool system COAS, and has been making "OpenDOS" and CP/M re-available (albeit less freely than initial reports suggested);
• Red Hat has contributed software that they have written such as RPM, PAM, as well as the whole Red Hat distribution as GPLed products, and has founded RHAD - Red Hat Advanced Development Laboratories to produce further GUIed tools in conjunction with the GNOME Project;
• Yggdrasil is sponsoring development of the Arena Web browser, as well as working quite a lot on "bleeding-edge application ports";
• Willows released sources to "Twin," which functions as a MS-Windows WIN16 emulator, in GPLed form;
• Cygnus Support has done a lot of work on GCC-related tools, most recently including some degree of sponsorship of "EGCS."

Based on these examples, it is quite reasonable to expect companies that profit from Linux to contribute something back to developme nt efforts. Whether that comes in the form of funding or of freely redistributable software is not too critical.

As a not so trivial aside, I would think it preferable for commercial contributors to prefer the form of the GNU Public License (or the LGPL, for libraries) to that of the BSD style of licensing. The GPL requires that any further contributions to code also beGPLed, which means that the contributing organization can expect to themselves benefit from other peoples' contributions. In contrast, Berkeley-style licenses allow competitors to take the code, improve on it, and keep the improvements private.

Moving beyond commercial enterprises, government agencies would be perhaps the most interesting "targets" of Linux sponsorship, as various tools (COBOL compiler, office productivity software) are of a nature that it might make sense for a governmental organization to provide some funding. Here are a few ideas:

• A group of 3-4 municipalities might grant a Linux Foundation funding to develop a "free" municipal tax accounting system. The next year, other municipalities might sponsor development of additional "application modules". The next year, 200 municipalities might move to the "Linux-Tax" system, and sponsor some additional modules.

  1997 would have been a nice time for such a package to be ready, in view of upcoming Year 2000problems.

• A government department might spend $300K helping develop a "GNU COBOL" compiler rather than spending the money on commercial compilers. The next year, 10 government departments start migrating code to "GNU COBOL" to run it on license-cost-free Linux servers.

  Note that the development of GNAT - GNU Ada was sponsored by the U.S. government in much this fashion. And that development of Perl was similarly sponsored by NASA/JPL. UNIX hardware vendors such as HP, NeXT and Digital (and almost certainly others) have contributed equipment, monies, hardware specifications, and even some expertise towards GCC development for their platforms. Precedents exist.

• A U.S. Defense Department contract might result in creation of a SGML DTD Design Editor and an associated document editor for managing SGML documents. Integrate this together with a GPLed document database system, perhaps with some assistance at "beefing up" MMediator (Mnemonic Mediator) and the plot thickens.
• Encourage a British school board to sponsor the creation of Linux-based educational software and software tools. Schools with limited funding might be early beneficiaries of "Network Computers".
• A public hospital might sponsor development of a secure hospital document management system using such tools as SGML, text databases,securing data against intruders/tampering using PGP (Pretty Good Privacy).
• Would it not be valuable to also have a small-scale medical practice data repository that is relatively secure, and which allows auditable transfers of data to/from the hospital systems?

These are all pretty big ideas. Almost surely not all of them will happen. But none of them are particularly outrageous.

I have heard arguments that people do not want government involved because of "government inefficiency." So long as usage of software that results from such projects is relatively unrestricted, I do not see a problem with this. If the software is reusable, any initial inefficiency quickly fades to irrelevance. If it were to cost $100 Million "too much" to develop GNU COBOL, but this still leads to millions of dollars worth of later savings in spending on software licenses, this may still be an attractive tradeoff.

Donations? Grants? Commissions?

It has been pointed out to me that contributions to such projects should be viewed as grants rather than as charitable donations.

Pure charitable donations go out as assistance to people in poverty, with no reasonable expectation of much return beyond gratefulness (note that the English word "charity" was, in the early days, synonymous with "love").

Grants, in contrast, are given to people and organizations w= ith an expectation of valuable results.

The purpose to contributing to free software is definitely not well-characterized as "pure charity". It is appropriate to expect contributions to turn into valuable results.

In cases where someone has substantial amounts of funding to provide, it is reasonable to be even more particular about the desired result, and set up a specific commissioning. Aladdin Software, for instance, has been commissioned to produce a Display Postscript "server" particularly for use with the GNUStep project.

Alternative Funding Sources

Here are some other funding methods that I feel are unlikely to provide substantial funding. While they may defray some costs, I do not believe that they are feasible ways to substantially fund development efforts. The Free Software Foundation, for instance, has not gotten wealthy by the sales of CD-ROMs. The fact that there are a goodly 20 vendors selling Linux CD-ROM products and publications means that there is little opportunity to bring in substantial money by starting up another not-for-profit alternative.

The major alternative to "freely given contributions" is to create a "captive commercial enterprise" to provide funding, and in my experience, that doesn't work very well. Student service organizations are not typically competent to also run businesses; churches should not run bingo halls; governments should not run lotteries. This divides the organizations into pieces that have substantially differing goals, to the detriment of all.

There is, nonetheless, some limited value in having small sideline operations, so long as it is kept clear that they are not intended to do much more than defray the direct costs of providing associated public services.

• A Linux Foundation could build a small distribution channel for some combination of those things that it produces. It would be logical to try to recover the costs of running the "Internet presence" via the sales of CDs and documentation.
  • A Web/FTP site,
  • Electronic media (CD-ROMs, DVD-ROMs) with Linux software in both source and binary form,
  • Printed media.

  A Linux Foundation should not presume that they will receive substantial funding out of sales of media.

  Commercial enterprises such as Red Hat, InfoMagic, LSL, CheapBytes, SSC, and others have shown that they can provide many of the same sorts of products very effectively at reasonable prices, which limits the "profits" that can be extracted from this mechanism. It might make just as much sense for a "Linux Foundation" to resell media from a "discount vendor" like LSL or CheapBytes.

• Source Code Brokerage

  Rahul Miller has extended an offer to be a "source code broker" so that dealing with GNU Public License clauses relating to the offering of source code does not need to be burdensome to those that develop software.

  It would be of some value for a "Linux Foundation" to provide similar services; they would certainly need to offer sources to software internally developed; it would be valuable to the free software community for a foundation to provide brokering services for other developers of free software.

Licensing Approaches to Intellectual Property

There are occasional "wars" between those that think that the GNU Public License is the ideal way of distrbuting "free" software and those that think that the BSDL model is "freer". And I have room only to mention that there are other variants of the GPL such as the "Aladdin Ghostscript" license and the "Artistic License" from Perl.

The critical difference between the BSD License and the GNU Public License:

The GPL specifies that all derivative software must also be made freely available in source form.

On the other hand,

The BSD license specifies that people are free to do whatever they want with "BSD Licensed" code, including reselling derivative works as commercial products without any legal obligation to return the changes to the community at large.

The GPL demands the permanent freeness of any code released under it. In effect, it makes the assumption that people want to make "free" intellectual property proprietary, and seeks to prevent that. It and its most vocal proponents seek to make a political statement to "change the world".

The BSD license approach, in contrast, makes the assumption that it is worthwhile enough to make some intellectual property "free" that people and organizations will support a useful amount of "free" software. If the code is really good, then the world is free, able, and encouraged to adopt it for all kinds of purposes. Hopefully enough people will feel morally obligated to also contribute.

As an example of advantage that comes from using the GPL, Willows have released their TWIN Windows emulation system under the GPL, which means that if anyone else improves it, and wishes to redistribute the improved system, the changes must also be made available under the GPL. This means that Willows (as well as the community at large) gains benefit of other peoples' improvements to the system. Those changes could remain proprietary with the "BSD" approach.

In contrast, by virtue of the fact that it can be used to derive "proprietary" software, BSD networking code has had a tremendous impact in the commercial world; the fact that companies may take and freely make use of the code has had the result that most TCP/IP network implementations include some components of the BSD "reference implementation" code. The GPL blocks that use of code.

There are people that are strong proponents of each approach. Interest in the GPLed Willows system has been limited, while there appear to be far more people working on the WINE system that uses a BSD License. On the other hand, far more people appear to be working on the GPLed Linux kernel than on any of the BSD operating system projects.

My personal belief is that the world has room for both the GPL and BSDL models. There is value to both; in different environments, each approach has advantages. Having the multiple approaches to intellectual property permits people who want to give different things to the community to indeed do so.

GPL proponents should allow the BSDL licensing model to be free to either succeed or fail at providing useful free software to the world, and vice-versa.

If someone wants to give away different aspects of their intellectual property, that's their problem. If they prefer the GPL, that's OK. If they prefer the BSDL licensing model, that's OK.

In the Interim - Your Fair Share

If you have benefited from using Linux or other freely produced software, it is entirely fair to expect that you return back Your Fair Share to help improve future releases. Contributions might reasonably be given in a variety of forms, notably including the following:

• Financial grants
• Build needed software
• Providing information
• Providing service

I think it fair to expect people to contribute Their Fair Share in some fashion in all of these areas, and in particular, in the financial area. The United Way (a charitable program that operates in the USA and Canada, and elsewhere, as a "clearing house" for donations) asks people to contribute what they suggest to be a "fair share" in order to support community service efforts. They typically suggest contributing on the order of one percent of one's income. For Linux, I would suggest that the reader consider the alternative valuation metric of:

How much would you have paid for commercial versions of the software?

• Installing Linux instead of NT Server "saves" you on the $1000 USD, and I have seen estimates of as much as $5000. If the millions of Linux users contributed $1000 (or its equivalent) to Linux development efforts, that would literally provide billions of dollars of funding to help improve Linux. These figures sound rather high, and this sort of spending is unlikely particularly for home systems, but this kind of contribution is not preposterous for someone installing Linux in a commercial environment.
• $100 resembles pricing for "PC" operating systems like Windows 95, and still represents potentially hundreds of millions of dollars in funding. If, instead of spending the several hundred dollars per year on commercial software that is probably typical for PC users, Linux users contribute similar funds directly to software development efforts, that still points a remarkable amount of money and effort at software development.

I would argue that $100 per year is a pretty "fair share" for a home user of Linux. Some people (particularly students) honestly can't afford that, which is fair enough. I would still urge having some financial participation, however nominal. Contributions that come in the form of services are valuable and are also highly necessary; combining the various kinds of contributions strengthens the community.

If the gentle reader has received benefit and has not given something back, I would suggest that you consider where contributions can be made in the following section.

Financial Grants

With the multiple millions of Linux users, it would be entirely plausible for grateful users to individually contribute a little.

That has the potential to add up to hundreds of millions of dollars towards development of improved tools.

That being said, getting funds to developers and other worthy recipients may realistically represent something much like the old story about Belling the Cat. At this time there isn't any single "Linux Software Foundation" to which we can expect to see such contributions go. And I don't expect that the present organizations are realistically prepared to receive millions of dollars.

There are, nonetheless, a number of possible routes for Linux users to take to make financial contributions to efforts to improve Linux, and I would urge that people consider contributing to them.

Having a single "umbrella" organization ("Linux Development Foundation") would have some value as a focal point, but is not necessary. It is useful for individuals for there to be a way of turning contributions into tax deductible expenditures, so as to maximize the value of those contributions. I can contribute more money "pre-tax" than I can "post-tax."

I have contributed to some of the following organizations and not to others. Inclusion in the list doesn't mean that I agree with all their aims, merely that they have some reasonable relevance to Linux and free software and that they appear to me to be worth considering.

Note that many of these organizations are also able to use contributions that come in the forms of computer hardware and services.

• Send Linus Torvalds a gift

  This really isn't a direct way of increasing "Linux Free Software developments;" it's nonetheless a nice idea. Linus' efforts with respect to Linux certainly deserve to be rewarded.

  Note that Linux System Laboratories have set something up where you can send a $5 gift to Linus when buying a $2 CD.

  I'd be game to do this regardless of any potential future work Linus may do; his "lifetime contributions" are most certainly worth to me more than any nominal sum I might send. If 100,000 people dropped $20 his way, would that not be pretty neat? It would certainly be well-deserved.

  This could be applied further. If there is someone that built free software that you use and find valuable, it would be an entirely nice idea to write out a cheque for twenty dollars, find their address, and send it to them completely unsolicited with a nice note thanking them for their efforts. There may be no tax benefits or any formal expectation of anything in return, but it certainly will be an encouragement. It beats the usual whining about When will version 4.2 come out? And when will you be adding my pet feature to the program?

• The XFree86 Project

  If you use X, it would be entirely reasonable to send them a (tax-deductible in at least some jurisdictions) donation to help in the continuing work.

• Debian/Software In the Public Interest

  They have their own Linux distribution; those that "love" Red Hat may not be interested in contributing to assist "Debian Linux." But they also are involved with promotion of opening hardware standards (in contrast with things like I2O).

• Linux International Project Sponsorship Fund

  If Linux International were to develop a charitable tax status for its Project Sponsorship program, it might be a catalyst for other Linux projects.

• Various Linux Advocacy projects

  These projects are looking for various sorts of volunteered things, and not necessarily financial contributions.

  • Linux Publicity Project
  • Linux Advocacy Project
  • Linux User Group List Project
  • Linux CD and Support Giveaway List
  • Linux Banners for Web pages

• Your Local Linux Users Group

  Local groups may obviously pursue activities to benefit the local community; they may also participate in activities with international implications.

  My local group, NTLug (North Texas Linux Users Group) has been pursuing charitable status. The local approach may allow personal tax deductibility to cross international boundaries, which is rather nice.

  Mark Aitchison suggests that a worthy task for local groups is to:

  Prepare scripts for enabling access to a particular ISP (Internet Service Provider) - start with the nicest/cheapest local provider, then let others feel pressured into helping the user group if they have problems with their ISP.

  Another would be to:

  Help local hardware suppliers produce ready-made Hardware+Linux solutions, e.g. a dual-booting home system, a Linux-only Web gateway & proxy for an organisation.

  My local users group, NTLug, has a monthly "Linux Installation Project" at a local computer show, and there are rumblings about submitting a system specification to a local PC builder to encourage creation of another Linux "VAR" (Value Added Retailer). There are some plans to publicize within the group all local vendors that sell Linux-related products.

  I have also heard rumor of efforts to target U. S. government organizations in Washington to try to do mass installs of Linux for office systems there. A group of four people could probably do 20 installs an hour in a room with an impromptu LAN, and if they charged $20 per system, and together collect $400 per hour, which is simultaneously far cheaper than doing Windows installs, and yet highly profitable.

  The fact that user groups bring people physically together makes them a logical nexus at which any of the other sorts of "organizations" can build up. Thus:

  • Some local people start building some "Linux PCs" and create a VAR.
  • Local people grow up a software business for some local niche
  • Local publicity efforts at a "PC Expo" or other such event
  • One consultant gets together with another, and encourages more of the same.

• League for Programming Freedom

  This is not a Linux-specific organization; they are involved in some general advocacy activities that touch on those involved in any way with software production.

  Involvement in this case represents something closer to involvement in a political lobby group.

  There's just a touch of "USA bias"; there are nonetheless international implications, and the international community as often as not follows the American lead in computing-related matters.

• The LaTeX3 Project Fund

  The TeX Users Group (TUG) is working on the "next generation" version of the LaTeX publishing system, known as LaTeX3. Linux is one of the platforms on which TeX and LaTeX are best supported.

  Contributions for the project can be sent to:

  ---

  
  TeX Users Group
  
  P.O. Box 1239
  
  Three Rivers, CA 93271-1239
  
  USA
  
  

  ---

  or, for those in Europe,

  ---

  
  UK TUG
  
  1 Eymore Close
  
  Selly Oaks
  
  Burmingham B29 4LB
  
  UK
  
  

  ---

  You should make a note to the effect that funds are intended for the LaTeX3 effort.

• Free Software Foundation

  One FSF project that may be of particular interest:

  Display Ghostscript Project

  The Free Software Foundation and Net Community are seeking to raise $14,175 to fund the completion of Display Ghostscript - that is, extending Ghostscript to support the Display Postscript features. So far we have raised $8050, slightly over half of the target.

  If you would like to contribute, please send a donation to the Free Software Foundation and state that it is meant for Display Ghostscript. Note that DGS is to be the "base platform" on which GNUstep is to be implemented.

• Project Gutenberg

  Their purpose is to make freely available in electronic form the texts of books in the public domain. Most of the prize money from the recent RC5 Crack contest was contributed to this project.

• There may also exist "international branches" for some organizations.

  This includes the Czech Free Software Foundation.

  This brings up the point that things like tax deductibility of donations as well as the ease of sending contributions can vary based on what country one is in. There is value to having multiple organizations for this reason alone.

• Other Free Projects

  There are a variety of other free software projects that are probably worth investigating too, some Linux-related, others not.

  • Andrew Consortium
  • Arjuna Project
  • Project Athena
  • EXODUS Database Toolkit Project
  • FreeBSD
  • Geometry Center
  • Project GINA
  • GRASS (Geographic Resources Analysis Support System)
  • Icon Project
  • ISIS Project
  • Kermit Consortium
  • Linux Documentation Project
  • NetBSD
  • MALI (Memorie aux Langages Indeterministes)
  • NCSA (National Center for Supercomputer Applications)
  • OpenBSD
  • Project Oberon
  • Postgres Project
  • Scorpion Project
  • SR (Synchronizing Resources) Project
  • TET (Test Environment Toolkit) Project
  • World Wide Web Consortium
  • Wine Project
  • WAIS (Wide Area Information Server) Project
  • X Consortium
  • x-Kernel Project
  • Yale Haskell Project

Build Needed Software

It's pretty obvious that code doesn't simply "get written". There need to be authors of new software.

Eric Raymond's article, The Cathedral and the Bazaar, describes the widely cited "Linux Bazaar Approach" to software development.

It can be simply characterized with three principles:

• Release things (whether code or documents) publicly on a regular basis, and
• Accept contributions so as to expand the "developer base".
• Make sure that this can all happen in an asynchronous fashion so that many people can participate in improving systems.

The Linux kernel typically has a more-or-less weekly release, whether it's ready or not. It has accepted patches from thousands of people. This huge body of participants has become a tremendous strength.

With a growing world population of Linux users, expanding that strength to encompass other system components such as compilers, libraries, utilities, applications, and even documentation allows us to harness the "smarts" of potentially millions of developers of one variety or another.

Ten thousand developers looking at the kernel is quite enough to keep it improving even if most individually only examine small portions of the code in their spare time.

Coordinating efforts in the wake of there being literally millions of participants requires a truly distributed approach. "The Bazaar" has proved to be a potent approach for software development.

The difficult thing that needs to happen is for there to be some compromises in the interests of unity.

• First and most important: Check your ego at the door.

  It doesn't matter if you're right if, at the end of the day, the project fragments, and development ceases.

  Many failed projects have resulted from the situation where egos have collided. This appears to be one reason why "BSD Lite" fragmented into three projects. This is quite clearly why there are two versions of the Emacs text editor. It is abundantly clear that this is the cause for the proliferation of GUI toolkits for X. It seems to be a reasonable generalization that many people would rather build a new GUI toolkit than use one that someone else wrote.

• Before starting a new project, consider adding the functionality to some existing system.

  If the system designs are reasonably compatible, it should require less work than starting from scratch, and benefits from the fact that you know there already are some interested users.

  This is strongly related to the "ego" issue; if you're unwilling to allow others to attach their code to yours, or to attach your code to theirs, then effort will be duplicated.

• If you are creating a new software system, make sure it is designed so that will be easy for others to insert additional functionality.

  Consider, for instance how the principles of the UNIX Philosophy apply to your application. You may have the perfect design, and can create a perfect, beautiful, monolithic C++ email application that does anything anyone could ever imagine, and is far faster and cleaner than other mail systems. Don't do it, unless you at the very least export some powerful interfaces to allow outside programs to control your program.

  Had EZ had been written in a fashion that made it easy for programs outside its project to interface with it, it might have become the Linux Word Processing application.

  Unfortunately, Java 2000 or some other fancy new tool may come out next year and cause people to forget about your beautiful but essentially unexpandable mail client. The EXMH mailer builds on the MH mailer and permits people to link in TCL code allows them to add in linkages to the new "Java 2000" language, the "PGP 6.0" cryptograp= hical toolkit, or whatever else comes along next year. Therefore EXMH will undoubtedly continue to be in use in 2002. It may (arguably) be uglier and slower than the mailers recently written using whatever tools are "new and cool," but it is likely to persist while they are replaced next year by something else that is "newer and cool".

• Pick your libraries carefully. There are entirely too many X toolkits out there, and far too many battles about which is the right one to use. The ability of X to simultaneously accomodate multiple GUI systems means that adopting a new GUI does not necessarily mean having to change or discard any existing programs.

  I don't know for certain which GUI system is best. Of those getting a lot of attention:

  • Qt seems technically good, but isn't considered "free enough" for use with freely redistributable applications, and appears strongly tied to C++;
  • Motif has similar similar licensing issues to Qt, and appears to require substantial effort to write programs;
  • Tk offers "ease of programming," and is licensed such that it can be used and reused to produce either commercial or free applications, but is (arguably) slow and due to multiplatform support must limit users to a "lowest common denominator" set of functionality;
  • Gtk seems pretty good, and uses the LGPL (Library GNU Public License), thus allowing it to be freely used in source and binary form without forcing any restrictions onto applications that use it. Too bad some people think it's written in Scheme, and that this would be an inherently bad thing.
  • GNUstep (also LGPLed) seems like it may be neat if it is ever completed, but seems limited to use with Objective C, and its proponents come from the Apple/NeXT traditions and seem rather "preachy" about what they seem to consider The One True GUI.
  • Berlin, which might someday become available, also offers yet another One True GUI.

  Other peoples' milage may vary, which is precisely why there's not likely to be One True GUI Toolkit, and why there is a lot of flaming about it. Which returns us to the ego issue.

• Flaming at people that build poor designs isn't usually very useful.

  I have been gradually toning down my criticisms of the Berlin Graphical Environment. The Berlin Consortium opened up the design process somewhat, which was a wise idea. They have recently reorganized and many of the things they intended to develop have been made part of the underlying GGI infrastructure.

• Some relatively closed projects probably need to open up to use The Bazaar development approach.

  I am aware of half a dozen different efforts ongoing to create Linux-based personal finance systems. Were some of the teams to combine efforts, cutting the number to (say) 3, use some of the "additional staff" managing things via the "Bazaar" approach, and then take advantage of increased publicity, functionality and robustness would probably grow faster than it does now.

  For instance, significant efforts are presently going into CBB, xacc, and WaterMark. This is rather wasteful, as all three programs attempt to duplicate largely the same set of functionality from Quicken.

Providing Information/Linux Support

If you aren't a "software developer," it may be reasonable to contribute to general as well as specific support efforts. Here are a few ideas:

• Help design certification programs.
• Get "certified."
• Install a Linux server at a local school to provide mail, news, Web, and file server services. The ultimate goal may be to make Linux be the "complete" solution; it's critical to at least start with something.
• Help someone install Linux. My local users group, NTLug, has a monthly "Linux Installation Project" at a local computer show.
• Answer a question on Usenet (correctly).
• Contribute to a HOWTO document to the Linux Documentation Project.
• Write an article for the Linux Journal or the Linux Gazette.

Sources of Inspiration in The Growth of "Free Software"

The earliest references to "free" software can be found in Richard Stallman's The GNU Manifesto.

The Perl community has produced a document looking at "freely available things" entitled Information Wants to be Valuable that takes a somewhat different perspective.

Another paper that is well worth reading in analyzing the adoption and nonadoption of systems is Lisp: Good News, Bad News, and How to Win Big "Worse is Better". Its thesis is that while LISP provides extensive functionality, typical LISP-based attempts to provide "100% solutions" fail because the UNIX principle of looking for the 90% solution provides something "good enough" more quickly.

This may be further extended to the notion that Good Enough is Best. That essay makes the conclusion that Windows NT is "good enough," and will probably win the "OS Wars". That of course assumes that NT is in fact "good enough," which often stirs up controversy.

Inspiration for ideas in this essay can be traced back to Eric Raymond's The Cathedral and the Bazaar paper. Both Eric Raymond's "Cathedral/Bazaar" paper and this one were recently cited in Technology News from Wired News in connection with the recent reports that Netscape Communications Corp plans to make sources to Netscape Navigator/Communicator freely availableunder a license similar to the GNU Public License.

As a result of Eric Raymond's discussions with Netscape about how they might most appropriately deal with licenses like the GNU Public License, a group of advocates has come up with the proposal that the new term "open source" be used rather than "free software" to more readily draw corporate interest.

The English word "free" is unfortunately very ambiguous, which is a problem that proponents of "free software" have to wrestle with almost continually. "Free" has two main meanings, both of which can separately apply to "free software":

• Free of cost (the French "gratuit")

  Those that are new to "GNU Public License" software first think of this aspect. If you don't have to pay for something, many consumers are quite happy. In contrast, corporate users are concerned by the lack of cost, as it suggests to them a lack of support and a lack of value.

• Free of restrictions (the French "liberte," which corresponds to the English word "liberty")

  To developers that wish to create derivative works, this aspect is far more important. While the software may be "free of charge," if you are not at liberty to use it as you wish, then it lacks this critical aspect of freedom.

There are already two documents detailing what "Open Source" means, and why it is a good idea.

• "Free Software" is dead; long live "Open Source" by Eric Raymond, and
• Debian "Open Source" Definition

Credits

A document like this does not just happen by chance; it has certainly built in general on the past work of many people who have contributed to efforts to make Linux useful.

Thanks in particular go to the following people who have contributed comments, suggestions, and corrections to make this document better:

• Brian Bartholomew
• Kendall Clark
• Nathan Myers
• David Parsley
• Russell Nelson
• Kragen Sittler
• Michael Stutz
• Michael Tiemann
• Anonymous referees from First Monday.

About the Author

Christopher B. Browne is a Consultant with The Sabre Group. He formerly was a Systems Engineer for SHL Systemhouse in Toronto. A graduate of the Universities of Ottawa and Waterloo, he has been working with Linux since 1993, and involved in the Internet from UNIX and UNIX-like platforms since 1985. E-mail: cbbrowne@hex.net
WWW: http://www.hex.net/~cbbrowne/

Copyright © 1998, ƒ ¡ ® s † - m ¤ ñ d @ ¥