The Scheme FAQ gives a brief answer and a few pointers to OO systems:

  http://schemers.org/Documents/FAQ/#N10640

though I think a better list is available at the CMU AI repository (this
includes TinyCLOS):

  http://www-2.cs.cmu.edu/Groups/AI/lang/scheme/oop/0.html

Another portable OO system is Meroon (available at above links) which
was the basis for withdrawn SRFI-20.

Below is a genealogy of object systems with brief notes about their
major differences.  Please let me know if I made any mistakes or missed
anything below.  Pointers to other Lisp-based object systems would be
much appreciated.

OO: Vague concept of abstraction, many definitions.
  |
  +- CLOS: Common Lisp Object System, based on CommonLoops and New Flavors,
  |   |    winning out in the CL standardization over Object Lisp and
  |   |    Common Objects.  I know nothing of those 4 original systems.
  |   |
  |   +- TinyCLOS: Subset of CLOS written in pure Scheme, including a
  |   |    |       meta-object protocol (MOP).  Classes, generics &
  |   |    |       methods all 1st class.  Native OO system for Chicken.
  |   |    |
  |   |    +- SOS: MIT Scheme's native OO system, mostly differs in naming
  |   |    |       and interface.  No MOP via meta-classes but supports
  |   |    |       computed methods.
  |   |    |
  |   |    +- STklos: Native TinyCLOS implementation.  Class redefinition.
  |   |         |     Don't need to predefine generics (complicates module
  |   |         |     interaction).
  |   |         |
  |   |         +- Gauche: Well integrated with native libraries.
  |   |         |          Collections API.  MOP utilities.
  |   |         |
  |   |         +- GOOPS: Guile's native OO system, also well integrated.
  |   |                   Very well documented.
  |   |
  |   +- SISC: Similar to TinyCLOS (possibly a conscious influence though
  |   |        I can't find any lineage in the docs).  Limited multiple
  |   |        inheritance.
  |   |
  |   +- Meroon: Another CLOS derivative, similar to TinyCLOS but more
  |   |    |     featureful (also has stripped down version Meroonet).
  |   |    |     MOP.  DSSSL support.  Excellent documentation.
  |   |    |
  |   |    +- Bigloo: Native implementation based on Meroon, has 1st class
  |   |               classes, generics & methods.  No MOP.  Fields can be
  |   |               typed with native C types for efficiency.
  |   |
  |   +- YASOS: Yet Another Scheme Object System, a portable OO system
  |        |    distributed with SLIB.  Works in terms of dispatching
  |        |    methods (called operations) on arbitrary Scheme values
  |        |    (which can inherit from arbitrary Scheme values - there
  |        |    are no classes).  Includes a collections API.
  |        |
  |        +- MOS: Macroless Object System, removes macros (and thus uses
  |                different API) from YASOS but keeps the idea of methods
  |                on objects with no classes.  Distributed with SLIB.
  |
  +- MzScheme: System of classes, objects and methods, all 1st class Scheme
  |            values, but no MOP.  Single inheritance with interfaces and a
  |            public/private distinction similar to the C++ & Java style of
  |            OO.  Uses explicit send syntax to call methods, although a
  |            with-method syntax is provided to look like CLOS methods.
  |            Excellent interactive documentation.
  |
  +- Kawa: Access to Java OO system.  Methods defined statically with
  |        classes.  Provides "this" syntax.
  |
  +- Smalltalk: Oldest OO system still in use (only Simula is older, and
       |        Smalltalk is better).  Objects dispatch on methods names,
       |        as opposed to the reverse in all of the above systems.
       |
       +- SICP: Chapter 3 of The Structure & Interpretation of Computer
                Programs describes a very simple dispatch closure based
                OO system.  Some of the smaller OO system's in the
                Scheme repositories follow this style, most Schemers
                write such an OO system at some point, and many Schemers
                use this style without any sugar when they want portable
                code (see much of SLIB).