Re: [Gnu-arch-users] [semi-OffTopic] UserLinux

[Tom Lord]

    T>> Gee, and I always thought that, when push comes to shove,
    T>> these customers will be best off if they figure out that the
    T>> product they buy _is_ engineering.

    A> Do I *really* have to point out that *everybody* thinks that
    A> about their own field?

    S> Including middle management.

"middle management" and "engineering" are not necessarily disjoint
sets of activities.   But anyway....

We can draw some pictures of UserLinux proposition:

Let's start with the flow of source:

        Source code flow:

               various free and
               open source software
               projects
                  |
                  v
    ......................................
    .          Debian                    .
    .             |                      .
    .             v                      .
    .          UserLinux                 .
    .       /     |       \              .
    .      /   ...|........\..............
    .     v    .  v         v
    . service  . ISVs     end customers
    . providers.          ,^
    ...........`---------'

Note that the "stuff in the dotted box" is analogous to what the
GNU/Linux vendors defined as "The Problem" do internally.  They don't
use Debian but they do collect the various projects into a "starter
culture" for distros, they massage that to make particular supported
distributions, their "service provider" component is internal (and
singular).

Not shown in the diagram are software feedback arrows from service
providers into UserLinux, into Debian, and into the various projects.
They aren't shown because the whitepaper doesn't talk about them.

"The Problem Vendors" make those feedback arrows a distinct part of
their "added value" proposition: for example, their customers can
expect very timely security patches, conveniently and preferentially
distributed.  The participation of vendor engineers in the public
projects is a selling point.  The strong influence of the alliances of
the problem vendors over some projects is a selling point.

UserLinux, to scale up and compete, has to solve a harder problem.
Like the problem vendors, it needs to implement a competitively tight
feedback loop between service providers and the UserLinux platform,
including the ability to rapidly propogate changes to end customers.
Unlike the problem vendors: that feedback loop has to span the
internal boundaries of a confederation of service providers -- a
confederation whose ultimate aim is to be _much_larger_ than the
service arms of the problem vendors.

So what's the plan for that feedback loop?  How will it work
technically, socially, and economically?  Can the UserLinux
organization call an emergency real-time meeting of the service
providers?  Are the end customers going to share a package update
service that is distinct from Debian's?  Who's going to manage
decisions about what changes make it in to UserLinux -- especially
during an emergency response -- and who's going to be responsible for
shepherding such changes back to the various projects?

There is presumably a testing process between changes to UserLinux and
the release of those changes.   There's presumably an auditting
process and costs associated with distributing updates.  Bruce talks
about funding "brand building" and "cultivating ISVs" -- but is silent
on the economics of maintaining that software flow graph (with
feedback arrows added).

What should the unspecified parts of this UserLinux
"meta-organization" look like?  How do they get paid for?

-t