[Gnu-arch-users] re: sad events

[Thomas Lord]

Michael Goikhman writes:

  > The latest events are sad. It seems that neither Tom Lord nor
  > Canonical are interested in developing Arch anymore. And noone yet
  > volunteered as the new maintainer.

Let me expand on, perhaps even change my position about that.

Negatives, and then positives.

The negatives:

~ I am not interested in continuing as an official GNU Maintainer

  I have too many political differences with RMS about the proper
  handling of the GNU project and so I do not think I can represent
  the project's values and policies well enough to be a maintainer.

  *Of course* I agree about the importance of software freedoms and
  will do my best to always chose GPL-compatible free software licenses
  but those points of agreement are insufficient, in my opinion, to 
  also stand as a public interface to an official GNU project.


~ I am not interested in running a "fashionable" public free software 
  project.

  I've taken no end of heat from vocal members of the Arch mailing
  lists about such things as whose patches and bug reports I spend
  time on and when.   Often the implicit threat, and actual effect,
  has been "Do our bidding or we trash your professional reputation."

  The sad truth is that with the resources I've had, to keep such a 
  user community satisfied would mean making huge sacrifices to the
  code quality of GNU Arch and to any work on making major leaps in
  functionality.

  There is room, certainly, to enable skilled and dedicated volunteers
  and promising, eager-to-learn volunteers to help hack a public
  project.   There is value, certainly, in being able to receive bug
  reports.  But the wild-west gambler's-town style interaction I
  encountered in this project doesn't fit the bill.  A better, more
  restrained approach is needed -- one which is less dependent upon 
  the way the winds blow on the mailing lists from week to week.

The In Between:

~ I am not interested in dying.

  The same old sob story:  I've no revenues.  I'm in the red for october
  (meaning that basic expenses like food and DSL and electricity through
  the end of the month vastly exceed my remaining cash.  I'm flat, 
  flat, flat broke in just a few days with nothing redeeming in sight).

  I'm not interested in "working for fame" or any other such intangible.
  I did that.  I earned my own modest share of it.  That and a $1.50
  will buy me a cup of coffee (though I'll have to stiff the barista
  on a tip).

The positives:

~ Especially with Canonical abandoning it, Arch can have a future.

  Arch is no longer my heart's first true love -- that's for sure.

  On the other hand, and especially in the direction of revc, I think
  it can have a bright future.  

  I am willing to enthusiastically keep working on it under the right
  circumstances, provided that I am able to go in directions that I
  think make sense, especially directions that move far, far beyond
  just "software source code revision control".  Surely I have earned
  some credibility with which to chose a course.

  I think that porting some of the missing features from tla to revc,
  which would be quite useful for source code management, is a good
  place to start.   This can be done without sacrificing the already
  file-at-a-time CVS/SVN-like command set of revc or the nice 
  git-like performance characteristics.

  I would certainly be willing to be technical adviser to a group
  that wants to maintain tla as it stands (although they have to
  pay more than lip service to my role in that capacity).

  It is simplifying that Canonical is going in their own direction.
  It would have been just swell to have help improving the UI in
  this direction or that but, for whatever reason, they came with
  far too much baggage.

~ All it takes is monetary investment

  So, Arch got started (out of necessity) by my going into debt.
  It got sustained by the stunning generosity of many people when
  I was busking.  It got sustained further while an angel investor
  and I tried unsuccessfully to bootstrap a start-up business around
  it.  There seem to be a significant number of interested users.
  It has certainly had its share of positive impact both directly
  and by influencing several other systems.

  Somehow, our collective mode of economic organization has failed to
  actually reward *me* and allow *me* to, in good conscious and fully
  living up to familial responsibilities, continue to work on it.

  I reject the glib defamations of the Canonical crew and those they've
  influenced.   I don't even begin to claim perfection as businessperson
  or entrepreneur but I'm certain I'm far from the outlier I've come to
  be portrayed and widely regarded as thanks to their "efforts".

  So I'm throwing up my arms a bit:  Dear Lazyweb -- what the *hell* am
  I supposed to do at this point to keep the effort going?  Anyone got
  any ideas?   Any offers?  Selfish and self-righteous replies from 
  Canonical, their groupies, and think-alikes will be called out as 
  exactly that.

~ A Vast Frontier Opens Up Before Us

  Take revision control far enough and you wind up smack dab in the 
  middle of global file-systems generally.   There is *so* much to
  do that is worth doing in elaborating this framework for other kinds
  of content management and with respect to new kinds of user
  application that build upon it.

  This weekend I've been working on raising the bar of wiki parsers.
  I don't think I'll have time to finish it before I run out of cash.
  Roughly, the idea is that Wikis, deep down, are based on multi-pass,
  recursive parsing -- a rough parse of a large piece of text, followed
  by a finer parse of each component.   At each level of recursion, 
  the lexical and syntactic grammars change (a trivial example: wiki
  mark-up that let's you make a stylized paragraph at one level -- 
  but have a mathematical equation that can be fed to a compute-engine
  and/or fancy formatter at the next level down).  It ties in nicely
  with revision control because wiki-style syntaxes tend to branch
  and merge nicely, and applications which handle them tend to be 
  error-tolerant and provide user-friendly-recoverability for subtexts
  containing syntax errors (such as after a slightly-off merge).

  The rough idea there is to bump awiki to the next level as a precursor
  for integrating it with revc.  Many nifty applications flow from that.

-t

Emergency assistance welcome: address@hidden on paypal,  same address for
inquiries into what directions I'd like to take my R&D efforts in 
the future.