Proposed Principles and Definitions for the Soar Consortium
June 8, 2004
The purpose of this document is to present a set of definitions and principles that will guide a
consortium in managing the continued open source development of Soar. The explicit
understanding is that whenever there are decision points in the procedures, the principles will be
used to direct the evaluations of alternative choices.
Definitions
Consortium: Refers to the Soar Consortium throughout the document
Consortium Review Process: Refers to the process for approval and integration of proposed SKS
changes.
Soar Consortium: All organizations and individuals that have agreed to actively participate in
the Soar project and abide by its rules.
Soar Kernel Suite (SKS) consists of:
 Soar Kernel: The Soar Kernel consists of all of the code that was part of the Soar 8.3
release and any changes made by Soar Technology to that code for any purposes,
including the integration of gSKI. Any changes made to the Soar Kernel code base will
continue to be considered part of the Soar Kernel.
 gSKI: A generic Soar Kernel Interface consisting of an interface design together with
implementations in C++ and other languages for accessing the Soar Kernel, originally
developed by Soar Technology.
Soar Project: The SKS and all Soar community members that have registered to use and
maintain the SKS. At the time of writing this consists of Soar project Sourceforge members.
Consortium Principles
1. Openess: The SKS will be distributed using the BSD license.
2. Code Quality: All changes to the kernel will be thoroughly reviewed and tested
according to consortium review process.
a. Correctness: Analysis and tests must show that integration code executes the
given design and that no undesirable side-effects occur.
b. Robustness: Analysis and tests must show that the integration code executes
correctly in a broad range of conditions, including error conditions.
c. Maintainability: Analysis must show that the integration code is implemented in
such a way that it is readily understandable to another trained programmer and
that modifications and improvements can be made without excessive effort.
3. Increase User Base: The consortium will have as an explicit goal increasing the user
base for Soar. As part of the effort to achieve this goal, changes to the SKS will be
evaluated along the following dimensions:
4.
5.
6.
7.
8.
a. Usability: The consortium will prefer changes that improve the usability of Soar
to those that do not affect or reduce the usability of Soar. “Usability” includes
system integration, architecture coding and development, Soar coding and
development, and Soar model use.
b. Learnability: The consortium will prefer changes that make Soar easier to learn
to those that do not affect or reduce the learnability of Soar. The emphasis on
learnability will be placed mainly on Soar coding and development, but it also
includes learning system integration, as well as learning architecture coding and
development, and learning how to use Soar models.
Shared Contributions: Consortium members are expected to submit any significant SKS
changes they make to the consortium. Whether or not these changes are actually
integrated will be decided using the consortium review process.
Inclusive: All good faith proposals to change the SKS will be considered for acceptance
by the consortium. However, before acceptance and integration, any change must pass
the consortium review process.
Compatibility: New releases of Soar will minimize changes in existing applications that
depend on SKS.
Timeliness: Changes to the SKS will be considered and reviewed in a timely manner.
The exact time frame for the review process may be set by the consortium as it sees fit;
however, bug fixes in particular will receive high priority for approval and integration.
Respect for Research and Commercial Needs: The needs of both academic research
and commercial development will be respected and supported.