[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: A student comment

From: Ondrej Certik
Subject: [Axiom-developer] Re: A student comment
Date: Wed, 5 Sep 2007 01:44:56 +0200

> I started open source programming in the late 90s and was quite
> idealistic about the whole idea, contributing to other projects
> and starting my own project (Pinger).
> In the last few months I've gotten quite cynical. I don't see the
> sense of community, cooperation, and selfless assistance I used to
> see. Now I see a great deal of "it should be different" but no actual
> code to support the "should". Or "it should run on X" with no actual
> code to support the "should" (hyperdoc? graphics? sman? clef?). Or "it
> should be licensed thus" with no thought of the great deal of effort
> freely given under the current license. Or "it should be windows
> based" with no effort to try to actually make it run. Or it has a bug
> with no effort to find/fix/test/diff/patch the bug. Or "it should
> .... " fill in whatever anyone has an opinion about what "it should
> do" or how "it should be".
> I remember a time when open source was characterized as a group of
> people who "scratched their own itch", that is, they wrote CODE that
> make the world look like "it should". I remember a time when open
> source was characterized by people who freely gave away code so that
> others could benefit without restriction because it was the right
> thing to do. They used the code, they fixed or extended the code, and
> they sent the changes back, a very small part of a much larger whole.
> I have wasted a year debating. I have wasted a year listening to
> people say what it should do. I have wasted a year trying to explain
> to people that this is open source and there are certain norms about
> how to contribute code and documentation. I have been posting
> diff-Naur patches to try to show how contributions are done.  I have
> lost patience with people who say "this is nice but..." or "it should
> do this" or "make it work the way *I* want it to work" or "graphics
> should run on windows" or "this isn't windows so it is archaic" or
> whatever the complaint is.
> Opinions about what "it should do" are worthless. No code, no sympathy.
> Download the code, scratch your itch, test it, document it, diff it,
> and post it. I've done that with projects, had patches rejected (e.g. noweb)
> and accepted (aldor tutorial typos, presumably). But I made the effort.
> Students need to find their own motivation. Either the itch is great
> enough and the student good enough to scratch it or not. Asking for
> help in fixing/extending/documenting is well supported. I just built
> a whole Suse 10.2 system and an axiom image to debug a problem. But
> the person with the problem ACTUALLY TRIED to do something.
> I'd have been much more sympathetic if the student sent in a patch to
> make )help start hyperdoc on windows. I don't recall seeing a patch.
> The student has the source, the student has the time, the student has
> the opinion, the student has the itch. I await the patch.
> Tim, the newly cynical curmudgeon.

I understand your annoyance with a behavior of someone just
criticizing without doing anything. Nevertheless, I myself just ask a
question - why am I doing the opensource project? My answer is,
because I want people to use it. Thus being able to know how the
majority of people would like to use my project is crucial. I have no
problems with someone just stating what he expected, or what he was
annoyed about.

The "send a patch or shut up" attitude is perfectly legitimate, but I
think there are also other attitudes that can help the project more.
For example, you can come to the SymPy mailinglist and say whatever
you want, more criticisms, the better. I think it's very important for
new users of any software to experience a pleasant surprise, not to be
annoyed. With the "send a patch or shut up" attitude, you will never
know, what exactly your users don't like on it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]