Re: [Axiom-developer] Re: votes

[Ayal]

Hi,
As a fellow maintainer of a competing CAS system (Yacas) I have been
following recent discussions on this mailing list with great interest. It
is not unlikely that I might run in to similar problems in the future.

For what it is worth, here are a few thoughts I had.

Democracy in an open-source project
===================================
A democracy is not always the best approach. Most successful open-content
projects out there (Linux, Wiki, Slashdot, ...) have a form of moderating
system where 'trusted lieutenants' determine what goes in and what
doesn't. These people need to know what they are talking about. Linux is
complex enough that you don't want a beginner messing up the code. A CAS
is quite complex too, you need to know what you are doing. You need the
lead maintainer and his trusted lieutenants to verify that patches adhere to 
the long-term vision of the
system.

They are end-responsible for it in the end, including maintaining the
system. You also have the case that people add things to the system, and
then go do something else, leaving the maintainer to maintain their code.
With CAS this can be very sophisticated code rooted in deep mathematics.
The people committed to maintaining the system (for the next 30 years no
less!) *have* to understand all the parts of the system, and agree with
how it is set up.

The trusted lieutenants are not voted in through a democracy, but assigned
the role by the lead maintainer, the leader, the visionary, the owner of
the branch, who calls the shots in the end. This sounds a bit pompous,
but in practice this *is* what is needed, I believe. A democracy will not 
automatically lead to
better decisions per se in *every* situation. More specifically, when you
have a situation where a certain group is better informed than another
group, you need to have the better-informed group make the decisions. A
good example is an army. There you have uninformed soldiers in the field,
and informed officers (went through training in strategic warfare and get
intelligence on what the enemy is doing) at the center.

I am not suggesting that developing a CAS is similar to warfare, but one
aspect of it is the same; you have a group of better-informed individuals
who are better suited to making decisions. Better to have them take the
lead than to use a democracy and allow every one to vote with equal
weight.

Vision
======
With a big project comes a long-term vision. The leader has a vision, and
tries to get other contributors to buy in to his vision.

The vision is very important. It determines how the system develops over
time. Is the focus on cross-platform? Research? Or targeted at people
wanting to just do practical calculations? Easy to start using? Or very 
powerful but with a
steep learning curve? Easy to maintain code or very efficient code? Where
do we put abstraction layers that allow customization of the system for
different applications? Focus on symbolics, numerics, or some subset of
mathematics to become very good at a very specific type of calculation? Or
be general purpose? There are a lot of design decisions that need to
be made. Different ssytems (and possibly even different branches of the
same system) can be built based on different visions.

It is essential that every one working on a branch has the same vision.

Different branches are maybe not a bad idea, just like having different
systems is not a bad idea per se. The different systems have different
properties, and are useful in different situations.

Regards,
Ayal