AN OPPORTUNITY EVALUATION ABSTRACT We propose a new project whose ultimate aim is to develop a Layered Athena product. In this OE, we seek approval from ACS, CSS and DCNS to agree to develop the requirements for such a product. To that end, we will need a team with members from each of these departments. We include in this OE a brief description of the customer for this product, as well as the benefits that we expect to get, and the deliverables we expect to need to produce along the way. A process for gathering the requirements is suggested. BACKGROUND There has been much talk of layering Athena on vendor operating systems, but up until now we have not really addressed this. We must take the opportunity now to do this as an independent project rather than be forced into it by small decisions made while porting the environment to new platforms. CUSTOMER The customer we are targeting in this project is the person who has purchased a Unix workstation with their own money, or from a departmental or sponsored research account. Layered Athena on such a private workstation means giving the workstation owner the option of what parts of Athena to install. There are a spectrum of possible layerings, from a pure vendor OS to the current Athena model to copying the entire system pack and some lockers to the local disk. The workstation owner needs local control over where on this spectrum his workstation falls and how and when it receives updates. One extreme model that may prove popular is where the workstation owner is not involved at all, but a user without any privileges temporarily does what is necessary to use Athena services. Thus the technical sophistication of the customer might vary quite a bit from site to site. BENEFITS We believe there are a number of benefits derived from doing a Layered Athena project: First, it will help us complete new platform ports easier. Second, it will allow us to deal better with a source-code free world for client platforms (although not necessarily for servers). Third, it will allow us to expand the use of Athena into departmental clusters and labs that do not want to give up their local control. Fourth, it will lessen the amount of time our support people spend with each special workstation configuration (although this may prompt more specials that result in an ultimate increase in support load). Finally, it will also make it easier for us to export Athena services outside of MIT, increasing our profile in industry. DELIVERABLES OF THE WHOLE PROJECT To achieve these benefits, we must do several discrete things: First, we need to develop tools that work with a workstation configuration definition which specifies what software is desired, what versions of that software, and when it can take updates. This configuration (possibly a file on the local workstation, possibly in a central database for safety) must be under the control of the workstation owner. The Layered Athena project should progress in parallel with Tom Coppeto's project that is aimed at making it easier for Sun workstation customers to configure for network use. In the end, the tools developed in these two projects should dovetails nicely. Second, we need to decide how to partition Athena into pieces that can be chosen and how to encode this partitioning in the release. We will need to figure out how this interacts with the current mechanism for updating the release in the public clusters. Third, we need to consider how this affects use of licensed software here and how we can make sure we do not violate our licenses. This also impacts how people pay for "Athena system software" if this makes it very easy for people to obtain our software. To simplify the problem somewhat, we should first develop a product for a single vendor operating system that we understand well and are not in the middle of porting. We suggest that Ultrix would be a good choice for this. Only after we have a working prototype should we consider multiple platforms and folding it into next summer's release, if that is called for. DELIVERABLES FROM NEXT PHASE -- REQUIREMENTS First, we need to gather requirements in two areas: technical/functional requirements, and service requirements. Note that the explicit inclusion of service requirements is a minor change to the "orange" process, and the way we have done some recent projects. We have become increasingly aware of the need to be more explicit about developing at least draft versions of the support and service plans earlier in the development/product process to ensure that the products we develop are the "right" products. NEXT STEPS Clearly, this project needs to be evaluated from more than just the DCNS perspective. To that end, we propose that the Directors of ACS, CSS and DCNS, in conjunction with their managers, discuss this OE, and if all agree to move ahead, to assemble a small team to deliver the deliverables discussed above for the requirements phase. We propose that the technical/functional requirements gathering process not be based on starting from scratch, but rather on a set of requirements that have been bubbling up around Athena & DCNS for a long time. We propose that these requirements, as well as the support requirements, be passed around broadly for comment, including potential customers. Before we proceed to design, implementation and delivery, another decision by the Directors mentioned above would be required. In general, we don't expect this project to require a major investment of resources, although calendar time will be somewhat longer obviously. We believe that the proposed technical/functional requirements could be ready for distribution shortly after this OE is approved, and a team is assembled. During the open review/comment period, which might last for about a month, we would contact key customers and hold an open forum to get others' response to our requirements, and revise all of the plans as appropriate. At this point, our expectation is that a technical design might take a full week's effort over a month of real time by Mark and Richard. We don't have any estimates at this point about how long the design and development of the support elements will take, but those estimates should be developed during the requirements phase.