[Its.an.education.project] An "About" statement? (Was: untangling constructionism)
gdk at redhat.com
Mon May 5 17:05:28 CEST 2008
On Mon, 5 May 2008, Walter Bender wrote:
> Another iteration:
> "It's an education project."
> (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;
> (4) We are examining and discussing Sugar's educational importance.
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
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
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!!!!!
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"
More information about the Its.an.education.project