[IAEP] Volunteer-driven development of educational software

[Greg Smith]

Hi All,

On the question of Open Source to develop applications which are not 
necessarily used by the people who write the code. That is a challenge 
which I think we should address directly.

Greg D's strategy (programmers code for themselves then we re purpose it 
for schools) may be the most fruitful in terms producing lots of 
applications quickly. I certainly hope so.

It still leaves open the question of how to adapt the result for use in 
classes and how to tie the applications in to the learning theory. Maybe 
that last stage is a job for paid programmers instead of open source 
volunteers. As more applications become available for the XO/Sugar we 
can see which get the most demand in schools and go from there.

On the other hand, I hope David is correct that we can find people who 
will work on things which the teachers and students need, even if they 
don't "scratch your own itch". In addition to finding such programmers, 
the challenge is to define what teachers and students need in a way that 
is easily actionable.

We have lots of input from the field and some input from educational 
theorists. The hard part is focusing that in to something easily coded.

There is one nice synergy between the educational theory and the 
development strategy. I believe that a tenet of the educational theory 
is that teachers and students together choose the most relevant topics 
for learning. If programmers and users also follow that strategy of 
working together to choose the relevant "topics" maybe we could pioneer 
a new paradigm for open source development.

I wrote a brief explanation of this strategy here: 
http://wiki.laptop.org/go/User:Gregorio

On the question of asynchronous vs synchronous collaboration. If you 
read the beginning of the thread 
(http://lists.laptop.org/pipermail/devel/2008-October/020588.html) 
you'll see that neither Juliano nor I are opposed to synchronous 
collaboration ala "CollAbiWord". Juliano was just pointing out that we 
also need asynchronous collaboration (e.g. multi-kid projects) and that 
wasn't on the roadmap.

We need both and my impression is that the shortest path to major new 
functionality is on the asynchronous side. Any help defining the 
requirements and scope of that is welcome.

Please add your input here:
http://wiki.laptop.org/go/Feature_roadmap#Asynchronous_collaboration

We need more input on the educational research to see if either 
synchronous or asynchronous is better correlated to the theory. Any 
pointers or comments welcome.

Clearly the idea of learning by creating projects is central to the 
educational strategy  (see 
http://dspace.mit.edu/handle/1721.1/41706?show=full).

So is learning by doing and working together. I'm just not sure if it 
has to be real time or not.

I can say that the kids love the real time write sharing when it works 
and they hate it when it fails. See: 
http://lists.laptop.org/pipermail/olpc-sur/2008-May/000118.html
When it worked: "they loved it ... it seemed like magic"
When the collaboration broke: "¡QUË DESILUSIÖN!!!!"

On synchronous collaboration I think the requirements are well defined. 
See: http://wiki.laptop.org/go/9.1.0_Collaboration_Requirements and 
http://wiki.laptop.org/go/Feature_roadmap#Synchronous_Collaboration

Comments welcome.

The challenge with synchronous collaboration is if/when/how we can 
support the requirements as defined. Maybe the open source community can 
get us over the hump on that...

Thanks,

Greg S

> Date: Tue, 11 Nov 2008 11:11:59 +1030
> From: "Bill Kerr" <billkerr at gmail.com>
> Subject: Re: [IAEP] Volunteer-driven development of educational
> 	software
> To: "Greg Dekoenigsberg" <gdk at redhat.com>
> Cc: iaep <iaep at lists.sugarlabs.org>
> Message-ID:
> 	<5d2dce520811101641v7a69f5cfm39e78f0e1a408e07 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 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.