Great thanks are due to Jason G. for starting to distill some of the issues involved in the developments leading to sage-edu in a very gracious manner. I hope to add, in a similar vein (nothing about APIs, sorry!), more commentary on some more of the underlying issues, and a request to the "main development team" (a fluid term in an open source project) for some suggestions to help the rest of us contribute more substantially.
As a relative newcomer to open source, it's been interesting watching some of the same growing pains and sociological issues that Eric Raymond (and other more scholarly outside observers) describes so well. Particularly interesting is that here it seems to come from the (fairly atypical?) fact that a significant number of true end users of a program have been directly involving themselves in development, even if primarily via feature requests and not as much via code. I say particularly interesting because the highest profile open source projects (e.g. Mozilla, Apache) are used by millions of people daily without any thought to development, and in my grad school days most of us who used very important ones like Linux and TeX asked someone else nearby with questions, and never thought to ask a developer for an enhancement! I sense a much higher proportion do with Sage. In addition, with Sage we have a program with developers and end users with remarkable affinities - to its credit. It is being used by scores of people outside the (early) original target audience who are just expert enough to understand what is going on behind the scenes and are also excited about the primary use (here, math research), and yet is being developed by people who largely have some experience and affinity to those additional uses (here, pedagogical). This is largely because, at heart, mathematics is a much more unified discipline than some others. However, there is nonetheless a fundamental asymmetry with any technology between those who know how to use it most profitably and those without that expertise (e.g. medieval users of Roman numerals fighting against the introduction of decimals as a "leveling" influence). This asymmetry isn't inherently bad if the non-expert is given the benefits of the technology fairly; in fact, it can promote efficiency since the non-expert can become expert in something else. Certainly in a case like Sage, it doesn't stand in the way of bugs/ features that *everyone* wants to catch/use being thought of with amazing swiftness, because of my above point. But this asymmetry can become a problem. Sage seems to have fallen victim to its own success, for instance in discussions about the cube root of -1, or in increasing demands on time of the core developers for what are essentially side issues. Anyone in academia should be very sympathetic to time constraints, but the real issue is not that there isn't enough time, but that a conscious (and reasonable) choice has been made to focus Sage development on things like modular forms. However, that leaves the question of how to continue improving the more pedagogically useful aspects of Sage (e.g., the notebook and calculus package), which everyone seems to agree is a very good thing. (Here comes the part where I ask for help.) I think that most pedagogical Sage users would like to help in ways that they can, and most research Sage users really do appreciate being able to make a quality competitor to "the M's" for teaching purposes at no (monetary) cost. So what I am asking for (perhaps on sage-edu, certainly not here) are concrete suggestions for how that can happen, given several limiting factors. I outline some of these limiting factors at length below, and offer tentative suggestions for some of them. The bottom line is this; what mechanisms can be put in place now to help the education community create patches, and eventually significant code, without needing to constantly divert developers from the core directions of Sage? Then a call to "show me the code" (which Jason already pointed out is eminently unreasonable at this time) might have a chance to be honored not just in the breach. If we can do this, for the first time a totally free option which supports mathematics in pedagogically sound ways all the way from arithmetic and geometry to arithmetic geometry will exist, with huge benefits for anyone who cares about more than one level of mathematics. - kcrisman Here Follows A Perhaps Superfluous Long List Of Limiting Factors and Suggestions Which Might Help Combat Them. Limiting Factor 1: If research mathematicians and grad students are pressed for time, many high school teachers and professors at teaching institutions have been squeezed completely dry before they ever embark on trying new things like Sage. Sometimes they are actively discouraged from it, though that hasn't been my experience. I don't know that there is much one can do about this, but I put it first because it directly impacts all the other limiting factors. Limiting Factor 2: Who is trying out Sage from the education community? My sense is that to some extent they are people at institutions which do not have enough resources to afford site licenses for the competitors of Sage in the first place. These institutions tend to be precisely the ones where teachers are least able to find time and least likely to already have the experience to conquer the other factors. It seems like Sage is starting to alleviate this somewhat by attracting education people who hear about it through its research aspect, but there is more work to be done in finding people who can help and are willing to leave the big boys. The JMM booth was a huge step in the right direction. Limiting Factor 3: Many educational would-be developers are not really sure what is needed to implement that can be done on a step-by-step basis, other than by finding bugs or comparing with other programs. This has already been discussed quite a bit elsewhere. An additional suggestion would be that a Moore-method style list of functionality, each step of which could be implemented by someone without a full grasp of the larger development vision of Sage, could be helpful (e.g. define some minor class, write these methods for it, interface them with this other class, add these basic examples, etc.). (A personal note relevant to this factor and the next is appropriate here. I've learned far more programming than I ever dreamed I would through Sage, and it's been exhilarating. I would love a list of theorems like this, similar to the Euler thing someone else mentioned a while back for learning Python. But there is no way I will be able to contribute more than here and there *on my own* without radically restructuring my work load, which would mean getting a different kind of job, or even not having one at all. I wish Sage had existed when I was a grad student!) Limiting Factor 4: The fundamental technological asymmetry will persist. Although people like David Joyner and (now former developer?) Ted Kosan do have the experience to do so, many of those fairly interested in education who Sage will want to attract to this simply will not have anywhere near the background necessary to do real development without a lot of hand-holding or an intensive course in things like server interaction and the ins and outs of initialization and overloading. A possible solution to this, though a very expensive one, would be to find funding for a summer Sage Education Days where precisely this sort of thing could happen, leading to a much more independent education group. Others will know more about this, and it's been mentioned, but it would seem that there is a lot of federal money out there for helping develop already-tested programs in the educational context. Even GeoGebra, a German product, seems to have done so in this country, and there are lots of far poorer-quality and far more localized (in geographical use) programs than Sage to have gained such funding. On a more immediately realistic level, a modest program of regional weekend events with a small registration fee asked of participants could attract enough people to be worthwhile as well. Limiting Factor 5: Not-yet-developers receive mixed signals on how much support they can expect on sage-support, particularly in terms of requesting functionality. Sage has some extent become a victim of its own success - many of us, especially "early adopters" (pre-slashdot) got immediate responses on sage-support or to personal emails, and started relying on that help, rather than switching programs or just giving up on using a computer mathematics program. An impartial observer of that and the huge increase in downloads would have seen the trouble ahead. The reason this is a limiting factor to educational developers is simply frustration of not knowing when it's time to start and when it's time to ask. I have absolutely no idea what to do about this; brusque responses of not having time (or no responses) will turn off brand-new users as much as answering endless sequences of continuing trivial questions will turn off long-time developers. The creation of sage-edu could be a step in the right direction, or it could be a dead end. It doesn't sound like sage-edu folks (if that proves to be a viable long-term concept) would not be discouraged from asking continued questions of sage-devel or even contributing to discussions there, but making this clear is essential to its viability. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
