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

[Pamela Jones]

I'd add a fourth item, Greg, because I think it's the winning ticket in 
sales going forward:

security.

We are talking about children. They must be protected from malware, 
phishing, botnets, etc.  That is *never* going to be possible with 
Windows software, and that is how Sugar can be presented by the sales 
people, I think. Not that it's infallible, because FOSS folks always 
tell the truth, but I'd focus on it very hard as a selling point, 
because the whole world knows Microsoft is not secure. The DOD knows it, 
and they are switching to GNU/Linux because of it.

So why would any government/school wish to endanger their kids?

Greg DeKoenigsberg wrote:
> 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
>