FOSS and Interface Taxonomy levels

[Danek Duvall]

[ Taking this off the 2008/170 discussion. ]

I think you're absolutely right on most of your points.  Except for
(parts elided):

>      Behavior	Promises	Effect on consumers
>      --------	--------	-----------------------
>      chaotic	stable		high cost[2], low satisfaction[1]
>      chaotic	evolving	high cost[2][4], low satisfaction[1]
>      chaotic	chaotic		high cost[4], low satisfaction, low use
> 
>     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.

Right now, we have no effective way to deliver components for Solaris other
than through "the foundation of our systems".  Solaris is delivered as a
giant, monolithic blob, appropriately highlighted by its moniker, the WOS.

If we had a better delivery system, that would allow for a smaller "core"
but still allowed users to easily install a larger amount of software, we
could push the more volatile things off into this arena, and make them
available perhaps only through explicit "user pulls", rather than Sun /
distro "pushes", then this problem would be alleviated.

However, given that we have effectively a single distribution channel, we
have to make the best of it that we can.  And right now, that involves
pushing a lot of software through it that may not satisfy the stability
desires that we've held for a long time.  This isn't just a management push
-- there are a lot of engineers who want to make more software available,
regardless of how appropriate it might be to build stuff on.  A large
portion of the world has learned to live with the pain, and even accepts it
in limited circumstances.

As long as we understand -- and document for the end-users so they
understand -- that these bits may change chaotically, we shouldn't disallow
Volatile software from shipping.  We shouldn't build on it, certainly, but
for people who want easy access to it and understand its limitations,
there's little reason not to make it easily available.

I don't think that doing so should involve not running such projects
through the ARC.  I think there's value in a basic architectural review of
the system integration points, and also in having extra eyes on the project
to confirm that they're assessing the stability of the interfaces correctly.
But there are going to be components which are simply best described as
Volatile, but are still bits demanded by our users.  Do we really need to
deny them simply because *we* wouldn't build on those components?

Danek