[IAEP] Volunteer-driven development of educational software

Bill Kerr billkerr at gmail.com
Mon Nov 10 19:41:59 EST 2008


On Tue, Nov 11, 2008 at 9:27 AM, Greg Dekoenigsberg <gdk at redhat.com> wrote:

>
> On Mon, 10 Nov 2008, Bert Freudenberg wrote:
>
> > Cutting this important part out of another discussion ...
> >
> > On 10.11.2008, at 20:49, Jecel Assumpcao Jr wrote:
> >
> >> Of course, this all supposes the open source model. If someone gets
> >> paid
> >> to do a Python Etoys or a GNU Smalltalk one then I wouldn't be at all
> >> surprised to see a good quality implementation created from scratch in
> >> just a couple of months.
> >
> > I have been thinking about this for quite a while - how valid is the
> > assumption that a volunteer community would be able to create software
> > that they do not intend to use themselves?
>
> It is absolutely invalid, IMHO.
>
> > For example, Etoys development was not driven by volunteers, but by a
> > small research group around Alan Kay with paid developers. It is open-
> > source and free, but we get relatively few contributions from volunteer
> > developers. This is in contrast to Squeak, the underlying system, which
> > is supported and advanced by a thriving community of developers. But the
> > majority of the Squeak community is not interested in Etoys, just in the
> > Smalltalk development system (which they use and improve for
> > themselves).
> >
> > I see a similar issue with Sugar - since no-one seems genuinely
> > interested in making it their own environment, but rather developing
> > it for someone else, progress pretty much is made only by the
> > (unfortunately few) paid developers. The few parents / teachers who
> > might want to contribute are not savvy enough to actually do so.
>
> Yep.  This is exactly right, and is one of the driving ideas behind making
> Sugar a first-class desktop environment in Fedora.
>
> There are a number of compromises to be made, I think.  No, the typical
> Fedora developer will not be a teacher or a kid -- but if they grow
> accustomed to using Sugar, they will experience pain, and will be
> motivated to fix that pain in a way that is consistent with Sugar's goals.
> Assuming that (a) the pain isn't so terrible as to make it unusable, and
> (b) we are effective in communicating Sugar's goals.
>
> Seriously, though: journaling and collaboration, by themselves, are
> exciting not just to kids but to regular people.  The idea of
> "CollAbiWord" is incredibly exciting to everyone I discuss it with.



I thought walter's comments in a recent digest about the relative merits of
synchronous to asynchronous collaboration, (based on comments from Juliano
Bittencourt) were a slight step back from the merits of real time
collaborative writing, for instance

Some good educators argue that group work is over rated because the
individual needs to develop their own voice (philosophical objection,
strong) Others don't like it much because it is difficult to
measure.(pragmatic objection, not so strong)

"CollAbiWord" is an interesting idea - has it been fleshed out
educationally, I can't see where?

I read Bert as raising two points:
1) eat your own dog food - people here will agree to the importance of that
2) the educational vision - more difficult

I can see that etoys had a strong educational vision based on visual
programming, late binding, OOPs supported by people like Bruner ("doing with
images makes symbols")

I can see that logo has a strong educational vision worked out by Papert who
built on top of Piaget (eg. the body syntonic turtle)

Both of the above are disputed and partially understood but they are well
theorised and radical - in that sense "inspirational" even if not proven to
be correct

A big literature is now being developed about computer based collaboration
for education (web2.0 authors, numerous) - but its very messy at this point
of time. I think what is happening is a patching together of different
visions some about incremental improvement (eg. moodle philosophy) and other
which are more radical (Papert, Kay). That's probably inevitable and I don't
have a big problem with it but it might be important to understand that it
is happening.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20081111/e05fe4f7/attachment.htm 


More information about the IAEP mailing list