[Pika-dev] Funding Drive

[Tom Lord]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(This is part of a two part message.   The second half
 is called "NPO Time?" and is posted separately.)


Well, it's yet another one of those exciting times for the arch
project, financially speaking.  Among the currently overdue bills are
$181 for electricity, $120 for ISP services, and $120 for water....
and I have about $150 in the bank for the two of us and our cat to
live on until the next expected check -- mid-February for $500.

I must make the usual hat-passing appeal but I'd like to do it a bit
differently this time because the arch project is growing and
spreading, more people are becoming more seriously involved, and my
role in the project is gradually changing.

Financially speaking, the arch project operates on a simple principle:
the project publishes excellent and useful free software which you are
free to download, use, modify, and redistribute.   The project keeps
the community in touch with a lively discussion forum.   What I ask in
return is that from time to time, users ask themselves how valuable
the project is to them and, if they are able, to provide the project
with a measure of that value in the form of a cash donation.

I think that's an excellent deal -- an excellent "model", if you will
for how free software research and development can be funded.  No user
is _required_ to pay.  No user is asked to pay more than they can
afford.  No user is denied use of the software or participation in the
project for not paying.  The direct contribution model is efficient
because it "cuts out the middlemen" -- funding directly supports
further R&D.  And the system is especially affordable for users when
compared to "seat fees", "support contracts", and the other systems of
"metered software costs" found in commercial projects.

Contributions from private individuals are (as always) extremely
welcome, however, I'd like to dedicate today's appeal to a different
group -- and with a new goal.  I'm certainly not discouraging personal
contributions: I suspect they're still needed.  They've kept me alive
for quite a while now.  The more the merrier and thank you, thank you,
thank you.  

But it also seems to me that the project is reaching a stage in
development, popularity, and impact, where it becomes appropriate for
me to look beyond personal charity, and beyond the current informal
structure of the project.

Therefore, today's appeal is especially directed at those users whose
interest in arch is related to commercial activity.  There are at
least a small number of companies who are either already using arch
internally, or who are conducting pilot efforts to figure out how to
use arch internally, or who are supporting their employees while those
employees are exploring arch.  There are also beginning to be
contractors who are working with arch as part of their jobs.   It's
this group of users I'd like to especially appeal to today.

I'm asking those of you with a commercial interest in arch, either
individually or via your organization, to make a contribution today.
I suggest that you pick an amount on a self-assessed sliding scale of,
say, $50 to $500.

Because of the current circumstances, that's an /URGENT/ request.
Time is of the essence.  The count-down to "lights off" on this end is
proceeding quite rapidly.  I encourage the use of paypal right now
simply because in most cases, that's the most rapid route for turning
contributions into bill payments.

To the degree that this appeal is successful, I'd like to give
something new back to the community and to the financial supporters of
arch.  In particular, I'd like to expand the funding model I've been
using for arch.  I hope to formalize it legally in the form of a
non-profit, charitable organization.  I hope to extend the model so
that funding flows to other arch engineer's besides just me.  I hope
to apply the model to other software in addition to arch.   

I'll need the community's help to accomplish those goals.  In addition
to just (literally) "keeping the lights on" here at Arch Central, I'll
need to raise a little bit seed money.  I'll need to find officers to
help run the organization (California law requires 3) and pay the
incorporation fees.  And I'll need to work out with the most active
technical contributors to arch how funding should best flow.  I've
written more on those topics in a followup message to this one.

For now, though, the need is urgent and immediate.  Every little bit
helps.  

Paypal link:

  
https://www.paypal.com/xclick/business=lord%40emf.net&item_name=support+for+arch+and+other+free+software+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD

and Moneybookers info:

  address@hidden for www.moneybookers.com payments.


I thought I'd leave off in this message with a brief summary of what's
been going in arch and related projects lately -- to give a better
sense of how contributions turn into R&D.

So what's up with arch?   What's been going on?

* reviewing and merging contributions

  Nearly all of the new code in the 1.2preX series (so far) is
  _contributed_ code.  The quantity and quality of contributed code
  continues to rise.  Arch has crossed a kind of project-lifetime
  milestone:  the contributed code to arch has begun to consistently
  exceed what I could create personally.

  My role seems to have clearly shifted, recently, from "primary
  hacker" to "primary gatekeeper".  I'm finding that arch is starting
  to proceed faster if I spend less time writing new code for it
  myself, and more time giving advise about, reviewing, testing and
  merging contributions.   Not as fast as some contributors would
  like, I'm sure -- but at what I judge to be "the right speed."

  The "gatekeeper" role is an interesting one.  I've found it
  important to say "no" to some contributions when testing revealed
  them problematic; other contributions when they damage portability
  or code cleanliness; other contributions when they would create
  "architectural" problems in arch.  This has worked out quite well in
  some cases when, after the "no", the contributors go back and fix
  the problems and their corrected work is later merged.



* designing process improvements

  As the size of the user community and the number of code
  contributors has grown, some weaknesses in the engineering process
  that creates arch releases have become apparent.

  Coordination with code contributors has proven to be a little too ad
  hoc -- a little too "the squeaky wheel gets the grease".

  The Savannah bug tracker, while arguably better than nothing, has
  proven to be an inefficient way to keep track of pending issues.
  It's an awkward tool and a bottleneck to development.   It's
  impossible to tune well for the kinds of "patch flows" that are best
  for the arch project.

  Therefore, I proposed "The Game" -- a new combination of practices
  and tools for running the arch project, and, eventually, other
  projects as well.

  As I write this, contributors have been working on designing and
  implementing the needed tools and I think prospects are good that
  we'll be able to move the project to "The Game" style of management 
  before too long.



* ancillary tools

  Quite independently of anything that _I_ work on, some contributors
  continue to work on "ancillary tools" such as front ends, shell
  completion support, browsers, and cvs gateways.  The gnu-arch-users
  mailing list is showing signs of success at helping those projects
  get off the ground by attracting users and contributors.



* advocacy

  Again, quite independently of anything I do, a number of community
  members have become arch advocates: giving talks to LUGs (Linux user
  groups) and, in one case, giving an _award_winning_session_ about
  arch at the "linux.conf.au" conference (congratulations to Robert
  Collins and his team!).



* security feature initiatives

  After the infamous security crack of the FSF's free software project
  host, savannah.gnu.org, I was contacted by the FSF and asked how
  hard it would be to add cryptographic signing features to arch.  The
  crack created a crisis, of sorts, for Savannah because it raised the
  possibility that CVS archives of hosted projects had been corrupted
  by the introduction of malicious code.  

  Indeed, exactly such an attempt has recently been made on the CVS
  archive hosted by BitMover for the Linux Kernel -- malicious code
  was indeed injected.  _That_ attack quickly failed, however, when
  the integrity checking features of Bitkeeper noticed and reported
  the problem.

  And so, I concluded, such integrity checking features are _vital_
  for arch.   

  I posted a design proposal for such features and some interesting
  results followed.   First, the design received careful study and
  criticism from the community who did, indeed, find bugs.  Second,
  the corrected design was quickly implemented by volunteers -- I
  needed to make only modest corrections before merging it.

  It was not more than a couple of weeks between the FSF's initial
  inquiry and the appearance of the features in arch.   Arch is now
  one of the most securable revision control systems in existence.


* a new project

  In addition to my work on arch, I've started a new project called
  "Pika Scheme".

  The goal is to build a portable Scheme implementation, with (among
  other features) excellent Unicode support, good support for systems
  programming on Posix-family systems, and a flexible and robust FFI
  that will enable Pika to evolve flexibly with respect to its
  implementation strategy (such as VM implementation and GC strategy).

  The long term goal is to build a Scheme suitable for applications
  like "itla" (a sophisticated interactive front-end for arch) and a
  Scheme-based, internationalized, GUI-intensive version of Emacs.

  I initially published just two things:  some long design sketches
  and plans for how to build Pika, and a small amount of "starter
  code" -- just barely implementing the core of the core of the core
  of what will be Pika.

  To my delight and surprise, even though the project community is
  still small, already it has attracted active contributors who are
  completing the work far more rapidly than I could do alone.  The
  "lexer" and "reader" (for parsing Scheme data and code) has matured
  rapidly;  the support for numbers (including bignums, exact rational
  numbers, and complex numbers) is nearly done;  support for Unicode
  strings and characters is underway.

  And as spin-offs of Pika, I've begun work on some "SRFIs" (community
  standards for Scheme) to specify a portable interface to Unicode
  programming in Scheme.


So that's what's up lately at Arch Central.

I hope that some of you will find these activities worth paying for
even though nobody is obligated to do so.   That's the free software
funding model:  we invent new and great software which anyone can use;
users pay what they think it's worth and what they can afford;  and
the cycle (hopefully) continues.

As I said, Arch Central faces an urgent crisis at the moment -- and
I'd sure like to get past that.  In addition, I hope to better
formalize the arch funding model and you can read more about that in
my next message.

If you can, please help.   Those links again are:

Paypal link:

  
https://www.paypal.com/xclick/business=lord%40emf.net&item_name=support+for+arch+and+other+free+software+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD

and Moneybookers info:

  address@hidden for www.moneybookers.com payments.


Thanks and yeehaw,
- -t

- ----------

"Fast forward a couple of years. Now the truly massive profit margins
 meant that just about any mistake and I mean any mistake, was completely
 masked by the awesome cash flow. Management succumbed to the cash flow
 drug and vainly assumed that it was their hard work, superior strategies
 and dizzying business acumen that was driving the company ever skyward.
 They thought they could do no wrong but they were. 

 They thought that t-shirts, purple furniture, jackets, unique building
 architecture, polo shirts, sabbaticals, watches and great product code
 names were the secret recipe for success." --Chad Carlin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFAGUZsYiL4ten68SkRAjU0AJ9ARnnF7CRmRDz4nrBq7o1aeeDesQCfWHLz
QYbbKWFOqES5ZmWNeQBSWMQ=
=HyPO
-----END PGP SIGNATURE-----