what to do

[Tom Lord]

This message doesn't argue for any new features for Guile.  It doesn't
propose a new way for Guile development to proceed.  All it does is
present my point of view, try to help explain why the state of Guile
seems wrong to me, and raises the question of what, if anything, to do
about that.

Guile started with the idea of building a Scheme-based GUI application
framework and some specific applications of that framework.  The
rough design of that framework was fixed in my mind (and still is).

The framework I had in mind wasn't especially original.  It consists
of a collection of ideas that various hackers I've known have traded
around informally for many years -- we've worked on this for a very
long time.  Guile started off as an effort to put those ideas together
into a working system.

To give you some idea of what the framework is about, consider
generalizing Emacs.  Emacs is an application framework.  If you want
to write, say, a mail reading program -- you don't write the program
and then "link emacs in" as an extension language.  That's doing it
inside out.  You start with Emacs, and then write an extension that
implements mail-reading features.  In that way, you can write the mail
reading program with a lot less code, leveraging all the functionality
that's already in Emacs.  As a side effect, your mail reading program
can be combined (by end-users) with other extensions (e.g. a contacts
database, or a TAGS package) in surprising and useful ways.  

One idea of the Scheme-based GUI framework is that the approach taken
by Emacs can be generalized well beyond text-editor applications.

Such a project can work.  In the course of my participation with
Guile, the hardest parts were (sloppily) prototyped and tried out
(mostly in unreleased code).  A clean implementation will work just
fine.  The obstacle is that it will take some time to do well, and a
dedicated team who gets along, who have a shared software aesthetics,
who can share state about the project at high bandwidth, and who can
work on the project full time.  (No small order, I realize.)



           Confused Leadership, Diluted Goals, Wasted Time

One thing that went wrong in the early days of Guile was a severe
dilution of goals.  Rightly or wrongly, I believed that the commercial
support for the Guile project was tenuous at best, and in an effort to
shore it up, accepted all sorts of new goals that diluted the project
almost beyond recognition.

In a famous and silly flamefest, some of us decided that the
popularity of Tcl/Tk was the largest challenge to commercial support
for Guile, and spent too much time fighting against that.  For
example, lots of time was spent worrying about making simplified C
api's to Guile, and building a Guile interface to Tk.  Those things
are arguably valuable, but they contributed nothing to the original
goal.

Grateful for an endorsement by the FSF, I accepted goals aimed at
Emacs lisp compatability and spent too much time worrying about how to
implement those.

Trying to improve the "business case" for Guile, I wasted time on
features like the mesa/glut/giggle, and ctax at a time when sticking
to the original project could very well have yielded more useful
results.

Sorry.




                          The Bizarre Bazaar

Early on, I believed that the (then unnamed) bazaare model of software
engineering was unproblematic and likely to yield good results.  In
the absense of a dedicated team, I turned to the net for help.

The early mailing list discussions were noisy with arguments and
extremely hypothetical "what-ifs".  That seemed good, at the time,
because occaisionally these discussions would open my eyes to features
of the design space I hadn't previously noticed.  But on balance, over
time, those discussions also caused all sorts of problems.  They took
lots of time, often without really helping.  They weren't systematic,
and often seemed to just go in circles. They led to volunteers
contributing code that was far afield of the original goals, and that
created maintenance headaches.

I had hoped for a volunteer community that would pretty much sync up
with my design aesthetics for Guile and that we'd have a quick and
efficient barn raising.  I had assumed there was enough shared state
for that to happen.

Instead, roughly five years later, I return to the field, see lots of
lumber lying around, some not-obviously-related half-finished
structures, and a team of volunteers who are happy to pass at least
some the time discussing whether we want to build a round barn or a
grand stable.  Worse still, there are some farmers around trying to
use the half-completed structures to store things.

I think that these problems may very well be inevitable with the
bazaar model of development.  When everyone just starts piling on
features and contributing uncoordinated design suggestions, there is a
tendency just to wander aimlessly around the design space until
externally imposed backward compatability requirements freeze
progress.  You could argue that that's good: that the random walk
proceeds until it hits a feature set that people like.  But you could
also argue that that's bad: a direct walk to a moderately distant
high ground is pretty much ruled out, in the absence of full-time
team of core developers with a shared vision.



                             Suggestions?


So now I'm not sure what, if anything, to do for or about Guile or for
or about the original project.

I still believe in the original project -- the Scheme-based GUI
application framework.  My prejudices about how the dialect of Scheme
should be extended for this purpose are still intact -- if anything,
they are clarified and stronger.

But the commercial support that would let me work on the project full
time is long gone.  The current volunteer community at least arguably
has its own momentum supporting gnucash and similar projects.

I experimentally dropped in to this list with a bunch of contextless
suggestions for features from Systas that I think help make it a nicer
dialect of Scheme.  I also raised the issues of inadequate testing in
both implementations, and a deep design flaw in the GC they have in
common.  But the result seems to be more the usual random walk around
the design space.

Any clever suggestions?