The /org directory is the second of the three main branches of the objectroot filesystem hierarchy (the other two being the /hosts and the /users branches).

The /org root and its subdirectories (“org trees”) is the installation location for all application and system software: executables, libraries, scripts, source code, documentation, man pages, fonts, e-books, images, data sets, etc. Anything a software publisher might choose to publish, including types of data that haven't even been invented yet.

There is no logical distinction between software that comes bundled as part of an “operating system distribution” and software packages that might be installed later (locally). It all goes in here, organized by publisher.


Software produced by the Apache Software Foundation.


Software published by Apple Inc.


Software developed and published by Daniel J. Bernstein.


Software produced by the FreeBSD Project.


Software developed by the GNU Project.


Software published by Google Inc.


Software developed and published by the Independent JPEG Group.


Software created by the KDE Community.


Software developed by the Linux Project.


Software produced by the NetBSD Foundation, Inc.


Software produced by the OpenBSD Project.


Software published by the Perl Project and the Comprehensive Perl Archive Network (CPAN).


Software published by the PHP Group.


Software ported from the Plan 9 from Bell Labs research system.


Software published by the Python Software Foundation.


Software governed by the X.Org Foundation.


Software developed by the Xen Project.


Software published by publisher.  [ More ... ]

[ For a description of the organization of the contents of a typical org tree, descend to /org/publisher/. ]


The primary reason for organizing all software in publisher specific subtrees is security. If a command is distributed in binary form only, or is otherwise untrusted, it can be executed chroot /org/publisher/.

Execution in a chroot jail, while inherently a restrictive measure, also means that the publisher can be given a little more leash. For example, the publisher may be allowed to “phone home” to check for updates or otherwise access the network. The tree then, figuratively speaking, serves as the publisher's “embassy” on the local system.

Alternatively, if the command is not trusted to access the network, it can be run as a black box with network access disabled. But here, again, the command does get access to all the files under the publisher's own org tree, which may include other software packages it may be able to take advantage of in providing its functionality.

Name space autonomy

Another important reason for the org tree model is name space autonomy. The publisher has sovereign control over everything that goes under /org/publisher/. This includes the naming of software packages and commands with no regard to whether the same name is already used by another publisher.

It is then up to the system administrator (or system packager/distributor) whether to honour that naming choice when mapping the command to the common user environment.

Processes that need to be able to unambiguously refer to a specific command from a specific publisher can always do so by using the full canonical pathname, even specifying a version number if needed.

The name of the org tree itself, i.e. the moniker identifying the publisher, of course needs to be unique. But coordinating publisher IDs is a much easier task than trying to prevent collisions in command and library names, something which experience has shown to be—as Stephen Fry might put it—“both difficult and impossible.”

Credit where credit is due

The org tree architecture naturally addresses the GNU/Linux naming controversy and other similar “crediting hazards.” Organizing all software in publisher specific trees makes it unambiguously clear who is providing what to the mix.  Just execute the command

ls -l /users/common/cmd

and see where the symlinks point. Or type

du -s /org/* | sort -nr

to list all publishers in descending order based on the total size of their contributions.

Political agnosticism

Some people insist that their computer only run software springing from certain political or philosophical ideals—say, software licensed under the GNU GPL license. Others prefer other ideals. The rest don't care one way or the other.

In some cases, this requirement for “software purity” has served as the motivation to compile and bring to the market whole new operating system distributions. This seems to be at least partly misdirected energy, for so much of the work involved is not pertaining to the philosophical goal, but is redundant administrativia and duplicating the general structures of an OS installation.

The tendency to see the operating system as an amalgamated whole, rather than as a collection of swappable components, is at least partly due to the traditional type-oriented filesystem hierarchy.

The org tree architecture then makes it easier to see the bare bones structure of the system as politically agnostic, where it is only the selection of org trees that determine its nature, politically and technically. Then, even in the case of a pre-installed system, if the administrator is not happy with the stances of a particular software publisher, all they need to do is

rm -r /org/publisher/

and then, perhaps, install another publisher's org tree for use in its stead.

Disclaimer: The organizations and individuals listed above are a random sample of software publishers currently active in the open source software arena. They have been listed here for the purpose of illustration only (using actual rather than fictitious names makes for a more understandable example). These organizations and individuals have no special role or status with regards to the objectroot concept. Nor have they in any way endorsed this proposal or website. The names are used here without permission.