[Axiom-developer] Axiom community goals

[daly]

Martin,

> This is simply not true, unless you don't consider myself as part of the
> community. In that case, I'll stop contributing to "your" axoim project
> today.

> I find it quite strange that you identify your goals with the goals of the
> axiom community. 

You do agree that the Axiom community has goals, right?
FriCAS will, and I'm interested to see what they are.

Some of those Axiom goals were defined when the project created, for
example, the goals of correct code, to try to prove programs correct,
and to make the code literate. The Axiom code was released by me as
literate code, not raw code. Thus I defined SOME of the community goals.

Other goals, driven by other people, have arisen over time and they
are compatible. For example, the ALLPROSE effort by Ralf and the drive
to include Aldor by many people. Stephen Wilson is working toward a
new compiler it appears. Bill Page has urged and Gaby has implemented
autoconf. Silver is in SVN.  Cliff has been working on ways to make
Axiom have a native understanding of literate documents. Cliff has
also volunteered to consider a new versioning scheme.  These efforts
are ongoing and have contributed to the breadth and depth of the
project.  They are in no way dividing the group.

However, I find these other events divisive and troubling:



Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00535.html>

Martin: At least here in Austria, most people use wh-sandbox

Cliff: Now, that's true. Eventually, we should reach the point where
       users should be using Gold by default

Martin: Cliff, please stop thinking about the future. Well, one month 
        is OK, but certainly not *now*. ...

Here I see Cliff explicitly supporting two fundamental project goals,
the notion that the Gold version should be the default and the idea
that changes will migrate there. I also see you explicitly state that
Cliff should ignore a fundamental, 30 year horizon view. You then
continue on this exchange with

Martin: .... If you want to implement a versioning scheme, please
        implement one that works with the current situation.
        If you implement one that works for Gold only, forget it.

I find this an odd attitude. If GCL implemented a versioning scheme
that worked for the main trunk but not in a developer sub-branch
you would reject the scheme? 

So I read from the above that if it isn't done by next month or if it
doesn't work in Waldek's branch it isn't worth doing? I will grant you
the point that this "arises from the community" but I hardly see how
this is compatible with the overall project goals. Not every idea
"from the community" is in harmony with the project goals.




Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00399.html>

Jose: Virtual machine http://wiki.axiom-developer.org/DoyenCD (Axiom Gold)

Martin: Hm, but didn't you have a live cd of wh-sandbox also? That's
        much better than Gold, since HyperDoc doesn't really work in
        Gold (dependents, users, etc. crash.)

I'm puzzled why you would ask Jose to do additional work to support
wh-sandbox rather than ask Waldek to hurry up and promote his changes
to the latest trunk. The fact that 
  (a) HyperDoc crashes and 
  (b) Waldek knows how to fix it and 
  (c) we all need those fixes 
all seem to suggest that making a diff-Naur patch available would be
"a good thing". Yet you seem to promote a branch and ask another 
project (Doyen) to support it.



Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00318.html>

Martin: I think, the easiest way to put off people is to discuss what
        great things one will do in the future.

Again you seem to feel that it is unreasonable for us to think or plan
or discuss ideas that are not done by next month. I understand that
you wish to use this work in your classroom and I understand that such
a goal involves a september deadline. I've taught at several schools
so I know the intense pressure. You seem to have lost sight of the 30
year horizon, which is fine. However, chastizing others for trying to
consider things that don't fit your timeframe seems like you're
elevating your needs above the group.

Unlike work, I'm unaware of any deadlines on this project. Things get
done when they get done. It is more important to do it right than it
is to do it fast, at least on this project. For instance,
defintrf.spad has a code sequence that uncovers a compiler bug. The
wh-sandbox branch patches the algebra code to ignore the bug rather
than find the root cause. It seems more important to fix the compiler
so future algebra cannot make the same mistake. This will take more
time but seems to be the correct fix. It is ok to patch a branch but
the trunk should "do it right".

The future is important, it affects today's decisions, and we need
to discuss it.



Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00308.html>

Martin: Use the tools at hand and build something that can actually compete
        with current CAS (plural). We fight with the future and haven't even
        reached the present.

I'd urge you to re-read my response which I won't repeat here. I would
point out that we're going in long term directions different from
other efforts. Perhaps FriCAS can fulfill the "competition" need. To
try to compete with MMA you need to write half-a-hundred
workbook/textbook treatments. You need to convince department heads to
mandate using Axiom. You need to have super-spiffy front-ends. NAG did
not succeed in that competition and I doubt we could do any
better. They had the reputation, the contacts, the company, the money,
and the motivation.  Competition is not an Axiom project goal, at
least not in the direct sense and not in the short term. We'll simply
change the playing field and let them try to catch us.

"A wise general wins a war without fighting a battle" -- Sun Tzu




Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00310.html>

Martin: We need (good) contributors now. I'm working quite hard on that.

I fully agree we need good contributors. Please define what YOU mean by
contributing to the project. I've already said what I feel it means to
contribute to an open source project, which I believe is the generally
accepted definition.

Martin: But I tell you, if we are still less than 20 contributors end 
        of next year, I'll probably  stop with Axiom. 

I sent a quote
<http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00019.html>
from Chris DiBona, et. al. in the Open Sources 2.0 book that points out
that Brooks' Law appears to set a limit of about 10 people. So it is 
unlikely we will have 20 people.



I've seen you make the comment that "you'll quit if ..." on various
occasions. There is nothing anyone can do about that except you.
I'd urge you to stay. We do need you.




Martin, I find that you've done some excellent work for the project.
You've done valuable work with the Emacs effort, along with Cliff and
others. That's quite useful.

You've contributed algebra to the project. It got merged into wh-sandbox
(which is certainly why you find that branch personally interesting).
I've asked for a diff-Naur patch for that extension so it could be used
on the trunk. Your response was to ask Waldek. Waldek did not post a 
patch. I have a local git branch where I'm looking at merging the code.
Yet when I asked you for test cases and further documentation I did
not get any. Since I don't understand the algebra how can I tell if it
works? 

Contributing does not stop when the code is "done". It should not fall
solely on my desk to "make it work", "test it", or "document it". The
fact that you can make it work doesn't mean others can. The fact that
it works in a branch should only give you cause to ask that it be
promoted to the trunk. Holding a branch that includes your code up as
"the best way to go" misses the point of branching in the first place.
I'm surprised you didn't insist on seeing a patch created.




Like Waldek, you can make a choice to continue with Axiom or not.
You can contribute to both Axiom and FriCAS, it isn't "either-or".
But whatever your choice, it is entirely up to you.

Tim