[Its.an.education.project] An "About" statement? (Was: untangling constructionism)

[Greg DeKoenigsberg]

On Mon, 5 May 2008, Walter Bender wrote:

> Another iteration:
>
> "It's an education project."
>
> Summary:
>
> (1) Learning practice and theory need to evolve as technology evolves; 
> we are discussing constructionist (and other learning theories) research 
> and practice;
>
> (2) We are engaging in an open dialog between the overlapping 
> communities of software developers and educators;
>
> (3) We are guiding Sugar software development, as it serves as a 
> tangible structural underpinning for the application of 1 and 2 above; 
> and
>
> (4) We are examining and discussing Sugar's educational importance.

My $0.02:

I am a novice in the language of constructivism, so I will speak directly 
to the parts of the conversation I understand, and feel that I can bring 
value to.

IMHO, the revolutionary things about the Sugar interface, and the things 
that are therefore most worth defending, are the notions that (a) kids 
should be "sharing by default", and (b) kids should be able to tinker. 
These are the things that make "activities" different than "applications". 
If Sugar activities allow and encourage *both* of these behaviors, then 
they are successful.  To anyone with any experience in free software 
development, the reasons for choosing free software for this endeavor are 
obvious, and need not be belabored.

Other people continue to focus on "applications".  Other people will 
tackle challenges like getting Flash to play on particular configurations, 
and tweaking hardware to benefit these kinds of applications.  Good on 
them.  It allows us to focus on solving the challenges that will 
*actually* make a difference long-term.  Namely:

0. Making it *dead simple* to install Sugar everywhere.
   a. Which means packaging for every distro and every virtual machine,
      and removing hw-related olpc-isms wherever possible.

1. Making it *dead simple* to write Sugar activities.
   a. By demanding rock-stable apis, no matter the cost.
   b. And by making lots of awesome example code that uses these apis.

2. Making it *dead simple* to share Sugar activities.
   a. By figuring out an architecture that allows discovery of
      activities across the entire world... a hard problem.  :)

>From where I sit, these three challenges are the *only* things in the 
critical path (from an engineering perspective) right now.  They are 
fundamental to creating the network effect that ultimately will be 
required to make Sugar successful.  If I've learned any lesson in my years 
in Fedora, it's this: attempts to generate community are wasted if there 
is not an adequate architecture of participation to sustain that 
community.

In the end, Sugar is a *software* platform that supports *constructionist 
learning* through the development of compelling educational *activities*. 
To paraphrase our favorite monkey boy: activites, activities, activities. 
Activities!  Activities!  Activities!  EEEEEEEYAH!!!!!

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"