[Gnu-arch-users] planning 2.0? (was re: Google...)

[Thomas Lord]

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.