Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A tool is provided for addressing a number of issues related to
assembling software stacks including multiple uncoordinated components
such as open source projects. The tool identifies individual projects for
stacking, manages dependency relationships and provides an intuitive
graphical interface to assist a user. A project filter is also provided
for controlling access to or installation of projects in accordance with
filter criteria. In this manner, compliance with internal policies
regarding the use of open source or other software is facilitated. The
user can also add projects to the collection of supported projects and
define stack macros or stacros. Once such stacros are defined, various
functionality can be provided analogous to that provided for individual
projects.

Claims:

1. A method for use in connection with processing software components,
comprising the steps of: providing a computer based system for separately
performing operations in relation to identified software systems,
software applications, or software tools, said operations comprising at
least providing information about each of said software systems, software
applications, or software tools, wherein the information includes at
least one of licensing information, dependency information, or software
documentation information; establishing a stack including a plurality of
said software system, software applications, or software tools; and
operating said computer-based system to perform said operations of said
system in relation to said stack in a manner that is analogous to said
performing said operations in relation to individual ones of said
software systems, software applications, or software tools including at
least providing said information about said stack.

2. A method set forth in claim 1, wherein said operations further include
one of applying searching functionality, implementing synchronization,
and applying a project filter.

3. A method as set forth in claim 1, wherein said stack includes at least
one open source software project.

4. A method as set forth in claim 1, wherein said operations further
include installing said software systems, software applications, or
software tools.

5. A method for use in connection with processing software projects,
comprising the steps of: providing a computer-based tool for performing
operations related to stacking for a list of supported projects; first
operating said computer-based tool to add a project to said list of
supported projects; obtaining information for the added project including
at least one of licensing information, dependency information, or
software documentation information; and second operating said
computer-based tool to perform at least one of said operations with
respect to said added project.

6. A method as set forth in claims 5, wherein said step of first
operating comprises identifying said project.

7. A method as set forth in claim 5, wherein said step of first operating
comprises downloading said project.

8. (canceled)

9. A method as set forth in claim 5, wherein said operations include one
of providing project information, applying searching functionality,
implementing synchronization and applying a project filter.

10.-65. (canceled)

66. A method as set forth in claim 1, wherein said plurality of said
software systems, software applications, or software tools of said stack
are vertically dependent.

67. A method as set forth in claim 66, wherein said providing information
comprises providing information relating to vertical relationships
between ones of said software systems, software applications, or software
tools.

68. A method as set forth in claim 66, wherein said vertical
relationships comprise dependency relationships.

69. A method as set forth in claim 1, wherein said providing information
comprises providing one of restriction information and exclusion
information.

Description:

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority under 35 U.S.C. 120 as a
continuation of U.S. application Ser. No. 11/752,023 entitled "PROJECT
EXTENSIBILITY AND CERTIFICATION FOR STACKING AND SUPPORT TOOL" filed May
22, 2007 that claims priority to U.S. Provisional Application No.
60/807,588 entitled "PROJECT EXTENSIBILITY AND CERTIFICATION FOR STACKING
AND SUPPORT TOOL" filed on Jul. 17, 2006, and this application claims
priority under 35 U.S.C. 120 as a continuation-in-part of U.S.
application Ser. No. 11/556,094 entitled "STACK MACROS AND PROJECT
EXTENSIBILITY FOR PROJECT STACKING AND SUPPORT SYSTEM" filed on Nov. 2,
2006 that claims priority to U.S. Provisional Application No. 60/732,729
filed Nov. 2, 2005 entitled "STACK MACROS AND PROJECT EXTENSIBILITY FOR
PROJECT STACKING AND SUPPORT SYSTEM", the contents each and every one of
which are all incorporated herein as if set forth in full.

TECHNOLOGICAL FIELD

[0002] The systems and methods presented herein generally relate to
software projects including open source projects or projects that are
otherwise available for stacking and, in particular, to a tool for
assembling, installing and supporting or servicing software stacks. The
noted systems and methods facilitate the incorporation of additional
projects, stacks and supported platforms for use with such a tool.

BACKGROUND

[0003] Conventionally, packages of software have been formed from
proprietary applications. These applications have generally been provided
by a single source or by industry partners such that the applications
have been developed in a coordinated way to facilitate such packaging.
However, the assembly and use of such packages has generally been limited
by associated licenses. More recently, open source software has grown
rapidly in importance and availability. Generally, open source software
is software where the source code is available for copying and
modification and whose licenses generally give the user freedom to use
the software for any purpose as well as to modify and redistribute the
software. In this regard, open source software is distinguished from
proprietary software in that the source code of proprietary software is
generally not made available to the end user and the licenses for
proprietary software generally place significant restrictions on use,
copying, modification and redistribution. In addition, open source
software is generally made available for free or for a reasonable
reproduction fee whereas proprietary software is frequently provided on a
for profit basis. Open source software has a number of potential
advantages for end users. First, because the source code is available to
the end user and the licenses allow for substantial freedom of use and
modification, the end user has significant flexibility to adapt and
optimize the code for a particular endeavor. In this regard, the end user
is not tied into a particular proprietary system. In addition, studies
have shown that open source software tends to be of very high quality.
That is, due to the open nature of the software and the opportunity for
virtually unlimited peer review, the open source software is generally
continually improving in quality. Moreover, because the open source
software is generally available for free or at a nominal cost, there is a
significant potential to use the open source software in a cost effective
manner. For these and other reasons, many governments and other entities
have mandated or encouraged a transition from proprietary software to
open source software for systems under their control.

[0004] At the present time, however, significant obstacles remain with
respect to fully realizing the potential advantages of open source
software or other independently developed or uncoordinated software. One
such challenge is assembling software stacks. Typically, a software
system, application or tool ("project") does not function in isolation.
Rather, a particular project may require another project (e.g., open
source or proprietary) as a prerequisite to its proper operation and,
once installed, may be used by other projects. Because of these vertical
dependency relationships, end users often require or desire a software
stack including multiple projects. Moreover, a project may be subject to
certain restrictions prohibiting or limiting the installation or use of
the project in connection with another project (e.g., where another
version of the same project is already installed on the platform).
Assembling such stacks involves identifying individual projects required
for an endeavor as well as addressing the dependency and restriction
relationships. This may require significant expertise and time. Although
some open source providers offer coordinated projects or stacks, open
source software tends to be uncoordinated.

[0005] Another difficulty associated with the use of uncoordinated
software such as certain open source software relates to installation.
Installation involves addressing various machine configuration issues,
integrating software projects, resolving conflicts and testing for proper
interoperation of the individual projects as well as interoperation
between the projects and machine components. Again, installation often
requires significant expertise and time. In addition, there are a number
of post-installation issues relating to the use of such uncoordinated
software. For example, the use of any software may require occasional
reference to user manuals and other documentation. Such documentation may
not be readily available in the context of a stack including multiple
uncoordinated (e.g., open source projects) projects. Even when
documentation is available for individual projects, such documentation
may not be adapted for the environment of a particular software stack.
Similarly, training materials such as tutorials may not be available or
optimized for a software stack environment. Other post-installation
issues relate to uninstalling projects or altering installed projects or
stacks.

SUMMARY

[0006] The present invention generally relates to extending the
functionality of a system for assembling, installing and supporting or
servicing software stacks composed of multiple projects, including
uncoordinated projects. The projects are software components for
particular applications such as proprietary software applications and
open source projects. A stack is defined by installing two or more
projects in a processing environment (single machine or distributed) such
that the projects share one or more logical resources such as a function
library or are otherwise configured for cooperative and dependent
operation. That is, two projects have a dependency relationship where a
first one of the projects requires a project, such as the other (second)
one of the projects, to perform a function that defines a substantial
part of the first project's application. The projects are thus vertically
integrated. In this regard, uncoordinated projects are projects that are
not specifically preconfigured for such cooperative and dependent
operation in a stack. For example, such projects may be developed by
multiple parties working independently or by open source developers. The
invention facilitates extending the functionality of such a system, for
example, by adding projects, stacks or supported operating systems or
platforms.

[0007] In particular, a computer-based tool (e.g., a software tool) may
address a number of the above-noted issues relating to software stacks
including multiple uncoordinated components. The computer-based tool
facilitates stack assembly by identifying individual projects, managing
dependency and/or restriction relationships and providing an intuitive
graphical interface to assist the user. In addition, the computer-based
tool facilitates installation by addressing machine configuration issues,
resolving conflicts and performing at least partially automated testing.
The computer-based tool also addresses a number of post-installation
issues including the generation of appropriate documentation (or
provision of predefined sets of documentation) and training tools, as
well as by facilitating de-installation of projects as well as
modification of replacement projects and software stacks.

[0008] The computer based tool and associated methods (collectively
referred to herein as the "utility") provides for enabling convenient
access to stacks of uncoordinated software projects. Specifically, the
utility involves receiving an input regarding a stack of interest,
accessing information regarding potential stacks and outputting stack
information responsive to the input. From the perspective of a user or
user system, the utility involves accessing a system for providing stack
information regarding stacks of (formed from) uncoordinated software
projects, submitting an input (e.g., to a local processor or remote
platform) regarding a stack of interest and receiving stack information
responsive to the input. The stack information may include, for example,
an identification of the project content of one or more possible stacks,
projects for installation as one or more stacks, and/or installation
information for one or more possible stacks. In this regard, for example,
a stack or information defining a stack may be assembled from projects or
project information responsive to the input, or such stacks or
information defining stacks may be predetermined and stored. That is, the
stack information can be assembled at various times and in various ways.
In any event, convenient access can be provided to information useful in
assembling and/or installing stacks formed from uncoordinated software
projects, e.g., including one or more open source projects and even
proprietary source projects (e.g., proprietary software such as Microsoft
Office, Oracle database, and SQL Server, DB2, etc.).

[0009] The utility is useful in assembling stacks of software projects.
That is, the utility is useful in determining the project content of a
stack. It will be appreciated the utility may further be useful in
identifying and/or resolving conflicts, dependency and restriction
characteristics and other issues relating to assembling a stack. The
utility involves receiving input information regarding a stack of
interest (e.g., via the operation of the computer based tool) to
determine at least a first characteristic of a first project of the stack
and to provide information regarding a second project of the stack. The
input information may, for example, identify a function of this stack,
identify the first project for inclusion in the stack or otherwise
provide initial information for use in assembling the stack.

[0010] Based on this input information, the utility is operative to
determine the first characteristic of the first project. The first
characteristic may relate, for example, to a dependency or restriction
relationship of the first project or a resource requirement. In this
regard, the utility may identify one or more projects on which the first
project depends, one or more projects having a dependency that is
satisfied by the first project, one or more projects with which the first
project has a restriction relationship, or may relate to ports or other
resource requirements. This characteristic is used to provide information
regarding a second project of this stack. Thus, for example, dependency
or restriction relationships, conflicts and the like may be identified in
an output to the user or resolved so as to assist in stack assembly. For
example, one or more graphical user interfaces may identify dependencies
or conflicts to resolve in order to complete a desired stack assembly.

[0011] The utility can be used to facilitate assembly of uncoordinated
projects. In this regard, the first and second projects may be
uncoordinated and may include open source projects, proprietary projects,
other projects or combinations thereof. Preferably, at least one of the
projects in the stack operates at a tools or applications layer of the
stack above an operating system level of the stack.

[0012] According to another aspect of the present invention, a utility is
useful in assembling stacks by reference to a knowledge base including
information regarding a set of supported projects and interoperability
(e.g., dependency or restriction information). Specifically, the utility
involves identifying a set of software projects and determining, for the
set of software projects, a set of interoperability relationships
relating to interoperation of the software projects. A controller
includes logic for accessing information reflecting the interoperability
relationships and relating particular ones of the software projects based
on the interoperability relationships. In operation, the controller
receives a user input indicating an interest in assembling a stack of
projects and identifying, at least by type, at least a first project for
inclusion in this stack. Based on this user input and the
interoperability relationships, the controller identifies at least a
second project for inclusion in the stack. For example, a user may
indicate a particular function to be performed by the stack or a
particular project that the user is interested in using. In the case of
an identified function, the controller may identify project options
associated with the function from which the user can select a desired
project. In any case, once a project is identified, the stored
interoperability relationships can be used to identify prerequisite
projects, projects used by the first project and further associated
dependencies, as well as any restrictions. It will be appreciated that
such interoperability relationships may exist between first and second
groups of programs. In that case, each group effectively functions as a
project and the assembly of the groups defines a stack. In this manner,
the user can efficiently assemble a stack where interoperability
relationships are satisfied across the stack.

[0013] According to a still further aspect of the present invention, a
utility is provided for filtering projects in connection with a request
to access or use projects. It has been recognized that the ready
availability of externally developed projects is problematic for many
entities. In particular, in the context of open source projects, such
projects are readily available at no or a nominal cost. As a result,
personnel may sometimes access such projects without consideration of
compliance with license terms or company policy. Moreover, as noted
above, open source licenses can include a variety of terms and
obligations regarding reproduction or use of the open source software. In
many cases, entities may be unaware that such open source projects are
being used until undesired consequences have occurred. In this regard,
the utility may assist such entities in facilitating compliance with
policies developed by the entity.

[0014] An associated utility in accordance with the present invention
involves defining filter criteria relating to access or use of software
projects, receiving a request for access to or use of one or more
software projects and processing the request in accordance with the
filter criteria to provide an output responsive to the request. The
filter criteria reflect a policy affecting the requestor independent of
any rights granted by the providers of the software projects or lack
thereof. Thus, for example, the filter criteria may define what projects
may be accessed, by whom, and for what purpose. For example different
criteria may apply to different personnel (e.g., software developers, IT
personnel, accounting) and for different purposes (strictly internal use
versus incorporation into product). The filter may be implemented in
connection with a stack assembly and installation tool. In this regard,
graphical user interfaces may only present project options that are
appropriate for the person or purpose at issue or filtered projects may
be otherwise unavailable for selection in connection with such user
interfaces. In this manner, adherence to the entity's policy concerning
projects may be enforced. Projects may be filtered, for example, on a
project-by-project basis, based on a type of or category of the projects,
or based on a license association of the project.

[0015] In accordance with a still further aspect of the present invention,
a utility is provided for installing uncoordinated software. An
associated system involves a configuration module for configuring a
number of uncoordinated software projects into a stack and an installer
for installing the stack on a computer. For example, the configuration
module may configure the projects into a stack responsive to a request
from a user or a user system. In this regard, such a stack may be
identified with the aid of an assembly tool as discussed above.
Alternatively, the projects may be configured into a stack prior to
handling a specific request. Preferably, the stack is configured in a
manner that resolves interoperability issues with respect to the included
projects. In addition, the configuration module may take into account the
state of the machine on which the stack is to be installed in connection
with considering such interoperability issues or resolving potential
conflicts. From the perspective of a user or user system, the utility
involves submitting input information regarding a stack of interest to a
configuration module and receiving installation information. Such
installation information may include, for example, information regarding
an installation procedure, projects reflecting a configuration for use in
the stack and/or installation tools. The utility thus addresses a number
of problematic issues relating to installation of stacks formed from
uncoordinated projects.

[0016] In accordance with a still further aspect of the present invention,
a utility is provided for use in installing a stack of uncoordinated
projects on a machine or other system designated by a user. An associated
installer may be resident on the designated system or interconnected to a
system via a LAN or WAN. In addition, the installer may be operatively
associated with an assembly utility as described above or may operate
independently. The installer utility is operative to receive input
information regarding a stack of interest, determine at least a first
characteristic of a first project of the stack, and provide information
regarding a second project of the stack. The input information may, for
example, identify a function of the stack or identify the first project,
at least by type. In response to this information, the utility may
identify one or more projects having an interoperability relationship
with the first project or a resource requirement of the first project.
Since such information may be used to identify the second project so as
to resolve an interoperability relationship or avoid a resource conflict.
The utility is useful for installing stacks including uncoordinated
projects (e.g., open source projects) where at least one of the projects
operates at a tools or applications layer of a stack above an operating
system level.

[0017] In accordance with another aspect of the present invention, a
utility is provided for assisting with post-installation support in
connection with an installed stack of uncoordinated projects. This
support utility may be provided in conjunction with assembly and/or
installation utilities as noted above or independently. Moreover, the
support utility may operate in connection with a local system or may be
accessed via a network, e.g., the Internet. The support utility involves
receiving an identification of a stack including a number of
uncoordinated software projects, selectively accessing storage to obtain
support information specific to that stack and outputting the support
information to a user. The support information may include, for example,
a tutorial or documentation specifically tailored for the package.
Support information may be preassembled and indexed to the stack or may
be stored as separate chunks of information that are assembled in
response to a request. In this regard, documentation may be stored as
structured content, e.g., associated with metadata such as XML tags,
identifying a context or association of the data, for example, an
association with a particular project. Text and/or graphics may be
assembled in this regard. In addition, the support information may be
selected based on operating environment information for the stack such as
information relating to the machine of a user or operating system of a
user.

[0018] In accordance with yet another aspect of the present invention, a
utility is provided for managing updates in connection with an installed
stack of uncoordinated projects. It will be appreciated that updates
relating to a stack such as project updates, dependency updates and
support information updates may become available from time to time.
Managing such updates can be problematic, particularly in the context of
stacks of uncoordinated software projects. The utility of the present
invention involves receiving information regarding the availability of an
update concerning a stack, identifying a stack potentially affected by
the update, and providing update information to a user or user system.
The update information may include, for example, a notification to a user
that updates are available, updated software and/or installation
information. In this regard, an update may be automatically installed or
installed upon receiving an indication from a user that the update is
desired. Preferably, update installations are accomplished while leaving
at least a portion of the previously installed stack in an installed
state, e.g., without uninstalling one or more projects of the stack. An
associated update installation process may involve determining an
installation sequence, resolving any dependency or resource conflicts,
performing an installation of the update in accordance with the
determined installation procedure and testing the update upon
installation. Associated support materials may also be made available in
connection with the update.

[0019] In accordance with a further aspect of the present invention, a
utility is provided for enabling substitution of projects within a stack
of software projects. The utility involves receiving an input in relation
to an installed stack including a plurality of software projects and, in
response to the input, substituting for a first one of the projects a
substituted project having substantially equivalent functionality. It
will be appreciated that this utility is particularly, though not
exclusively, useful in connection with open source projects that often
have licensing terms that provide significant flexibility in configuring
stacks. For example, the utility may be used to substitute a second
database project in place of a first database project in a given stack.
In this manner, a user can experiment with different projects to build a
stack with optional performance for a given endeavor.

[0020] In accordance with yet another aspect of the present invention, a
utility is provided for managing licensing information. The utility
involves storing public information and private information concerning a
given software license; providing access to at least a portion of the
public information; receiving a request for access to the private
information; responsive to the request, verifying an authorization to
access the private information, and selectively providing access to the
private information based on the verification. For example, in connection
with a request to access the private information, a user may be prompted
to enter a password or other authorization information. Such
authorization information may be used to encrypt and decrypt the private
information so as to inhibit unauthorized accesses to such information.

[0021] In accordance with a still further aspect of the present invention,
a utility is provided for use in connection with processing software
projects. Specifically, the utility allows for the definition of stack
macros or "stacros" including a number of projects. Once such stacros are
defined, various functionality can be implemented analogous to that
provided for individual projects. The associated utility involves
providing a computer based system for performing operations related to
identifying software projects, establishing a macro including plurality
of software projects, and operating the computer based system to perform
at least one of the operations with respect to the macros. For example,
the operations may include providing project information (dependencies,
"used by" information, restrictions, exclusions and the like), applying
search functionality, implementing synchronization and applying a project
filter. It will thus be appreciated that a such stacros may encompass
functionality beyond a one-click grouping. For example, the macros may
provide an easy to use synchronization mechanism.

[0022] In accordance with another aspect of the present invention, a
utility is provided for enabling project extensibility. That is, although
the system of the present invention will generally support a large and
varied selection of projects, a user may on occasion wish to add custom
projects or projects that are otherwise not currently supported. These
projects may include open source, proprietary or other software. The
associated utility involves providing a computer-based system for
performing operations related to a list of supported projects, adding a
project to the list of supported projects, and performing at least one of
the operations with respect to the added project. In this regard, the
system may calculate a variety of information, for example, related to
exclusions or a chain of dependencies, based on limited input information
such as direct dependencies entered by the user. This information can be
used to augment the knowledge base and support a variety of
functionality. In addition, the system may use projects provided by a
number of varied sources for incorporation into a deliverable software
package.

[0023] In accordance with a still further aspect of the present invention,
a utility is provided for use in incorporating a new software project
into a stacking system such as described above. The utility involves
obtaining a project from a project source in native form, modifying the
project for use by the system, and storing the modified project for
access by the system. For example, the project may be obtained by
downloading the project from a source web site. The project may be
modified for use by the system in a variety of ways. For example, one or
more basic configurations for the project may be selected, and the
project may be configured in accordance therewith. In this regard, a
script may be utilized to modify configuration files. A script may also
be used to install one or more functional components such as a short cut,
a link, a menu item, a desktop item or an OS service. Additionally or
alternatively, the project may be modified by changing permissions for
one or more files, integrating the project with one or more projects
having a dependency relationship with the project, and/or associating
metadata with the project. Such metadata may relate to support
information, interoperability information and licensing information
regarding the project. The utility may further involve executing standard
configurations for the project and executing optional configurations
selected by a user.

[0024] In accordance with another aspect of the present invention, a
method is provided for certifying a project for use in a stacking system,
such as described above. The method involves selecting a project for
potential acceptance into the system, performing an acceptance analysis
to verify the selected project meets criteria for acceptance into the
system and, responsive to the acceptance analysis, installing and testing
the selected project. A project may be selected based on information
regarding needs of potential system users. For example, users may request
a project or an analysis of the needs of users may be performed. The
acceptance analysis may involve a variety of considerations, such as the
viability of the project, a legal analysis of the project, the
functionality of the project and/or a technical evaluation of the
project. In this regard, an analysis of the viability of the project may
involve obtaining information regarding a level of support for the
project or a level of maintenance for the selected project. In the latter
regard, the absence of recent updates may raise concerns regarding the
viability of the project. On the other hand, the existence of an
established group driving the project increases the chances that the
project will remain viable. The legal analysis may involve obtaining
information regarding one or more licenses associated with the selected
project. The licenses may then be analyzed to determine whether the
licenses are likely to be problematic for system users. In this regard,
the use of open source licenses that are well understood would be a
favorable factor in the acceptance analysis. Other licenses may be
analyzed and may be deemed acceptable. The functionality analysis may
involve verifying that the selected project has features that would be
expected in that project type and an analysis of a user interface
regarding usability.

[0025] The technical evaluation may involve one or more of various
considerations. For example, the evaluation may involve verifying the
selected project can be properly downloaded, e.g., a checksum analysis.
Additionally or alternatively, the technical evaluation may involve
verifying that the selected project is free of malware, such as Trojans,
viruses, worms or others, obtaining information regarding
interoperability relationships of the selected project, verifying the
selected project can be installed on at least one supported platform,
determining at least one basic configuration for the project, and
verifying that the project can be properly integrated with other projects
having a dependency relationship therewith. Installing and testing the
project may involve conducting an installation and configuration of the
selected project for each of multiple supported platforms. Additionally,
or alternatively, the installing and testing may involve integrating the
project with at least one other project.

[0026] In accordance with yet another aspect of the present invention, a
utility is provided for incorporating a software project into a stacking
system as described above. The utility preferably has an architecture for
allowing a client to submit extensibility requests without requiring
extensive specification of the target platform environment. The utility
involves providing a client for use in transmitting a request to
incorporate a project into the stacking system, where the request is
associated with a target platform for using the project. An agent
executes installation related operations on the target platform with
respect to the project. The utility further involves operating a nexus to
receive the request and identify a package, including the project, using
information regarding the target platform. The target platform
information is obtained from a source separate from the request. In this
regard, the nexus may be operative to transmit a message indicating
specific versions of components to use to satisfy the request where the
specific versions of the components are determined based at least in part
on the target platform information. The target platform information may
relate to, for example, a hardware implementation of the target platform
or an operating system of the target platform.

[0027] In connection with the various aspects of the invention discussed
above wherein the functionality of a stacking system is extended to
include an additional project (or set of projects such as a stack), the
projects may be obtained from project sources. Each of these sources or
projects may have unique licensing requirements. For example, certain
sources may provide open-source software with licenses that make source
code available under terms that allow for modification and redistribution
without having to pay the original author. Such licenses may, however,
have additional restrictions that, e.g., preserve the name of the authors
and any copyright statements within the code. Proprietary software, on
the other hand, often has restrictions regarding use and copying. The
prevention of use, copying, or modification of this software can be
achieved by legal means and such software is generally sold as commercial
software or, in some instances, is available at zero-price as "freeware".
Other forms of software may include "shareware" which may allow a user to
use the software for a certain period of time or use an inferior version
of the software. Additionally, shareware may allow the user to freely
distribute the software. Any of these software types may be added to the
stacking system, with due regard to any restrictions as noted above.

[0028] In accordance with the present invention, the system may include a
bundler that retrieves projects from the providers for configuration as a
software package. For example, an end-user of the software package may
have certain preferences for various projects. These preferences may be
communicated to the bundler such that the bundler may select projects
from the providers and configure those modules into a software package
that is usable by the end-user. Prior to incorporating the projects into
the software package, the bundler may check the software licenses of each
project to ensure compatibility. For example, the bundler may analyze
software licenses to determine whether a particular project may be
modified and/or configured for incorporation to a software package with
other projects.

[0029] Once a license of a particular project has been deemed compatible
with other projects, the system may calculate a variety of dependencies
used that link the individual projects into a single software package.
For example, the system may receive information pertaining to a
particular operating system for which a software package is intended.
Based on the operating system destination, the system may generate a
configuration file to which the projects are linked. Individual projects
may thereby take advantage of the operating system functionality and
operate within the parameters of the operating system. Additionally, the
system may reconfigure portions of the individual projects to properly
function with an intended operating system. That is, the individual
projects may be "stripped" of certain operating system dependencies
and/or reconfigured such that the projects may operate with operating
systems for which the projects were not originally intended.

[0030] Once a software package is built, a variety of tests may be
performed on the package to ensure its operability with the intended
operating system destination. For example, a software package may be
obtained from the bundler to begin a certification process that includes
testing the software package for operability with an intended operating
system. In this regard, the testing process may involve "stepping
through" various portions of individual projects (e.g., lines of code) to
ensure functionality of various software functions and routines of the
projects. For example, such testing may include verification of
functional outputs of a project to determine whether functions are
outputting desired data and, thus, operating as intended.

[0031] Additionally, the system may include a knowledgebase module. The
knowledgebase module may assist in the testing of a software package in
that test procedures may be retrieved from the knowledgebase module
without the need for developing individual tests for each destined
operating system. For example, the knowledgebase module may include test
plans and/or software that may be associated with a particular project.
The certification module may retrieve these test plans and/or software
may be used to automatically perform a test on the project.

[0032] Due to its less restrictive nature, open-source software is
frequently updated. For example, the open-source community includes a
variety of software engineers and programmers that regularly contribute
to various pieces of open-source software. This open-source community
also comments on deficiencies and/or problems with various pieces of
open-source software such that the software may ultimately improve. This
open-source community may also provide test plans to test individual
open-source projects. For example, each time a software package is to be
built for an intended operating system (e.g., according to an end-user's
operating system requirements), the knowledgebase module may be processed
for recent updates to projects and test procedures for those modules to
ensure compatibility with other projects and operability with various
operating systems. Upon a successful testing of the software stack (i.e.,
the projects thereof), the software package may be approved for delivery
to the end-user.

[0033] The knowledgebase module may also be configured to communicate with
the software package. For example, once the software package is delivered
to an end-user, the end-user will install the software package on a
computer. In this regard, the software package may be configured with
installation software, such as InstallShield by the Macrovision
Corporation that unbundles the projects of the package and prepares them
for operation with the operating system. Once installed, the projects of
the software package will operate with the operating system according to
their parameters (e.g., OpenOffice, an open-source suite of business
software, will control its various office software components while
operating within the parameters of the operating system). This
installation, however, is somewhat static in nature. That is, the
projects may be changed by the provider after installation of the
software package. To compensate for this, the bundler may configure the
software package with a communication protocol that enables the projects
to receive updates from the knowledgebase module. Additionally, this
communication protocol may enable an end-user to troubleshoot projects
(i.e., resolve operational problems with various projects after
installation).

[0034] The knowledgebase module is, among other things, a software tool
that enables communication with the various project providers and then
assimilates updates or changes in relation to supported stacks and
environments. That is, in addition to communicating with a software
package/end-users and the bundler, the knowledgebase module may
automatically check for software updates by the project providers. For
example, software providers routinely update their software upon
detection of defects (a.k.a., "bugs") and/or discovered improvements.
Some software providers automatically download these updates to their
installed projects (e.g., Microsoft Corp. has an automatic update feature
with many of its software programs that interacts/communicates with the
software programs once installed on an end-user's computer or "machine").
The knowledgebase module may be configured to automatically receive
updates and/or check for updates that may be available from the software
providers. The knowledgebase module may then transfer these updates to
the bundler (e.g., upon configuration of the new software stack) and/or
the software stack (i.e., upon installation of the software package with
the end-user's machine) to ensure that the software stack is current and
otherwise ready for addition to the supported library.

BRIEF DESCRIPTION OF THE DRAWINGS

[0035] For a more complete understanding of the present invention and
further advantages thereof, reference is now made to the following
detailed description taken in conjunction with the drawings, in which:

[0036]FIG. 1 is a graph illustrating the layers of an application
development environment;

[0037] FIG. 2 illustrates examples of proprietary applications at various
layers of the application development environment;

[0038]FIG. 3 illustrates the layers of an application development
environment including open source options;

[0040] FIG. 5 is a schematic diagram of a software stack assembly,
installation and support system in accordance with the present invention;

[0041] FIGS. 6-11 are examples of user interface screens that may be
provided in connection with operation of the system of FIG. 5;

[0042] FIG. 12 is a schematic diagram illustrating a project filter system
in accordance with the present invention;

[0043] FIG. 13 is a flow chart illustrating the operation of the project
filter system of FIG. 12;

[0044]FIG. 14 is a schematic diagram of a license management system in
accordance with the present invention;

[0045]FIG. 15 is a flow chart illustrating a stack assembly process in
accordance with the present invention; and

[0046] FIGS. 16-48 show user interface screens illustrating various
functionality in accordance with the present invention;

[0047]FIG. 49 is a block diagram of a system that configures software
packages for installation upon an end-user's machine; and

[0048] FIG. 50 illustrates a certification process in accordance with the
present invention.

DETAILED DESCRIPTION OF THE DRAWINGS

[0049] The present invention relates to extending the functionality of a
stacking system to include one or more new projects or stacks of
projects. In the following description, the invention is set forth in the
context of a particular stacking system that encompasses stack assembly,
installation and support functionality. It should be appreciated that, as
noted above, such functionality may be provided independently, rather
than as part of an integrated system, in accordance with the present
invention. Moreover, it will be appreciated that various aspects of the
invention have application beyond the specific context described below.
Accordingly, this description should be understood as exemplifying the
invention, and not by way of limitation.

[0050] In the following description, the application development
environment is first described in relation to the open source software
movement. This represents an illustrative application of stacking
uncoordinated projects. Thereafter, a system architecture in accordance
with the present invention is described. Specific functionality for stack
assembly, installation and post-installation support is then described in
detail. Finally, the functionality related to project extensibility and
certification is described.

I. The Open Source Application Development Environment

[0051] The present invention relates to a tool for use in assembling,
installing and supporting software stacks including, for example, stacks
that include one or more open source projects.

[0052] As noted above, stacks including open source projects are
particularly apt for illustrating the various aspects of the present
invention, as open source projects are typically uncoordinated and are
typically associated with licenses that provide significant freedom for
configuration in custom stacks. Indeed, the flexibility to modify and
combine such projects as desired is a principal motivation for the open
software movement. However, it will be appreciated that stacks may be
formed from proprietary applications or a combination of open source
projects, proprietary applications and other uncoordinated projects where
licenses allow. Indeed, it is anticipated that such combinations will
become increasingly common. In any event, the invention has particular
advantages in the context of forming stacks of uncoordinated software
components, i.e., projects or applications that are not preconfigured to
share logical resources such as function libraries or otherwise
specifically configured for cooperative and dependent operation in a
stack.

[0053] In the examples below, such stacks are described in the context of
an application development environment. In this regard, an application
development environment refers to a stack that includes at least one
project, that is, an application or a development environment tool,
operating above the operating system or hardware levels. This may be
understood by reference to FIG. 1. As shown in FIG. 1, a full software
development environment 100 generally includes an applications layer 102,
a development environment tool layer 104, an operating system layer 106
and a hardware layer 108. Generally, applications 102 are created by
using development tools 104 in a working development environment based on
a selected software operating system 106 that functions on selected
hardware 108.

[0054] Operating system software and development tools have historically
been sold by competing commercial vendors and the software is
proprietary. FIG. 2 illustrates a proprietary software development
environment 200 with examples of proprietary products at each layer. As
shown, the application layer 202 includes various commercially available
web-based applications, business applications and other applications. At
the development environment tool layer 204, commercially available tools
are provided by Oracle, BEA, Rational and others. The dominant systems at
the operating system layer 206 are Windows and Unix, though others are
available. Examples of manufacturers at the hardware layer 208 include
IBM, Apple, Sun, HP/Compact and Intel.

[0055] It will be appreciated that there is generally limited flexibility
relating to integrating stacks for the software development environment.
More specifically, existing operating systems provide an open platform by
which particular products can operate independent of the specific
hardware environment to a significant degree. Moreover, many products can
operate across multiple operating systems. However, at the application
layer 202 and development environment tool layer 204, options are much
more limited. Some commercial software developers provide integrated
stacks of multiple proprietary products or provide individual products
that can be readily integrated into a stack. Similarly, integrated open
source stacks or coordinated open source projects are provided by some
software developments. These products are developed much like the
corresponding proprietary products but have open source rather than
proprietary license associations. However, these commercial developers
generally have little incentive to accommodate interoperation with
respect to products of competing commercial developers. Accordingly, such
stacks may be limited to products of a particular commercial developer or
a developer and industry partners. Accordingly, an end user has limited
flexibility and may be locked into an overall stack environment due to a
need for a particular product.

[0056] Open source software, particularly Linux, has become widely adopted
for the operating system layer. In addition, open source development
tools and applications are emerging. FIG. 3 illustrates an open source
application development environment 300. That is, the open source
application development environment 300 includes at least one open source
project at the application layer 302 and/or development environment tool
layer 304. Proprietary applications may also be available and utilized at
these layers in the environment 300. As shown, an example of an open
source application at the application layer 302 is OpenOffice. At the
development environment tool layer 304, examples of open source tools
include Eclipse, MySQL and Apache. The illustrated environment 300
includes, at the operating system layer 306, one example of an open
source operating system (Linux) and one example of a proprietary
operating system Windows. At the hardware layer 308, a number of
proprietary original equipment manufacturers are identified. It will thus
be appreciated that a full open source application development
environment may include or support or allow for proprietary elements, at
the operating system and hardware layers 306 and 308 and at the
development environment and application layers 302 and 304.

[0057] As noted above, while many high quality open source projects are
available, there are a number of difficulties associated with the
stacking of multiple open source projects (alone or together with
proprietary products) to enable a full application development
environment. This is graphically illustrated in FIG. 4. FIG. 4
illustrates a number of open source projects and proprietary products.
The lines and arrow connecting the various components represent mandatory
and conditional dependency relationships such as prerequisites and
projects that may be used by another project once installed. A thorough
understanding of these dependency relationships is often necessary to
assemble an appropriate stack for a particular endeavor.

[0058] Moreover, considerable expertise and time may be required for
installation of a stack once assembled. For example, installation issues
may involve determining a proper installation sequence, addressing
various hardware issues, resolving conflicts and testing an installed
stack, for example, to determine that required files are accessible.
Post-installation issues involve providing appropriate training tools and
documentation as well as facilitating the installation and modification
of particular projects as well as stacks. These issues are addressed by a
system according to the present invention as described below.

II. System Architecture

[0059] FIG. 5 illustrates a software stack assembly, installation and
support system 500 in accordance with the present invention. The system
500 is operative to allow a user, operating a user machine 502 such as a
personal computer or other processor or processing network, to identify
open source (and/or other) software projects for assembly into a stack,
to integrate the projects and install them on the user machine 502, and
to generate documentation and training materials specifically related to
the stack. The system 500 provides certain additional functionality, such
as switching databases or other tools within the stack, e.g., to achieve
optimized performance for a particular endeavor. It will be appreciated
that such functionality generally is not supported within proprietary or
other coordinated software contexts, where the integrating entity usually
has a vested interest in commercializing particular software products,
nor is such functionality supported within current uncoordinated open
source contexts, where stack assembly, integration and installation has
generally been performed on a customized endeavor-by-endeavor basis. The
illustrated system 500 includes a knowledge base 504 that stores and
provides knowledge required for the noted open source stack functionality
and an engine 506 that provides the logic for executing such
functionality. The knowledge base 504 and engine 506 may be resident on
the user machine 502, or may be at least partially accessible to the user
machine 502 via a network such as a WAN, e.g., the internet. Moreover,
the knowledge base 504 and engine 506 may be resident on a single
processing platform, or a distributed architecture may be employed.

[0060] The illustrated knowledge base 504 includes, for each supported
project, project information 504A such as identification information and
legal information, operational information, and category information. The
knowledge base also includes certain machine state information 504B
regarding the user machine 502. In addition, the knowledge base includes
certain stack information 504C for use in executing functionality at the
stack level, such as testing information.

[0061] With regard to project information 504A, the information that may
be included in the knowledge base 504 to identify a given project may
include the project name, version, type, home URL, categories,
description (with comparisons and recommendations) and links to full
project details. The legal information will generally include any
licenses with full license text or links thereto. Such license
information provides important legal information to users and further
supports license filter functionality as described below. The projects
may be stored locally, downloaded or otherwise accessed at the time of
installation.

[0062] The operational information may include dependency relationship
information and other resource information. For example, the dependency
relationship information may include a list of prerequisites for each
project, along with a description of why that dependency exists and how
the dependent project is used. The dependency relationship information
may further include a list of other projects that use each project,
together with a description of why that dependency exists and how the
dependent project is used. As will be understood from the description
below, such information is used to properly assemble stacks as well as to
provide stack explanation information to the user. In addition to
dependency relationship information, the operational information may
include other resource information such as ports used.

[0076] The machine state information 504B may include updated information
regarding projects and other resources that are available or unavailable
on the user machine 502. For example, if a particular tool such as a
database has previously been installed, this may be stored in the
knowledge base 504 and taken into account in addressing dependencies and
assembling stacks so as to avoid conflicts that might otherwise occur.
Similarly, port usage and other resource issues may be accounted for so
as to facilitate integration and proper interoperation of installed
projects.

[0077] The illustrated knowledge base 504 further includes stack
information 504C. Certain information may be indexed to stack
combinations rather than to individual projects. For example, information
corresponding to project information described above may be stored for
common stacks. In addition, certain installation information such as
testing parameters may be defined in relation to stack combinations.

[0078] The knowledge base 504 may store various other kinds of information
not shown such as operating environment information. For example,
information may be stored to support installation for multiple operating
systems and to associate particular uses of projects or stacks with
particular operating systems. For example, it may be desired to develop
on Windows and deploy on Linux.

[0079] The engine 506 accesses the knowledge base 504 at run time to
obtain all necessary information and executes logic for stack assembly,
installation and post-installation support as described in detail below.
The user can use the graphical user interface 508 to receive prompts and
other information to assist in implementing this functionality and to
enter associated information. The printer 510 allows for generating
hardcopy documentation.

[0080] It will be appreciated that the illustrated architecture allows for
convenient system implementation and maintenance. In particular, projects
or other information can be added or modified simply by updating the
knowledge base 504 substantially without updating the engine 506 or other
system components. Moreover, the engine 506 allows for rendering of
interfaces with a consistent look and feel across operating systems or
other implementation variations.

III. System Functionality

[0081] As noted above, a system in accordance with the present invention
may provide open source stack functionality related to assembly,
installation and post-installation support.

[0082] A. Assembly

[0083] Stack assembly generally relates to identifying a number of open
source and/or other projects to form a stack for addressing a particular
endeavor. In this regard, the system of the present invention can be used
to perform a number of functions. For example, information regarding
particular projects can be accessed in order to obtain a description of
the projects as well as dependency and restriction information. In
addition, information regarding stacks for common types of endeavors,
such as electronic commerce web site design, can be accessed. In this
manner, software developers who may have limited knowledge of available
open source and other resources may quickly assemble stacks. The system
is also fully functional to access machine state information, project
information and stack information such that the engine can be used to
address dependency relationships and facilitate stack assembly as
described below.

[0084] Referring to FIG. 6, a user interface screen 600 that may be
utilized in connection with stack assembly is shown. As illustrated, the
user interface 600 includes a project identification panel 602, a project
description panel 604, a prerequisite panel 606 and a used-by panel 608.
Generally, the project identification panel 602 displays a list of
supported projects with highlighting, graying and other graphical
elements to indicate status and certain dependency information as will be
described below. The project description panel 604 includes certain
project identification and description information as shown, including
recommendations and other assistance for the project highlighted in panel
602. The prerequisites panel 606 identifies projects that are
prerequisites of the identified project and the used-by panel 608
identifies other projects that may use the highlighted project.
Restriction information may also be shown in an appropriate panel.

[0085] More specifically, in the panel 602, primary projects are shown in
bold. Dependent projects are shown in normal typeface. Mandatory projects
are checked and cannot be changed. When a project is highlighted in the
panel 602, information relating to that project, in this case Tomcat, is
provided in panels 604, 606 and 608. In the illustrated example, the
title and version of the project is identified at the top of panel 604
together with information in parentheses indicating whether it is, for
example, a mandatory project or installed project. A link to the project
home URL is then provided followed by a link to view the project license.
Also shown are categories associated with the project that can be used
for grouping or filtering the projects and an identification of the ports
used by the project. Finally, a description of the project is provided
including, in some cases, recommendations or tips relating to the
project.

[0086] The used-by panel 608 lists other projects that depend on the
highlighted project. Conversely, the prerequisites panel 606 shows other
projects that are required in order to install the highlighted project.
It will thus be appreciated that the panels 606 and 608 collectively
define the dependency relationships for the subject project.

[0087] This dependency relationship information, as well as any applicable
restriction information, is derived from the knowledge base and is used
by the engine to provide assistance in graphical form related to stack
assembly. In this regard, if the user selects a project in panel 602 by
checking its associated install box, and that project has a prerequisite
that can be fulfilled by two or more other projects, or if there is an
unchecked dependency or violated restriction, an indication (e.g., audio
or visual) may be provided to prompt the user to resolve such issues. In
this regard, the project name turns red in the illustrated implementation
and the user is unable to continue with stack assembly until the
dependency is resolved. For example, if the project JBoss is selected in
panel 602, the JBoss lettering may turn red to indicate that a
prerequisite is required. The user can then consult the prerequisites
panel 606, which, in this case, would indicate that JBoss needs either
MySQL or PostgreSQL to continue. In the illustrated implementation, the
"Next" button on the user interface is disabled until the dependency
issues have been resolved, thus ensuring that the user does not continue
until all requirements are met. In other cases, dependencies may be
selected automatically.

[0088] In the noted example, the user may then elect to select MySQL to
satisfy the JBoss dependency. Once the selection is made, the JBoss
project will no longer be listed in red thereby indicating that the
dependency has been satisfied and stack assembly and installation may
proceed. As noted above, a project type is listed in parentheses next to
the project name and version at the top of panel 604. The types of
projects include mandatory, dependent, primary or already installed. The
project type is a link and if clicked will give a description of each of
the project types. Similarly, the license identification is a link,
which, if clicked, presents the full text of the license in panel 604.
The categories associated with each project are also links. If these
links are clicked, other projects in the category are listed in the panel
604. For example, if the category "server" is clicked, the panel 604 is
filled with a project description box with an initial description such as
tools usually found on servers or developer workstations--not typically
intended for routine end users. Such may be followed by a listing
including ANTLR, Apache, Http Server, etc. Projects listed in this
description are links, which, if selected, provide a more detailed
description of the selected project. In this regard, links may be
provided throughout the text, for example, when a supported project is
listed in the description of another project. Once a project has been
installed, the next time the user runs the system the installed projects
are shaded in panel 602 and are no longer selectable.

[0089] A button (not shown) is also provided in the tool bar to toggle
between install and uninstall modes. If this button is selected, for
example, to switch from the install mode to the uninstallation mode, a
pop-up box will appear warning that selected projects will not be
installed and confirming that this is what the user intends. Once this
intention is confirmed by the user, the system enters the uninstall mode.
In this mode, the projects that are installed are shown in the project
list of panel 602. Again, primary projects are shown in bold and
dependent projects are shown in regular typeface.

[0090] By way of example, in the install mode, the user may select Aspect
J, Castor, Eclipse and Eclipse plug-ins for installation. It may be noted
in this regard that if the Eclipse plug-in is first selected, the Eclipse
project will be automatically selected. Once all of the desired projects
have been selected, the user may select the next button 610 to proceed.
If any of the selected projects require more information to be properly
installed, a project properties page will be shown to collect this
information. A further user interface screen may be provided, if desired,
between the noted project selection and project properties screens to
check the ports (and potentially other resource requirements) to make
sure the machine state is compatible with the selected projects. If the
selected project requirements are not met, the user will be instructed as
to how to correct them. In some cases, any problems in this regard can be
corrected automatically. In any case, installation can be deterred until
all requirements have been met, thereby avoiding potential installation
complications. The user can choose to go backward and change project
selections as one way to resolve any issues.

[0091] An example is shown in FIG. 7. In this case, the user is prompted
to enter and re-enter passwords for JBoss and MySQL in the project
properties panel 702. A description of the selected properties is given
in panel 704 to assist the user in entering the correct information. Once
all necessary installation information has been entered, an installation
instruction screen 800 as shown in FIG. 8 is displayed. This screen
provides information to alleviate common issues that may interfere with
the installation. Links may be provided in this screen 800 to obtain any
additional instructions and requirements that may be useful.

[0092] When the user is finished with the installation instruction screen
800, the user can select the next button 802 to go to the installation
screen 900 as shown in FIG. 9. From the screen 900 the user can select
the start installation button 902 to initiate installation. The progress
of the installation can be monitored in Window 904. A pop-up window
indicates when the installation has been successfully completed and
provides information regarding post-installation instructions. As shown
in FIG. 10, upon completion of installation, the user is able to select a
reports button 1000 to generate installation reports or select the finish
button 1002 to complete the installation process. An example of an
installation report is shown is shown in FIG. 11. Specifically, the
report 1100 shows the status of all projects that have been installed at
the time of the report.

[0093] The projects that may be installed in this manner may include, for
example:

It is noted that this exemplary listing includes open source projects as
well as at least one proprietary application. Other open source projects
and proprietary applications may, of course, be supported.

[0094] The user interface may also execute a filter function to
selectively enable or inhibit access to particular projects by individual
users, e.g., within a client entity. For example, a company may configure
the system to assist in implementing a policy regarding, for example,
what projects may be accessed, how such projects may be used, and by
whom. In this regard, a company may define such projects on a
project-by-project basis or by type; may specify a set of projects that
may be used internally, the same or a different set of projects that may
be incorporated into products (generally or on a product-by-product
basis), and other project sets for other purposes; and/or may specify
what projects may be accessed by an individual or a set or sets of
individuals e.g., by software developers, by IT personnel, by accounting,
etc.

[0095] It will be appreciated that the filter, the underlying policies and
the associated filter parameters are selected by and are the
responsibility of the client entity. The filter provides a convenient
tool for implementing and improving internal enforcement of such policies
after the policies have been devised by the client entity with such
consideration of the legal environment and other factors as deemed
appropriate by the client entity. It is not intended that the filter be
used as a substitute for full consideration of such issues or in lieu a
full internal education and enforcement regime.

[0096] As noted above, a variety of parameters may be used to configure
the filter. One such parameter is license type. In the context of open
source projects, there are currently over 45 different recognized open
source licenses. These include, for example, the General Public License
(GPL), Lesser General Public License (LGPL), BSD, and Apache licenses.
Open source licenses are not free of restrictions and obligations and
different licenses involve different restrictions and obligations in this
regard. While these restrictions and obligations are not always
unambiguous, and the specific license terms should be consulted with due
care, certain characterizations are possible. For example, certain
licenses require that the source code of software, including proprietary
software, distributed with the licensed open source software be made
publicly available. Such licenses generally include obligations with
respect to copyright notices and attributions with respect to copies of
the software. Client entities will therefore generally need to carefully
consider such licenses in relation to intended uses as part of a
compliance program.

[0097] These licenses may serve as a parameter of the noted filter. That
is, as noted above, license information is associated with each supported
project in the illustrated system. These license designations may be
selected or deselected by the client entity or system operator, e.g.
using a filter graphical user interface, to enable or disable access to
projects based on license or license type. Such configuration may be
executed for specific users, user groups, intended uses, etc. Upon
definition of such a filter or filters, the GUI is operative to inhibit
or facilitate access to projects, generally in accordance with the
selected filter parameters.

[0098] The filter is not necessarily limited to binary allow or disallow
functionality. For example, three or more filter levels may be defined
such as "red", "yellow" and "green" levels that may correspond to levels
of license restrictions or obligations. Thus, a particular client entity
might decide, in its own discretion and in accordance with its own
internal policy, that GPL licensed projects will be associated with the
yellow filter level and BSD and Apache will be associated with the green
filter level.

[0099] The GUI can then be configured to execute different filter
functionality in connection with each filter level. For example, "red"
projects may be excluded from the project identification panel 602 (FIG.
6) or selection thereof may be disabled. In the case of yellow projects,
appropriate warnings regarding use or restrictions on use (e.g.,
`Internal Use Only" or "please consult with compliance officer prior to
use") may be displayed, or a password or other authorization may be
required to complete installation. Green projects may be accessed as
described above free from filter inhibitions. It will be appreciated that
other filter levels and associated filter functionality is possible in
accordance with the present invention. While such automated filtering may
be imperfect in matching and executing policy goals and is no substitute
for full education and compliance program, it provides a useful mechanism
for encouraging adherence to a compliance program which has become a
great concern for companies considering use of open source and other
projects.

[0100] It is noted that such filter functionality may have considerable
value apart from the illustrated system. For example, the filter may be
used by a compliance officer, wholly independent of any stack assembly,
installation and support functionality, to screen projects proposed for
use by employees. Moreover, such a filter may be implemented in
connection with an Internet gateway filter (e.g., otherwise used to limit
internet access in accordance with company policy) to inhibit downloading
of designated projects, for example, based on associated URLs. Other
execution environments and uses of the filter are possible in accordance
with the present invention.

[0101] FIG. 12 is schematic diagram illustrating a filter system 1200 in
accordance with the present invention. The illustrated system 1200
includes logic for executing one or more filters 1202. For example,
different filters 1202 may be defined for different users or user groups
within a client entity.

[0102] The filters 1202 may be defined by a user by way of user interface
of 1204. In this regard, filter identification information, filter
parameters and the like may be entered by way of a template or a series
of menus displayed on the user interface 1204. In this manner, the user
can define a number of filter parameters such as user parameters 1208,
use parameters 1210 and license parameters 1212. The user parameters 1208
may identify specific users or user groups, e.g., application developers,
IT personnel, accounting, etc. The use parameters 1210 define the
intended or allowable uses. Thus, for example, it may be desired to allow
one set of projects for internal uses and a second (typically more
limited) set of projects to be incorporated into products. The license
parameters 1212 allow for controlling access or use of projects based on
license associations. Thus, as noted above, certain licenses may be
associated with a green filter level, others may associated with a yellow
filter level and still others may be associated with red filter level.
Appropriate filter rules may be defined for each of these filter levels.

[0103] Based on such filter configuration information, the filters 1202
selectively allow access to or use of projects 1206 by a user system
1214. For example, the filters 1202 may inhibit access to selective ones
of the projects 1206, may prevent installation of selected ones of the
projects 1206, or may provide certain warnings or require certain
authorizations in connection with access to or use of individual ones of
the projects 1206. Such filtering functionality may be executed in
response to an identification of the user system 1214, a user I.D.
entered via user system 1214 or otherwise, or an intended use entered by
the user. The projects 1206 may be defined by a list of supported
projects of a stack assembly, installation and support system as
described above, a listing of projects defined by a compliance policy of
a client entity, or projects that are identified on a case by case basis,
for example, in connection with a request to download a project via the
internet.

[0104] FIG. 13 is a flow chart illustrating a process 1300 for configuring
and operating a project filter in accordance with the present invention.
The illustrated process 1300 is initiated by accessing (1302) a filter
configuration utility. Such configuration may be implemented by a client
entity, a system provider, or other operator. Using the utility, a filter
is selected (1304). This may involve associating a filter identification
with a particular filter to be configured. In this regard, it will be
noted that a client entity, a system provider or other operator may
define and manage multiple licenses.

[0105] Once the filter is selected, filter levels may be defined (1306)
for that filter. As noted above, a filter may be a binary in this regard
or may include more than two filter levels. Thus, a binary filter may be
operative to selectively allow or disallow access to specific projects by
specific users for specific purposes. A filter with more than two filter
levels may allow access, disallow access or allow access with certain
restrictions or authorizations. Individual users or user groups may then
be selected (1308) for association with the defined license. This allows
for different levels of access to particular projects or project groups
(e.g., defined by an associated license type) on an individual user basis
or by a user group such as an applications development group.

[0106] The illustrated process 1300 involves associating (1310) projects
with the defined filter levels. Again, this may be done on a
project-by-project basis or by groups of projects, e.g., as grouped based
on license type or another category such as noted above. It will be
appreciated that other filter parameters may be defined in this regard
such as, for example, expiration dates and copying or distribution
parameters. Once all desired filter parameters have been defined, it is
determined whether additional filters need to be defined (1314). If
additional filters are to be defined, this process is repeated.
Otherwise, the filter is activated (1316) for use in the desired project
filter environment.

[0107] In use, the filter is operated to identify (1318) a user for a
given filter function. The user may be identified based on user
identification information entered by the user or based on the identity
of the user machine or system. An intended use may also be identified
(1320). The intended use may be entered by the user or may be inferred
from a user group or other information. In this regard, it will be
appreciated that the filter may be operative to a prompt user to enter
such information as a gateway function prior to accessing a stack
assembly, installation, de-installation and/or support functions. In
addition, the subject project is identified (1322). Depending on the
specific implementation, such identification may be responsive to a
request, such as an installation request, entered by the user or may be
performed independent of any user input, in the background or prior to
running of the stack assembly, installation and/or support function. In
this regard, the filter may operate to prevent display of a filtered
project or to prevent selection of a filtered project independent of any
input by user. Finally, the filter is operative to execute (1324) the
filter function. Such execution may involve selectively allowing access
to an identified set of projects, selectively disallowing access to or
particular uses of an identified set of projects, or display of
limitation information/require appropriate authorizations.

[0108] An exemplary installation process 1500 is shown in FIG. 15. The
illustrated process is initiated by receiving (1502) input information
for a stack assembly. It will be appreciated that the process may be
initiated in a variety of ways. For example, some users may know that
they are interested in assembling a package that includes a particular
project that is relevant to a given endeavor. In this case, such users
may simply identify that project, for example, by scrolling through a
list of supported projects or by using a search function, and then work
through dependency relationships as discussed above. In other cases,
users may know the name of a proprietary application and may be
interested in identifying an open source analog. In such cases, a tool
may be provided for identifying such association. In still other cases, a
user may not know the name of a project but may only know the function of
interest. In these cases, assistance may be provided in the form of
graphical user interfaces to assist the user in initiating the
installation process. For example, menus may be provided, such as
pull-down menus, whereby the user can identify a function of interest.
Additionally or alternatively, supported projects may be graphically
illustrated, for example, with links to project descriptive information,
to assist a user in identifying a project of interest. As a further
alternative, the process may be initiated with an interview process over
a number of interfaces to identify user needs. It will be appreciated
that a wide variety of interface mechanisms are possible in this regard.

[0109] In any event, once input information is thereby received, the
illustrated process 1500 involves providing (1504) options for at least
one project. Thus, for example, if the input information indicates that
the stack of interest relates to web design, a variety of web design
project options may be identified. For example, such identification may
be accomplished by highlighting or otherwise drawing attention to such
projects in a list of supported projects. Alternatively, the relevant
projects may simply be listed with links to user interfaces that provide
project information as described above. It will be appreciated that in
some cases only one project may be available rather than a selection of
options.

[0110] A selection can then be received (1506) for a first project of a
stack under assembly. For example, one project from the noted listing of
options may be selected via a graphical user interface. Upon such
selection, the system determines (1508) dependency relationships for the
project. Such dependency relationships may include, for example, projects
on which the selected project depends as well as other projects that are
used by the selected project. The system also determines (1510) a machine
state. For example, this may involve identifying projects that are
already installed on the user's machine. The project filter may also be
applied (1512) at this point. Based on all this processing, the system
constructs (1514) a display reflecting the project filter, machine state
and dependency relationships. Thus, based on the project filter, the set
of projects that is available for selection or installation may be
limited. Based on machine state, previously installed projects may be
identified as installed or may be unavailable for selection to be
installed. The dependency relationships may be reflected in various
graphical elements and text as described above.

[0111] From this display, this system can receive (1516) a project
selection. For example, the user may select a project on which the first
project depends. After such selection, the system can determine (1518)
whether all dependencies are resolved. If the dependencies are not
resolved, the user may be prompted to make further project selections.
Otherwise, the system indicates (1520) that assembly is complete. Such an
indication may be provided by way of a pop-up box or other active display
element, or may simply be provided by way of the absence of any remaining
dependencies (for example, the first project listing may switch from red
to black).

[0112] It should be appreciated that the system of the present invention
may be used simply to assemble a stack without actually effecting
installation and that is an important aspect of the present invention.
For example, a developer may use logic resident on the developer's system
or access a website to execute the functionality described above in order
to facilitate the process of, for example, addressing dependency
relationship issues and filter functions associated with the client
entity's licensing compliance program. The individual projects of that
stack may then be obtained and installed independent of the system of the
present invention. However, the installer of the present invention
performs a variety of useful functions in connection with installation as
will be described below.

[0113] B. Installation

[0114] It should be understood that the identification of a set of
projects where the dependency relationships are internally satisfied does
not mean that installation will be successful and free of problems. It is
generally still necessary to resolve conflict issues, integrate projects
(e.g., so that a given project is configured to point to the correct
database), and to test the installed stack for proper installation and
interoperation of the projects. In addition, a particular sequence may be
required for installation. In accordance with the present invention, the
GUI is operative to execute a variety of functionality in this regard.

[0115] One such function is performing pre-installation checks. For
example, the GUI may identify and resolve port conflicts. As noted above,
the project information associated with individual projects identifies
the ports that are utilized by that project. This port information can be
compared to identify and resolve conflicts. The system may further
perform a check to verify that any files or other resources required by a
project are available and to otherwise verify that all environmental
requirements for a project are satisfied on the user machine or system.

[0116] Another function is control of the actual installation process. In
this regard, the engine may obtain the project list for a stack, analyze
the dependency relationships and any other necessary project information
to determine a suitable sequence for installation and then execute
installation in that sequence. Prior to executing this installation, the
controller may execute logic to identify any resources that may be
required in order to effect the desired installation.

[0117] Another function that is executed by the GUI in connection with
installation is database integration. In this regard, individual projects
may require a particular database and different projects may be
associated with different databases. The GUI is operative to integrate
the individual projects with the desired databases so that the projects
point to the desired database.

[0118] After installation and database integration have been performed,
tests may be performed on the installed stack to verify proper operation
of the installed stack. This is accomplished by causing the stack to run
on the user machine and then executing test procedures that are defined
for particular projects, combinations of projects or overall stacks. For
example, such tests may involve looking for particular files, checking
ports, pinging a server, etc. It will be appreciated that the particular
tests may be determined empirically or based on acquired expertise to
provide a high likelihood of identifying common installation errors.

[0119] The installed stack may then be run with selected samples. That is,
a tutorial specifically designed for the installed stack may be provided
by the GUI. The user can run this tutorial to learn how to use the
installed integrated stack. In connection with this stack, the installed
stack executes certain samples. This operates to provide sample tests.
That is, proper operation of the stack is verified in connection with
executing the samples. These tests are similar to the tests described
above but touch more layers of the software stack than the earlier tests
and operate in an execution environment. If any errors are identified as
a result of these tests, error messages may be provided together with
information regarding resolution of the errors or instructions to repeat
a portion of the installation process.

[0120] Similar issues are presented in connection with addressing project
updates. In the context of operating stacks composed of projects from
independent sources, e.g., multiple third parties or open source
developers, it will be appreciated that updates generally will not be
coordinated. That is, updates may occur at different times and may or may
not have an impact on compatibility. The installation process described
above can be implemented not only in connection with an initial
installation, but also in connection with an update installation. That
is, appropriate checks, installation sequencing, testing and the like can
be designed and executed for a given update.

[0121] In this regard, update installations may be implemented
automatically, upon manual retrieval of the update, or the user or an
administrator of the client entity may be notified of the availability of
an update. For example, a system operator may monitor the availability of
updates for supported projects and download appropriate information to
users or client entities. A user or client entity may then be advised of
the availability of updates upon logging into a network, loading of a
stack assembly, installation and support system, or selection of any
affected project. Such updates may relate to updated project options and
support materials as well as to updated software updates. The user or
client entity may then select to install or not install the update. It
will be appreciated that not all users/client entities may wish to
install all updates in this regard.

[0122] It will thus be appreciated that the illustrated system provides a
number of advantages with regard to the installation and update process
and this installation process, considered independent of stack assembly
or post-installation support, constitutes an important aspect of the
present invention. That is, various elements of this installation process
would provide advantages even in the context of a stack assembly
developed independent of the present invention. However, even upon
assembly and installation of a stack of multiple open source projects,
certain post-installation support may be desired. The present invention
provides significant advantages in this regard, as will be described
below.

[0123] C. Post-Installation Support

[0124] Upon assembly and installation of an open source software stack,
the stack is ready for use by the end user. However, a variety of
post-installation functionality may be useful to allow optimal
performance of the stack. The present invention provides a variety of
functionality in this regard, as described below. Many users may benefit
from a tutorial to educate the end user as to the proper use and
capabilities of the installed stack. As noted above, tutorials are
available for some open source software projects. However, such tutorials
generally are not specifically adapted to provide instructions in the
context of particular stacks that may be assembled. The present invention
provides tutorials in the context of such stacks. The system described
above supports a selected set of open source and other projects. These
projects can be combined to define a large but finite set of software
stacks. The knowledge base stores tutorial information for many or all of
these stacks or subsets thereof. Upon installation of a stack, the
associated tutorial or tutorials are made available to be run by the
user.

[0125] Another important post-installation function relates to users
manuals or other supporting documentation. As noted above, supporting
documentation may be available in connection with individual open source
projects. However, heretofore there has generally not been a convenient
mechanism to obtain supporting documentation relating to a particular
stack. This problem is addressed by the present invention by storing
support documentation as structured XML documents. That is, chunks of
supporting documentation text are associated with a tag system that links
the text to particular projects, combinations of projects and overall
stacks. For example, projects and stacks may be related by parent, child
and other hierarchical tag structures. When a particular stack is
installed, the relevant support documentation can be readily retrieved
using the tag system to compile customized support documentation.
Associated graphics may be assembled on a custom basis, also. The
supporting documentation may be specifically provided for Linux, Windows,
and/or other criteria specified by the user or indicated in the user
machine information stored in the knowledge base and the appropriate
documentation in this regard may be retrieved based on metadata (e.g.,
tag) associations.

[0126] It will be appreciated that the ability to provide custom tutorials
and supporting documentation for an open source project, a combination of
projects or an overall stack is an important advantage of the present
invention that may be utilized independent of the stack assembly and
installation tools noted above. For example, developers who have executed
a custom stack installation independent of the tools noted above may wish
to utilize the present invention to obtain supporting tutorials or
documentation. For example, this may be accomplished by running logic
resident on the developer's system or by accessing a website operative to
provide such tutorials or documentation on a fee basis.

[0127] The combination of the flexibility of open source software and the
ease of assembly and installation provided by the present invention
yields a number of advantages that can not be readily realized in
connection with proprietary systems or with open source software in the
absence of the tools of the present invention. For example, a user may
wish to try various stack options to determine which is optimal for a
particular endeavor. For example, a user may wish to switch between
different available database tools in connection with a particular open
source software stack. In accordance with the present invention, a
database switcher, or a switcher for other software components, may be
provided. In this manner, the user can prompt the system to switch
between one database and another. This system is operative as described
above to integrate associated projects of a stack so that they point to
the newly selected database. The user can then compare performance of the
stack with one database tool (or other resource) and another database
tool (or other resource). In this manner, optimization of performance for
a particular endeavor can be conveniently achieved. It will be
appreciated that proprietary systems generally do not accommodate
comparison as between tools of competing providers. Open source systems
theoretically allow for such comparisons but as a practical matter this
cannot be performed due to the significant complexities associated with
switching of tools and associated integration.

[0128] The system described above can be implemented a number of ways. For
example, the associated logic may be disseminated in physical form to
clients with updates provided periodically. Alternatively, the associated
logic may be downloaded from an operator's website by a client entity and
updates may be periodically downloaded in similar fashion. As a still
further alternative, the system may be operated as a hosted application.
In any event, use of the system may be licensed, for example, on a per
user per year basis. In this regard, it may be desired to make
information regarding such licenses available to the licensee while
protecting the license information against unauthorized modification.

[0129]FIG. 14 is a schematic diagram illustrating a system 1400 for
managing such license information. The illustrated system includes a
license manager 1402 for managing information that is available to the
user via a user interface 1410. The system 1400 may be resident on the
client equipment of the system provider, or another location, and may be
distributed across multiple platforms. The license manager 1402 is
operative to receive requests for license information entered via the
user interface 1410 and to manage access to license information of 1404.
In this regard, the license information 1404 includes license files 1406
for individual licenses. The license file 1406 includes a public portion
1406a and a private portion 1406b. The information available in the
public portion 1406a and private portion 1406b may overlap to an extent
but the private portion 1406b will generally include additional
information. In the illustrated implementation, the public portion
includes, for example, a license identification and an expiration date.
Such information may be used, for example, to enable the user to identify
the license at issue and obtain information of legitimate use to the
client entity.

[0130] The private portion 1406b may include additional information, such
as information defining the license term, as to which access is to be
limited. The private portion of 1406b can be accessed by an authorized
individual, for example, to update the expiration date or to add licensed
seats. This is accomplished by entering license identification
information via the user interface 1410 and requesting access to the
restricted access fields. In response to such an access request, the user
is prompted to enter a password or other security information. This
password information is used to encrypt information entered into the
private portion of 1406 or to decrypt information from the private
portion 1406b. In this manner, appropriate license information is made
available while protecting restricted access information such as
information fundamental to enforcement of the license terms.

IV. Stacros and Extensibility

[0131] FIGS. 16-48 are user interface screenshots, for an implementation
of the present invention designated as the BlueGlue® application,
showing a number of novel features of the invention. In addition to the
functionality generally described above, the following screenshots
illustrate certain advanced functionality relating to custom stacks and
extending system capabilities beyond currently supported projects as may
be desired by some users.

[0132] In the former regard, the discussion above described how stacks or
projects can be assembled, installed and supported or serviced.
Additionally, it may be desired to add such stacks to graphical
interfaces, for example, so that information regarding the stack, its
licenses, etc. can be conveniently accessed and other functionality such
as synchronization, license filtering and searching can be implemented
with respect to the stack. Thus, functionality can be executed with
regard to a stack analogous to the functionality supported for individual
projects. Such functionality may be termed a stack macro or "stacro."
Screens associated with such functionality are shown below.

[0133] With regard to project extensibility, the system as described above
supports a large and varied collection of projects. Nonetheless, specific
users may on occasion desire to add a project that is not currently
supported, e.g., so that the new project can be incorporated into stacks
and serviced, so that information regarding the project and licenses can
be readily obtained, and so that a variety of system tools can be applied
with respect to the new project. All of this functionality is supported
by the present invention. In addition, the system of the present
invention can calculate a variety of information regarding project
interdependencies, exclusions and conflicts for the new project, for
example, based on limited input information such as information
identifying direct dependencies. Screens related to this functionality
are also shown below.

[0134] Referring to FIG. 16, a user interface screen including an "about
BlueGlue®" dialog box 1602 is shown. The dialog box includes
Information and System tabs. In the illustrated example, the Information
tab has been selected and information regarding the BlueGlue® program
is provided. This information includes contact and licensing information
among other things. In addition, a link is provided to the license text.

[0135]FIG. 16 also shows graphical elements related to the project filter
functionality described above. Specifically, green 1604, yellow 1606 and
red 1608 indicators are provided in a license column associated with
various project names. These indicators 1604, 1606 and 1608 identify a
filtering parameter that has been associated with the project by the
company or operating entity. As discussed above, these filter parameters
may depend on the individual user or that user's position or other
authorization information. For example, a project may be associated with
a red indicator due to a license type deemed undesirable by the company
or because of the manner in which the project is intended to be used. In
such cases, the project may be grayed to prevent selection or warning
information may be displayed.

[0136]FIG. 17 shows a further user interface screen 1700 including the
"about BlueGlue®" dialog box 1702. In this case, the System tab has
been selected so as to provide various information regarding the state of
the system.

[0137]FIG. 18 shows a user interface screen 1800 for graphically
depicting dependency information. More specifically, the user can select
a node tree icon 1804 to obtain a graphical depiction of dependencies in
panel 1802. In this case, project dependencies are illustrated
graphically. It will be noted that panel 1802 shows complex dependency
relationships including dependencies and sub dependencies. In addition,
mandatory and contingent dependencies are indicated, in this case, by
open and closed bullets.

[0138] As noted above, the system of the present invention can be used to
extend the system functionality to add new projects to the supported
project library. The system can also be used to create custom stack
macros or stacros. These stacros may include added projects. Associated
functionality is illustrated by the user interface screen 1900 of FIG.
19. More specifically, by selecting appropriate graphical elements, the
user can access dialog boxes 1902 and 1904 that guide the user in
establishing a stacro. As indicated in dialog box 1902, the user can use
this functionality to create custom packages that may contain custom
projects, categories, licenses, and documentation. Appropriate fields are
provided for entering such information. For example, dialog box 1904
provides fields for entering information defining a custom category. FIG.
20 shows a dialog box 2002 that provides fields for entering information
defining custom documentation. FIG. 21 shows a dialog box 2102 that
provides fields for entering information defining a custom license.

[0139] A number of dialog boxes may be used to define a custom project.
Referring first to FIG. 22, a dialog box 2202 is shown including fields
for entering a project identification, project name, project distribution
package, a license and categories, and optional install and uninstall
scripts. FIG. 23 includes a dialog box 2302 illustrating the process for
identifying properties, exclusions and dependencies for a custom project.
FIG. 24 includes a dialog box 2402 illustrating the process for entering
custom project properties including property identification, property
display name, property type and optional information. FIG. 25 includes a
dialog box 2502 that can be used to enter optional values for
description, ways to use, and notes. As shown, projects that are already
installed can be included in the custom stack by selecting an appropriate
graphical element 2504.

[0140] As discussed above, the system of the present invention allows for
implementation of a project filter based, for example, on license types.
FIG. 26 shows a graphical user interface 2600 for implementing such a
tool. For example, the filter tool may be operative to removed projects
from the projects list, to prevent selection of projects shown on the
projects list, to prevent specified actions with respect to projects
shown on the projects list, to provide graphical or other warning
information with respect to a project on the projects list or to
otherwise identify filter restrictions. In the illustrated example,
license type filters can be selected or deselected on a
license-by-license basis. Additionally, the project filters can be used
to filter types of projects such as dependent projects. The user
interface 2600 also provides license details indicating projects that are
used by particular licenses together with links to the associated
licenses and information regarding the projects.

[0141] Once custom stacks or custom projects have been defined as
discussed above, the stacks or projects can be accessed and processed by
the system of the present invention. In this regard, FIG. 27 shows a user
interface screen 2700 that can be used to select the desired operation.
In this case, the user can select to install projects, uninstall projects
or manage licenses. FIG. 28 illustrates a graphical user interface screen
2800 that may be provided in connection with an installation process. The
screen 2800 includes a basic installation report showing installed
projects. In addition, test results and associated information are shown.
FIG. 29 shows a graphical user interface screen 2900 providing details
regarding installation progress.

[0142] FIG. 30 illustrates a user interface screen 3000 that may be
provided in connection with managing licenses. Specifically, in the
illustrated example, a license edition name, license status and
expiration date are shown together with a graphical element 3002 for use
in deactivating the license.

[0143]FIG. 31 shows a graphical user interface screen 3100 that may be
provided as part of an online help utility. Specifically, a welcome
screen 3100 is shown. Various help categories are shown in panel 3102. As
shown, the categories include major category headings project
installation, uninstallation, GUI, extensibility, licenses, and support.
Under these major category headings, a user can select various
subcategories for guidance through the relevant processes.

[0144] FIGS. 32-34 show various screens and dialog boxes associated with a
custom package manager. Dialog box 3200 of FIG. 32 can be used to create
a custom package. Specifically, the user is instructed to first click the
create new package button, then enter a project identification and
project name and move any custom projects, categories, licenses or
documentation to the package contents selection list. FIG. 33 illustrates
the process for populating these fields. Dialog box 3400 of FIG. 34 shows
a project node tree 3402 corresponding to the package contents selected
list 3404.

[0145] FIGS. 35-38 illustrate a process for defining preferences. Dialog
box 3500 of FIG. 35 illustrates various fields that may be selected under
the General tab. For example, the user can select to show a tip of the
day on start up, to send feedback, to show project versions and to show
custom package names in the project table. FIG. 36 shows fields that are
presented under the license tab of the preferences dialog box 3600. Using
this box 3600, the user can associate license type colors with each
supported license type. In addition, the user can on select whether to
show a license information dialog start up and whether to show a license
column in connection with the project name list. FIG. 37 shows various
fields that are presented under the Look and Feel tab. These fields allow
the user to customize the look and feel of the system. Finally, FIG. 38
shows the fields that are presented under the Update Manager tab. These
fields include certain proxy server settings as well as a box for
indicating a preference regarding whether to check for updates on start
up.

[0146] Once a custom package has been defined, that package can be
processed in accordance with specified preferences in a manner analogous
to processing of individual projects. Thus, FIG. 39 illustrates a user
interface screen 3900 for providing project details regarding a selected
project. In this case, the project "ant" is selected from the project
name list and project details are shown in panel 3902. In FIG. 40, a
custom package is selected from the project name list and details
specified for the custom package are presented in panel 4002.

[0147] Other functionality is also supported for such custom packages. For
example, FIG. 41 shows how information regarding dependencies and used by
projects may be provided in connection with a project selected from the
project name list. It will be appreciated that similar information may be
provided in connection with custom packages or custom projects. FIG. 42
shows how information regarding mandatory and contingent dependencies as
well as exclusions may be presented in connection with a project selected
from the project name list. Again, similar information may be provided in
connection with custom packages or custom projects. As discussed above,
installation, uninstallation, testing and support functionality may be
supported for the custom packages.

[0148]FIG. 43 shows a user interface screen that may be provided in
connection with a search function of the present invention. For example,
the user may wish to search for relevant information within the system by
entering keywords. The present invention supports such searching using,
for example, fuzzy and Boolean search logic. The entire record associated
with a project, e.g., all fields, may be searched. In the illustrated
example, the search criteria utilized is "Apache." The search results
identify a stack that includes the project "Apache HTTP server". It will
be appreciated that this functionality is also supported in connection
with custom stacks and projects.

[0149] As shown in FIG. 44, the user may also select the Stacks tab 4402
to obtain a stacks listing. The user can then select, for example, the
name "custom stack" and add, in this case, a custom project. As shown in
FIG. 45, when a stack is selected from the stack name list (in this case
"collaboration") details regarding the stack are provided in panel 4502.
FIG. 46 shows a tip of the day dialog box that may be presented depending
on the preferences selected by the user. FIG. 47 shows a user interface
screen 4700 that may be presented in connection with an uninstallation
procedure. The screen 4700 provides certain information and warnings
related to uninstallation. FIG. 48 shows a user interface screen 4800
including an update manager dialog box that can be used to check for
updates of the BlueGlue® system.

[0150] As noted above, it may be desired to extend the functionality of
the system, e.g., to include additional projects or packages or to
support additional platforms or operating systems. Such extension may be
performed internally by the entity operating or marketing the stacking
system or may be performed by an end user, for example, who wishes to add
a proprietary or other project to a stack where the new project is not
incorporated into the stacking system. As discussed above, this may
involve selecting a project for incorporation into the system, an initial
acceptance process for analyzing the project under consideration (e.g.,
with respect to viability, legal considerations, functionality and
technical considerations), and a certification process involving rigorous
testing of the added project for proper operation. Certain aspects of
this process for extending the functionality of the system are described
below.

[0151]FIG. 49 is a block diagram of a system and process 4900 for
configuring software packages for installation upon an end-user's
machine. In this embodiment, system 4900 includes a software project
bundler 4901 and a package certification process 4902 that, in
conjunction, provide a software package 4904 for an end-user. It will be
appreciated that such certification may be employed with respect to
individual projects as well as stacks. For example, the end-user may be
an information technology department of an enterprise requesting a
particular software project for implementation with the machines (i.e.,
computer systems) of the enterprise. This software project may include a
plurality of projects, such as business software suites (e.g., Microsoft
Office and Open Office maintained by Sun Microsystems, Inc.) and/or
database software (e.g., Oracle Database), etc. The package certification
process may be performed manually or may be at least partially automated.
Project bundler 4901 may retrieve requested projects from a plurality of
source providers, such as open source providers1 . . . M 4906,
proprietary source providers1 . . . N 1307, and no license source
providers1 . . . P 4908. Once retrieved, project bundler 4901 may
configure each of the projects for operation upon one or more particular
computer operating systems (e.g., Microsoft Windows, UNIX, Linux,
Solaris, HPUX, ZOS etc.) by modifying the projects and/or generating
configuration files that take advantage of operating system
functionality. That is, the operating system enables the modules to "run"
on a particular machine when the projects are configured to operate
within the parameters/confines of the operating system.

[0152] After building the software package, the package certification
process 4902 verifies that the projects contained therein will properly
operate with the destined operating system. That is, package
certification process 4902 involves a series of tests on the software
package to ensure its operability with the operating system. Once assured
of its operability, the software package is certified, and a deliverable
software package 4904 is generated for the end-user. In this regard,
system 4900 may include media recorder 4903 (e.g., a CD recorder, a DVD
recorder, magnetic tape recorder, etc.), which is used to record the
deliverable software package 4904 on a computer readable media. The
computer readable media may then be delivered to the end-user through any
known means. Alternatively or additionally, the end-user may communicate
directly with system 4900 (e.g., via the Internet) to receive the
deliverable software package 4904. As such, the system 4900 may include
Internet communication protocols that allow for the transfer of the
software package to the end-user.

[0153] Project bundler 4901 may also use communication protocols, such as
Internet communication protocols, to communicate with the various project
providers (open source providers1 . . . M 4906, proprietary source
providers1 . . . N 4907, and no license source providers1 . . .
P 4908). For example, project bundler 4901 may communicate with open
source provider1 4906 to retrieve a particular project for inclusion
with the software package. As with many types of software, a project
associated with open source provider1 4906 may come with a software
license 4909 that limits the use and/or reconfiguration of the project
being provided. Project bundler 4901 may, in one embodiment, analyze the
license to ensure that the associated project may be configured as part
of a software package. That is, project bundler 4901 may determine
whether the project being provided may be included with other projects
and/or changed to accommodate various operating system parameters.

[0154] Generally, software exists with various types of licenses. For
example, open source providers often use what is known as a GNU general
public license, which may grant the following rights to the software
being provided: [0155] The right to run the program, for any desired
purpose. [0156] The right to study how the program works, and modify it.
Access to the source code is generally a precondition for this. [0157]
The right to redistribute copies. [0158] The right to improve the
program, and release the improvements to the public. Again, access to the
source code is generally a precondition for this.

[0159] Project bundler 4901, when receiving a project from a provider, may
observe this license and determine that the provider of the project is an
open source provider. Accordingly, project bundler 4901 may configure the
project within a software package, as it deems necessary. Proprietary
software, on the other hand, may include a license 4910 that precludes
modification to the software being provided. In this regard, project
bundler 4901 may analyze the license to determine that the particular
project being provided is not acceptable for configuration within a
software package. As such, that particular project would be excluded.
Alternatively, project bundler 4901 may communicate with the proprietary
source provider 4907 and negotiate a particular licensing arrangement
that allows for the reconfiguration of the project being provided for
incorporation into the software package. In such an instance, the project
provided by proprietary software provider 4907 would be configured for
incorporation into the software package such that the software package
included open-source projects as well as proprietary source projects
without conflict, either functionally or legally.

[0160] The invention, however, is not intended to be limited to merely
incorporating certain types of licensed software, such as open-source
software and proprietary software. Rather, system 4900 may also allow
inputs from no license source providers 4908. For example, no license
source provider 4908 may include independent software engineers making
various software contributions on a free or contractual basis. Project
bundler 4901 may, therefore, allow for communication with such software
engineers and incorporate various software functionality when deemed
valuable by the end-user. In this regard, the end-user itself may have
software engineers making software contributions that the end-user wishes
to have incorporated into its deliverable software package 4904.
Alternatively or additionally, no license source provider 4908 may also
include free software source providers that simply make software
contributions available to the public as a matter of good will. Project
bundler 4901 may also evaluate such software and incorporate it to the
software package when the project bundler deems it to be value enhancing
to the software package.

[0161] System 4900 also includes a knowledgebase 4905. Knowledgebase 4905
may include information useful in troubleshooting various projects of a
software package. For example, as package certification process 4902
tests the functionality of various projects of a package, it may be
determined that a particular module will not operate according to the
parameters of the destined operating system. An operator may, therefore,
communicate with knowledgebase 4905 to obtain any fixes that may be
available for the project and may subsequently incorporate those into the
projects to make the software package deliverable (i.e., operable with
the end-user's operating system).

[0162] Additionally, deliverable software package 4904 itself may
communicate with knowledgebase 4905 when features of the package are not
operating as desired. For example, once a deliverable software package
4904 is installed upon an end-user's machine and the various projects
therein are unbundled for operation, problems with certain projects can
still occur. Operating systems themselves are routinely updated and,
therefore, have the potential to create conflicts within certain
projects. As such, deliverable software package 4904 may include
communication protocols that allow the deliverable software package to
communicate with knowledgebase 4905 to obtain fixes and/or troubleshoot
projects that are having problems after installation.

[0163] Knowledgebase 4905, however, is not intended to be limited to an
end-point of troubleshooting/repair. For example, knowledgebase 4905 may
also operate as an interface to project providers. That is, knowledgebase
4905 may routinely communicate with source providers (open source
providers1 . . . M 4906, proprietary source providers1 . . . N
4907, and no license source providers1 . . . P 4908) to determine
when updates are available for projects of a particular deliverable
software package 4904. Knowledgebase 4905 may then automatically download
and test those updates and reconfigure the deliverable software package
with those updates as they become available.

[0164] Additionally, knowledgebase 4905 may include a user interface that
allows for independent software developers to submit software, patches,
documentation, etc. that may be used in the package certification process
4902, by project bundler 4901, and/or by the deliverable software package
4904. For example, knowledgebase 4905 may allow software developers to
contract their services and handle problems that may occur with projects.
In this regard, an end-user may submit a problem to knowledgebase 4905
such that the software developer may address the problem and provide a
fix. System 4900 may also be configured with a payment system that allows
such developers to submit invoices to the system. Accordingly, one aspect
of the invention may include a business model, which allows for
independent software developers to login and provide services for a fee.
Alternatively or additionally, software developers may provide such
contributions for free.

[0165] The certification process and system of the present invention
provides the user with confidence that projects in the system library
will function properly and will remain available for use with minimal
complications. FIG. 50 shows an example of subject matter areas that may
be addressed as part of the certification process. In this case, the
certification process is divided into an initial acceptance process and a
full certification process. For example, projects under consideration for
addition to the system library may first be subjected to the initial
acceptance process. If a project passes this initial acceptance process,
it may then be subjected to the full certification process. Upon
successful completion of the full certification process, the project may
be added to the system library. The user and the provider or operator of
the system can thereby be confident in the quality and reliability of the
accepted projects. Indeed, the system provider may provide warranties,
indemnification and insurance for the supported projects. Accordingly,
users can receive software, documentation, implementation, support,
maintenance, upgrades/updates, warranties, indemnification and insurance
for projects and stacks, including open source projects. This addresses
many, if not all, of the concerns that have caused resistance to open
source adoption.

[0166] In the example of FIG. 50, a 42-point certification process is
implemented. Specifically, the initial acceptance process includes
analyses for a project with respect to viability, legal considerations,
functional considerations, support and technical considerations. Some of
the factors that may be considered in the viability analysis include the
structure of the community supporting the project, who is the entity
driving the project, what is the size of the community, what development
practices have been employed in connection with the project, what is the
longevity of the project, what maintenance activities have been performed
for the project, what alternatives are available for the project and what
ratings have the project received.

[0167] The legal analysis may involve validating the license where the
project is associated with a license that is well understood. In other
cases, where the project is associated with a custom license, that
license may be specifically reviewed for terms that are likely to be
acceptable to system users. Finally, a search may be performed to
identify any other possible legal issues such as any indication of third
party rights violations.

[0168] The functional analysis is directed to verifying that the project
has the types of features that would be expected by users and that the
project is readily usable. With regard to support, the project may be
analyzed to ensure that appropriate documentation is available (or can be
generated) and that training is available. In addition, the level of
community support may be analyzed, and that support may be tested to
ensure that it is adequate. In addition, any availability of commercial
support is taken into consideration.

[0169] The technical analysis may involve a variety of factors, including
verifying that the project can be properly downloaded, performing a
security check on the project and determining any dependency
relationships that the project may have. An installation test may then be
performed on the project, and the project may then be tested to ensure
that it can be configured and integrated for use in the supported
environment. Finally, basic tests may be performed to ensure technical
viability.

[0170] If a project passes the initial acceptance process, the full
certification process may then be executed. The full certification
process, in the illustrated example, includes process for technical
implementation, automated testing, knowledgebase population, and
packaging. The technical implementation process involves executing a
complete build of the project and completing integration of the project
into the system. The project is then configured for automation with
respect to the functionality described above, and any issues in this
regard are resolved.

[0171] As noted above, one of the functions performed by the system is
automated testing of the projects. In this regard, the full certification
process involves development and execution of basic tests. Integration
tests are also developed and executed. Finally, any issues that arise in
this regard are resolved.

[0172] The knowledgebase is also supplemented in relation to any projects
added to the library. This involves generating enhanced documentation and
sample applications, and storing a test suite for the project. In
addition, update and verification information is included in the
knowledgebase for each project.

[0173] Finally, the illustrated certification process involves packaging
for each added project. In this regard, the individual components are
packaged, release notes are provided and secure delivery is ensured. It
will be appreciated that a different certification process, involving
more, less or different steps, may be implemented. However, the noted
certification process is believed to provide projects with exceptional
reliability and ease of use.

[0174] While various embodiments of the present invention have been
described in detail, it is apparent that further modifications and
adaptations of the invention will occur to those skilled in the art.
However, it is to be expressly understood that such modifications and
adaptations are within the spirit and scope of the present invention.