Re: GNOME Namespace Management - ARC & GNOME

[John Plocher <john plocher sun com>]

+-- Brian Cameron:
| But there are some potential stumbling blocks.  For example, Sun's ARC
| documentation is in Sun's documentation formats
| +-- Murray Cumming:
| | Short examples of the visible output would be helpful here
| +--
+--

Back in June 2001, Nils Pedersen sent out an overview message that
described Sun's review process in some detail.  I'm including a
reference here as it may provide some helpful context:

    http://mail.gnome.org/archives/gnome-hackers/2001-June/msg00082.html
and
    http://developer.gnome.org/dotplan/archreview/20questions.html

The process that Sun uses starts with a proposal to make some change
to a component.  As Brian and others have noted, this submission
triggers a set of questions and decisions that, in as much as they can
be answered or made early, dramatically affect the risk involved
and the quality of the result.

Sun uses a template called (somewhat optimistically) a "1-pager" to
describe a proposal.  It is intentionally similar to an evaluated
bug report; the two can be considered equivalent for this discussion.
Like bug reports, proposals can be as short or long as required; about
80% of the proposals reviewed by Sun's ARCs are simple and short enough
to be reviewed informally; the remaining 20% take more time and effort,
and typically require the inception and commitment reviews mentioned
by others.

A 1-pager asks for certain contextual background information in
addition to the technical details so that its various consumers
(see below) can easily evaluate it  (a full example is at the end
of this message):

		1. Introduction
		   1.1. Project/Component Working Name:
		   1.2. Name of Document Author/Supplier:
		   1.3. Date of This Document:
		   1.4. Name of Major Document Customer(s)/Consumer(s):
		   1.5. Email Aliases:
		2. Project Summary
		   2.1. Project Description:
		   2.2. Risks and Assumptions:
		3. Business Summary
		   3.1. Problem Area:
		   3.2. Market/Requester:
		   3.3. Business Justification:
		   3.4. Competitive Analysis:
		   3.5. Opportunity Window/Exposure:
		   3.6. How will you know when you are done?:
		4. Technical Description:
		5. Reference Documents:
		6. Resources and Schedule:
		   6.1. Projected Availability:
		   6.2. Cost of Effort:
		7. Prototype Availability:
		   7.1. Prototype Availability:
 		   7.2. Prototype Cost of Effort:

Getting back to the consumers of these proposals, we have:

	o product "steering" teams that ask "do we want this
	  change, and if so, when should it go into a product?"

	o developers on other parts of this product as well as
	  those on other products, so that there is transparency
	  as well as an ability to detect duplication of effort
	  and to plan for future interactions.

	o architectural review committees that ask "is this the
	  right way to do this change?", with a scope that includes
	  understanding the risks and impact that this change may
	  have on other products, both now and in the future.

	(note that at Sun, as in the community, the above consumers
	 are not always explicit teams, but rather conceptual roles
	 filled by the people who actually do the work)

	o program managers, documentation teams, legal review teams
	  and other "downstream" consumers who might need to react
	  in some way to this particular change.

If Sun were to export these proposals "as-is" to the community, it
would need to scrub the confidential bits (like "3. Business Summary"
and maybe internal "1.5. Email Aliases:") first.  Nevertheless,
the rest of a proposal content is pretty tame and should not pose a
significant barrier to distribution.

Nils' mail (above) refers to a technical spec ("20 questions") that
is used as part of the architectural review to help make sure the
project team has thought of the (seemingly ever growing) list of
issues that seem to trip up other teams.  Sometimes these technical
specs include business justifications for technical details; it
may be that the right thing to do is for Sun to simply not put
the business details there in the first place.

This all is just to say that we (Sun) need to make sure we doesn't
"obsorne" ourselves by exposing early planning info to our
customers in ways that may set unfulfillable expectations.
(i.e., not all proposals actually make it into products, projects
change between proposal and integration, salespeople will promise
*anything* to make a sale, ...)

Even though it seems that all of us from Sun are long-winded, I hope
that I have provided some useful visibility into Sun's ARC process
and its artifacts.

   -John


John Plocher
Sun Microsystems CTO Group
Development Process Architecture


-----------------------------------------------------------

For reference, here is Sun's original "GNOME 2.0 for Solaris" proposal
from back in November, 2000, with a bit of pruning [marked by "XXX"] to
remove confidential items.  Note that a proposal of this large scope could
be seen as some sort of a "syntax error" - in a more perfect world there
would be dozens to hundreds of proposals for all the things that might
go into a component as large as "GNOME.next", instead of a request coming
at the end of development that proclaims "here is what we did, take it
all or leave it".

It probably is not worth commenting on this proposal's actual content,
as it is extremely dated; like most proposals, it was intended to
have a short lifetime and be replaced by other documents (specs, other
proposals, ...) over time.

-----------------------------------------------------------
1. Introduction

    1.1. Project Working Name:

        GNOME 2.x on Solaris

    1.2. Name of Document Author:

        XXX Internal email of a Sun Employee XXX

    1.3. Date of This Document:

        10th November 2000

    1.4. Name of Major Customers:

        Waterford/Power-Client Steering Commitee
        LSARC

2. Description

    2.1 Project Description

        The GNU Network Object Model Environment or GNOME is a
        main-stream open-source project with the goal of developing a
        complete easy-to-use desktop environment for UNIX X/Windows.

        There is a growing body of evidence that suggests that GNOME
        will be a popular desktop for users and developers alike. Some
        reasons for this include:

        - a growing number of contributors are making contributions to
          GNOME to fill feature gaps relative to mainstream desktops
          such as CDE and Windows 2000

        - commercial companies including Red Hat, Eazel, Red Flag and Ximian
          have committed significant development resources to creating
          and enhancing technologies and end-user applications; IBM,
          SGI and HP are making open-source contributions that may be
          used within GNOME

        - the establishment of the GNOME foundation provides a mechanism
          for commercial companies and key open-source contributors alike to
          resolve important questions of strategic direction

        - there is a commitment to establishing stable API's for each
          major GNOME release that will supported in future releases

        - GNOME has a more advanced native technology base than CDE,
          which may be valuable to ISV's: examples include a high-
          performance CORBA ORB, a component object model (Bonobo),
          an XML parser, a lightweight but powerful graphical API (Gtk+),
          many powerful Gtk+ widgets, an application framework
          (gnome-libs)

        - GNOME has a wide selection of applications, some of which are of
          high quality

	- GNOME offers an attractive modern user interface; it's rich
	  widget set and powerful component object embedding technology
	  allow the desktop and it's applications to offer an enhanced
          user experience

        - last and not least, all important API's in GNOME have C
          bindings and are released under LGPL, which together with
          the commitment to interface stability will ensure a stable
          ABI that can attract open-source and commercial ISV's alike.

          The goal of this project is to create a fully supported Sun-branded
          distribution of GNOME, which will become our default desktop
          and our primary native desktop development platform for ISV's.

          Sun's efforts will be primarily in the areas of:

          - Solaris porting, installation, performance and quality
          - interoperability testing against Sun/iPlanet's strategic
	    servers (mail, calendar, directory).
	  - making key GNOME technologies ready for use in enterprises
	    (especially in the areas of configuration management and
	    administration)
          - enhanced internationalisation of key GNOME technologies
          - creating an accessability framework for GNOME's primary
	    GUI API, Gtk+
          - assisting the community to achieve consistent high standards
	    of HCI design for the GNOME desktop and applications
          - creation of a coherent printable user guide and investment
            in raised documentation quality
          - high-quality localisation of user-interfaces and both online and
            printed documentation, in line with Sun's l10n big rules
          - end-user CDE to GNOME migration tools
          - creating a Sun-branded look-and-feel for the desktop

    2.2 Risks and Assumptions

	  Sun will have some influence over decisions, but is just one
	  important partner in the open-source GNOME project. This is
	  an unprecedented step for Sun. There is a risk that we cannot
	  accept a decision made by the community, which would require
	  that Sun forks some portion of the GNOME project for
	  distribution with Solaris. Membership of the GNOME Foundation
	  will provide a forum for raising issues of importance to Sun.
	
	  There is a risk that GNOME's broad native API set and CORBA-
	  based technology will cause uncertainty about the Java platform
	  and Sun's commitment to XML-based middleware.
	
	  GNOME is developed by a wide number of contributors with differing
	  needs and commitments which makes it difficult to establish
	  a reliable release schedule; further, there is little opportunity
          to synchronise GNOME releases with Sun's preferred schedule
	
	  With open-source software (especially GPL and LGPL as used for
          most GNOME-related source) there is always a risk of license
          contagion.

	  With sizable open-source software projects, it is difficult
	  to manage dependencies even within the project; Sun wishes to
	  increase the amount of open-source libraries installed with
	  Solaris and there is some overlap with libraries used in
	  Netscape. If one open-source package requires a different
          version of an installed file, installation and run-time
          behaviour would become complex and consume more resources.

	  There is a risk that Sun's ISV's will not adopt GNOME, either
	  because it is one desktop change too many or because they are
	  not convinced that the GNOME project will be a success.

	  Windows has provided a relatively evolutionary model for
	  look-and-feel and API's.  By comparison, Sun's adopt-and-drop
	  model for desktops has been challenging for end-users and
	  ISV's alike. Sun's success with GNOME depends on migration
	  and adoption being straightforward and on it being the right
	  choice for a longer period than previous desktop
	  environments.

3. Business Summary

   3.1. Problem Area

	The Common Desktop Environment (CDE) is a highly stable environment
	for end-users but it has become visually outdated.

	XXX evaluations of Sun components removed XXX

   3.2. Market/Requester

        XXX and Market Development have clearly identified
        the need for a modern power-client desktop environment with
        advanced technology for building component-based applications.

	Sun's customers have already begun using open-source desktops such
	as GNOME and KDE; GNOME is more attractive for the reasons given
	in the project description.

   3.3. Business Justification

	GNOME is new, with a more modern look-and-feel. It has attracted
	many open-source developers, it's Gtk+ graphic UI toolkit is
	easy-to-use and powerful.

	GNOME has some potential to succeed where CDE failed to create
	a common desktop environment and a united developer platform for all
	UNIX X/Windows environments. Sun's investment in GNOME ensures that
	Sun's customers can benefit from the widespread energy invested
	in enhancing GNOME, while ISV's are given a single target for
	developing UNIX applications, especially for Solaris and Linux.

   3.4. Competitive Analysis

	CDE and OpenWindows provide stable environments with essential
	desktop features, but they are clearly outdated in terms of
        user experience and ease of use.

        KDE is currently more advanced in some areas and is historically
	more stable than GNOME, but it is based on a collection of C++
	API's which makes it impossible to provide a compiler-neutral
	ABI for ISV's.

	KDE has historically been less clear-cut in it's adherence to
	open-source license, most visibly for the Qt graphical toolkit,
	and although recent changes make this more open-source , there
	is no clear separation between an LGPL (thus commercial
	ISV-friendly) technology base and GPL applications.

        Windows continues to be the benchmark for modern desktops. Microsoft
	has a 'monogamous' relationship with it's desktop
	XXX evaluations of Microsoft windows XXX

   3.5. Opportunity Window/Exposure

        It is intended to offer GNOME 1.4 to provide early exposure to
	Sun's customers within about 6 weeks of it being stabilised.
	GNOME 1.4 will be unsupported and ISV's will be recommended
	to target the GNOME 2.x platform.

	Considerable additional investment is needed in the areas listed
	above which will allow Sun to offer a Sun-supported GNOME 2.x
	within a number of months of the public availability of the
	Ximian GNOME release. The ultimate target here is to
	ship GNOME 2.x for Solaris 9, following the Solaris 9 primary
	scheduled dates; as noted under risks, the release date for
	the community GNOME 2.0 is outside Sun's direct control.

4. Technical Description

	[This section was empty when submitted, which was probably
	OK since the intent of this project was to "get Gnome into
	Solaris" and not "Produce Gnome 2.x". -John]

5. Reference Documents

        (1) Sun GNOME engineering web-site - http://XXX Internal Sun URL XXX

        (2) GNOME primary web-site - http://www.gnome.org

        (3) GNOME developers web-site - http://developer.gnome.org

        (4) Other commercial contributors:

	    * http://www.redhat.com - GNOME technology provider; ships
	      GNOME with the premier Linux distribution

	    * http://www.ximian.com - GNOME application developer,
	      primarily the groupware application Evolution; also
	      led by Miguel de Icaza, the leader of the GNOME project

	    * http://www.eazel.com - GNOME application developer,
	      primarily contributing the Nautilus file-manager and core desktop
	      UI, also offering GNOME-based web-services

6. Resources and Schedule

    6.1 Projected Availability

    6.2 Cost of Effort

	See Project plan.

    6.3 Cost of Capital Resources

	See Project plan.

7. Prototype Availability

    7.1 Prototype Availability

	GNOME 1.4 is an early-access version of GNOME; release date is
	not finalized, availability for Sun customers could be
	end Q2 CY2001.

    7.2 Prototype Cost

	15 person years.