FOSS and Interface Taxonomy levels: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]

[John Plocher]

James Carlson wrote:
> Uncommitted is *far* better than Volatile.  It restricts chaos to the
> Minor release boundaries, which are much less frequent than the rate
> at which we ship patches.

The difference between Volatile and Uncommitted and Committed
is in how the *project team* chooses to behave.

Software development is, at its heart, a set of producer-consumer
relationships.  Someone produces the source code, another compiles
it.  Someone makes packages/tarballs out of the result and another
uses them to construct a product...

The difference between FOSS development and that "all-done-by-us"
is simply that the role of the project team changes from being
source code authors to being importers and integrators.

As importers, the project team has to decide how often it will
import new versions of the source code from its external supplier,
what expectations to set for others and what glue and trim they
need to come up with to make it fit into our product mix.

The interface taxonomy provides some of the words we use in
setting those expectations.  Our son is studying Algebra in
school this year; he might express this as

    Expectations = f(Behavior(supplier),Promises(project team))

Raymond is focusing on only one component - the supplier's
behavior.  Jim is focusing on the other.  As usual, both of
you are right :-)

The project team is the final arbiter of /when/ change happens
in our components - if they do nothing, then nothing changes.
The team could put a version of libsane into the OS now, and
decide to never ever put a newer version into the system.
The result?  libsane would be a very stable interface because
the project team committed to never changing it.  (it also
would get extremely stale over time...)

The other end of the spectrum is also "interesting".  The project
team could decide to integrate a new version of libsane each and
every time the supplier dropped off a new one.  What would we
be able to say about the stability then?  Not much, other  than
"you get whatever the supplier gives - good luck".  This is where
understanding the supplier's behavior is so important.  If they
are well behaved, the effective stability might still be stable;
if not, it won't be.

The middle ground is where we find most projects that we
intend to reuse as part of our systems.  There, the stability
MUST be high enough for us to produce robust systems - if the
foundation components aren't stable, the system won't be,
either.  This requires the project teams to buffer their
supplier's behavior to keep it from negatively impacting our
derived systems.  Buffering implies that the project team's
job is harder, and that it may cost the company more resources.
As above, that cost is dependent on the actual behavior of the
supplier combined with the promises made by the project team.

It should be clear by now that there are some combinations of
supplier behavior and project team promises that work better than
others:

     Behavior	Promises	Effect on consumers
     --------	--------	-----------------------
     stable	stable		low cost, high satisfaction
     evolving	stable		short term OK, long term not[1]
     chaotic	stable		high cost[2], low satisfaction[1]

     stable	evolving	low cost[3], high satisfaction
     evolving	evolving	low cost[3], high satisfaction
     chaotic	evolving	high cost[2][4], low satisfaction[1]

     stable	chaotic		high cost[4], low satisfaction[1]
     evolving	chaotic		high cost[4], low satisfaction[1]
     chaotic	chaotic		high cost[4], low satisfaction, low use

What does this all mean?  IMO:
    Don't misrepresent either the supplier or your own ability
      (don't promise more than you actually can deliver),

    If your supplier is chaotic, you must either get involved with
      the supplier and fix the chaos problem *or* don't bother
      putting that component into the foundation of our systems, and

    If you don't intend for the component to be REUSED BY OTHER
      CORE TEAMS, don't put it into the core components of the OS,
      where we have stricter requirements for avoiding incompatible
      changes.  On the other hand, if it is intended for reuse, it
      really must be reusable in a low cost, low risk way.

   -John
____

[1] satisfaction among consumers will be low because they won't
all agree on /which/ of the versions of the supplier's code
they should use, thus guaranteeing the eventual uselessness
of whatever version the project team chose.

[2] high lifetime cost to the project team as they spend more
and more resources sustaining their fork over time.

[3] As long as the project team makes sure it has a way to roll
over to a new, incompatible version, so it doesn't get left
behind when its supplier evolves.  This means choosing a
consolidation that allows incompatible change to the interface
taxonomy types that were chosen.  It also may imply supporting
multiple incompatible versions of the component or having some
other transition plan in mind.

[4] low cost to the project team, but O(n) to O(n^2) sustaining cost
to "n" consumers and to distro producers as a whole