planning 2.0? (was re: Google...)

There is interest in things like changing the namespace,
changing the archive format, changing the working tree
format, etc.  I would like to explore the hypothesis that people
might be interested in cooperating to design and build
Arch 2.0 . [1]

So I have three questions, a personal partial answer to two of those
questions, and then some tentative assertions.

* The Questions
  Q1. Who is our target market?
  Q2. What are their needs?
  Q3. What is our business model? [2]

* Personal Partial Answer: Who is our target market?

  I think it should include:
    ~ GNU/Linux distribution projects (both commercial and public)
    ~ small, especially new free software projects
    ~ teams of people using office applications rather than programming 
per se
    ~ public-knowledge-repository projects such as Wikipedia

  I have not put "large, established FOSS projects" on the list because
  I think they are the ones with the least incentive to change (which
  gets into "what are their needs" which I'm skipping over for this
  post).   Conditions external to large, established FOSS projects need to
  change before many of them will want to change much of anything.

* Personal Partial Answer: What is our business model?

  Even if we start off 2.0 as a strictly volunteer effort, and even if we
  don't aim to be a for-profit company, I think we need a plan to derive
  revenue for the project and to distribute and spend that revenue equitably
  and effectively.   The way of not having such a plan leads to chaos and
  madness, in my experience.


* Tentative Assertions

   By "definition", anything to be called Arch is:

     ~ a revision control system
     ~ using a decentralized database
     ~ supports replication of database nodes
     ~ operates well with "partial knowledge" (some nodes inaccessible)
     ~ supports easy branching and merging across separately
        administered database nodes which exchange only read-only rights
     ~ provides ACID properties to multiple users of a single database
        node
     ~ provides smart merging based on history-of-patches and
        common-ancestor computations
     ~ handles file renames during merging via logical file ids
        rather than tracing history
     ~ permits publication of database nodes using generic,
        commonly provided server-side software (e.g., an HTTP
        server or SFTP server)
     ~ has a partially-ordered user-defined namespace of revisions
     ~ also has a separate partially-ordered history graph of revisions
     ~ uses cryptographic hashing and signing to help establish the 
integrity
        and authentic authorship of revisions
     ~ encourages the signing and distribution of explicitly reviewable
        deltas between preceding and succeeding revisions

  Of course, those are necessary, not sufficient conditions for a program
  to be called Arch.


Notes:
[1] "I would like to explore the hypothesis that people
       might be interested in cooperating to design and build
      Arch 2.0 ."

     For this hypothesis, I am not assuming that I am in any
     way "in charge" of Arch 2.0.   I can try to serve the effort
     by trying to lead, but that is not the same thing as being in
     charge.    It isn't initially obvious that *anybody* needs to
     be in charge.

[2] "Q3. What is our business model?"

     This does not imply starting a for-profit business (or rule it
     out).   Rather, it is just a reality that any FOSS project is an
     economic activity:  people are putting labor;  products are
     produced; there are customers.    The business model could
     just state that "We rely exclusively on volunteers," for example.
     I just suggest that we be explicit about this from the start.