Today, Solaris ships many useful components under /usr/sfw. These components are classified as External; the Interface Taxonomy definition of External Interfaces are: These interfaces are controlled by a body outside of Sun, but unlike Standard, it can not be asserted that an incompatible change to the interface would be exceedingly rare. In some cases it may not even be possible to clearly identify the controlling body. This classification is typically used for community software, freeware, open source and the like. In PSARC/2000/487, PSARC required that the user "perform a simple but explicit act" to gain access to any interfaces with an External classification. The rationale for this requirement was to insure that the user did not inadvertently depend on a software component that did not meet the ``Sun Application Binary Guarantee''. Thus, any External component could not be found in the default search path[1]. Unfortunately, this was never explained to customers. What's worse, we also placed stable components in non-default portions of the user's path, including /usr/ccs/bin, /usr/openwin/bin, /usr/dt/bin and the like, so customers became used to adding directories to their path in order to access required functionality. Any implicit warning value in the non-default locations in /usr/sfw and /opt/sfw was thus negated. Since this policy was created, the situation has changed significantly. Rather than simply providing alternate implementations of existing Solaris tools, the components with External stability classifications now provide key critical functionality, including web browsers, entire desktops, etc; Solaris would not appear functional without these components. As a result this requirement is now perceived as a hindrance to Solaris users. With a large number of users having Linux experience prior to their first experience with Solaris, our delineation of interface stability levels using directories goes largely unnoticed, while the lack of the usual software facilities for the newly configured user is remarked upon. In addition, more and more users depend on the External functionality we ship in /usr/sfw, including our default web browser, bundled compilers, etc. This forces almost all sophisticated users to alter their shell search paths, defeating any "warning" provided by the location of the command. Given that our man pages for all commands and libraries clearly specify the Interface Stability level (another SAC requirement), forcing users to add additional directories to their path seems to add little to the safely of the user/developer, while needlessly frustrating the casual or exploratory user. It has also led to torturous ARC discussions regarding access to required functionality that has External interface stability, and has led to such absurdities as having a menu on the default desktop to launch Mozilla, but having Mozilla not be found when invoked from a shell with the default path in order to protect the user. This project makes no suggestion or proposal as to how the relaxation of this constraint might be practically expressed; that will be part of another case(s). This project proposal has only a single purpose - to generate an TAC-approved opinion explicitly removing the constraint expressed in PSARC/2000/487: The user of these interfaces should be required to perform a simple but explicit act to gain access to these interfaces. This is to further minimize that possibility that a user expecting the ``Sun Application Binary Guarantee'' will not accidentally use these interfaces. TAC review is necessary as the above requirement was explicitly added by Rob Gingell in his erstwhile role as Chief Engineer. In the absence of the above constraint, it is clear the ARCs will need to set new policies regarding which components are deemed suitable for inclusion in the default path. While this proposal doesn't suggest such policies, the following should be considered as part of drafting these policies: * This relaxation of a restriction is not an open ticket to install objects on the default paths or to modify the default paths. All such actions are subject to SAC/ARC review and are likely to require justification. * Due to extenuating circumstances, a small number of objects exporting External interfaces were allowed to install in the default path on the condition that other behavior be included to mitigate the situation. Most commonly, this was a first time pop-up such as required of some versions of GNOME and Mozilla. This case does not by itself allow the removal of these mitigating behaviors. Such removal is also subject to SAC/ARC review. * Clarification of the Interface Taxonomy by decoupling the source of a specification from the stability of the specification. Stability is purely a function of when the interface is allowed to change, which Sun always controls - we're always free not to take an incompatible change. * The ARC should encourage increased stability levels for core software classified as External and possibly for widely used objects (currently in /usr/sfw) which are widely utilized. We were essentially excessively conservative with the the use of the External classification; much of the software thus classified has not changed incompatibly at all in the last 5 years. This may be due to the fact that are External interfaces are incorrectly percieved to involve less maintaince effort than other interface types. * Core components which are primarily composed of External interfaces should probably contain at least a few Stable and/or Unstable interfaces. For many components a small number of such interfaces greatly increases the utility of these components. * Hiding useful commands in non-default locations should be discouraged - if it is worth shipping to customers, it's probably a good idea that they can find it. In particular, providing binaries in a normal menu from the GUI but hiding them in /usr/demo/jds as a way of indicating that these are unsupported demos seems pointless. If we need additional documentation or other mechanisms to indicate stability and support assurances, those should be called out - the filesystem name space is clearly not up to the task. References PSARC/2000/487 PSARC/2001/313/external.taxonomy [1] See sh(1) for the definitions of "path", "default path" and $PATH.