[IAEP] Sugar Labs 2017 Budget

[Tony Anderson]

I hope I have made myself clear. The future of Sugar Labs, if it has 
any, is to provide Sugar on all widely distributed platforms so that it 
becomes a viable option for potential adopters. Sugar Labs needs to 
understand that a parent or educator who is looking for an educational 
platform is not going to build a development environment and demonstrate 
their knowledge of PRs by fixing random bugs or install a Fedora desktop 
to generate an SOAS stick.

Sugar Labs needs to release 0.110 for easy installation on PCs, 
Raspberry Pi, and Windows 10. It then needs to document  'Get Sugar' on 
the Sugar Labs website for non-technical computer users. It needs to 
re-focus on the goal to provide a constructionist learning environment 
for primary school children. None of this requires an academic analysis 
suitable for an MBA dissertation.

Naturally, Sugar Labs needs to continue to work with James Cameron to 
provide viable software for the XO. We must thank Lionel Laske every day 
for understanding this issue and developing Sugarizer to provide some of 
Sugar's capabilities to the huge installed base of mobile devices which 
do not support Python.

I think we need to remember the mission of OLPC/Sugar - to provide a 
better learning opportunity to children on the wrong side of the digital 
gap. Our hope should be that wide availability of Sugar on PCs and 
Raspberry Pis will make it a viable alternative for installation in the 
deployments served by Computers for Kids, Rachel, and others where there 
is no internet availability, no prior computer experience for either 
teachers or students, and no funds to purchase anything. These 
deployments depend on donated equipment from organizations and 
individuals on the right side of the gap.

This, of course, is the fundamental problem of SOAS. It serves an 
environment where a child has access to a computer at home and sometimes 
one at school. SOAS makes it possible for the student to carry the 
learning environment between the two worlds. However, on the wrong side 
of the gap, there is no concept of a computer at school and a second at 
home. In many cases the reality is that there is no electricity at home. 
In this environment Sugar needs to be installed on the local storage of 
the computer.

These millions of Android devices have a basic problem - they depend on 
connection to a network. In additon, the UI is designed for consumption 
and is not conducive to constructive learning. How many of its myriads 
of education apps are available open-source, free and for offline use? 
Sugarizer and GCompris show that it is possible to work around this 
design and its hyper-commercialized face.

In the meantime, miraculously there may be a school with Sugar on XOs 
and, hopefully, a schoolserver to stand in for the internet. Even more 
hopefully, the school allows the children to take a computer home with 
content to work on which was downloaded from the schoolserver (so far, a 
dream generally unfulfilled).

OLPC is fading not just as an organization but as a concept. Even some 
of our most robust OLPC deployments are moving to the computer lab 
model. The Raspberry Pi in, for example, the Computer for Kids 
deployments, is in a lab (the computer with keyboard, monitor and 
without a battery is not portable). The only hope for constructive 
education is to find a way that these labs can be made available to 
students after-hours or on weekends for unprogrammed use. This critical 
issue seems invisible to the Sugar Labs community.

One requirement that our current developers seem to have forgotten is 
that in an environment without the internet, students need to download 
content to the laptop so they can work with it away from the school 
server or other network resource. How does a student read Alice in 
Wonderland online in a classroom or computer lab? This implies a school 
server which serves the content from the internet selectively to 
computers with very limited storage capacity. Hand-waving at the 
internet like the Get Books activity or web services is relevant in 
Boston or other location with 24/7 broadband internet but not on the 
other side of the gap. Modifying Browse to replace the Read and Jukebox 
activities without support for downloading the media and playing it from 
the Journal is similarly misdirected.

Given that neither students or teachers in this environment have been 
brought up in a 'computer culture', without help - nothing happens. It 
is not economically feasible to provide counselors to work directly with 
the teachers to stage, for example, a Turtle Art day (i.e. as a way to 
introduce teachers and students to new capabilities available on the 
computer). My current focus is on providing 'turtleart day-like' 
documentation showing students how to perform tasks step-by-step to 
explore new capabilities. In Rwanda, this led to teacher training on how 
to access and use the documentation - with the documentation available 
through the school year. Since there was no funding for a schoolserver, 
this led to a roomserver - serving the documentation and other content 
from an SD card using SimpleHTTPServer.py and the adhoc networks.

The new science curriculum in Rwanda, thanks to the efforts of Eric 
Kemenyi at Rwanda Education Board, calls for school-age children to 
learn programming in Scratch, Etoys or Turtle Art. Amazingly, Sugar 
supports all three plus learning to program in Python and in web 
technology (static: html/css and animated: javascript). This is not to 
mention the essential tool for Linux users, bash scripting.

Imagine the excitement of a primary school student who discovers that it 
is possible to write a program in python (e.g. hello world) and have 
this program appear on the Home View (with the help of Pippy). Imagine 
the motivation to learn to make a custom icon for the program in svg. 
Imagine the motivation to make the program available to classmates by 
collaboration or via a schoolserver. This is the way constructive 
education should work - get a learner started at a simple level and show 
the path to increasing capability.

The educational potential of Sugar is amazing and amazingly neglected. 
Consider that we have deployments in Uruguay and Peru which have 
resulted in every person in both countries under the age of 20 being 
familiar with Sugar. The Sugar Labs community appears to be totally 
oblivious to this experience with remarks like - are there any computers 
with 13.2.8 installed? As most of you know, a pet peeve of mine is that 
localization is viewed by Sugar Labs as a professional enterprise, not a 
learning opportunity for our users.

Arguably, Sugar Labs has more experience with promoting constructive 1-1 
learning supported by computers than anyone on the planet. What 
advantage are we taking of this experience? Why don't we know how many 
laptops are deployed within a factor of 10? Why don't we know what 
version of Sugar is installed. (It is easy for developers to update 
Sugar hourly but it is another story to take Sugar on a three-day hike 
in the Andes to reflash the XOs). Most importantly, why don't we know 
what are the successes and failures of these deployments? Try to name a 
feature of Sugar introduced based on the experience of one of our 
deployments.

None of this has to do with the age of the XO. It is still the only 
alternative for deployments envisioned by the OLPC concept. Its design 
brilliantly met this requirement. Unlike brake pads, electronics don't 
wear out. There are components such as the battery that do. The 
solid-state store apparently does also.

So naturally, it would be helpful to have in serial production a $200 
laptop with the capabilities of the XO for new or expanding deployments. 
I have been looking for the past five years but have not found anything 
even close to a viable alternative.

Keeping the XOs running needs some product development. First, we need a 
replacement battery whose design avoids current transport restrictions 
on lithium batteries. The solid-state problem is much simpler: On the 
XO-1, go to the sd card image. On the later models, replace the micro-sd 
chip. In deployments, the major problem with the XO is not performance, 
it is storage capacity.

Tony

On 03/01/2017 06:04 PM, Dave Crossland wrote:
> Thanks for clarifying :)
>
> The question remains then: Is Sugar Labs to direct attention entirely 
> to a few hundreds of very-to-somewhat old XO laptops maintained by 
> experts like Tony and those in Caacupe, or to the millions of children 
> who have computers/tablets capable of accessing/installing Sugarizer, 
> or to some mix of the two; and if the latter, what mix is appropriate 
> in 2017 and 2018?
>
> On 1 March 2017 at 05:26, Tony Anderson <tony_anderson at usa.net 
> <mailto:tony_anderson at usa.net>> wrote:
>
>     All models are obviously xo-1, xo-1.5, xo-1.75 and xo-4. Sugarizer
>     is not relevant since the XOs deploy Sugar. The Sugarizer
>     activities are mostly also available as Sugar web activities. We
>     are using the Python Turtle blocks.
>
>     Tony
>
>
>     On 02/28/2017 02:29 PM, Dave Crossland wrote:
>>
>>
>>     On Feb 27, 2017 11:34 PM, "Tony Anderson" <tony_anderson at usa.net
>>     <mailto:tony_anderson at usa.net>> wrote:
>>
>>         For what it's worth, Sugar 0.110 (OLPC OS 13.2.8) has been
>>         installed on hundreds of XO laptops, all models in Rwanda.
>>         The codebase is reaching these classrooms.
>>
>>
>>     That is great to know!!! :)
>>
>>     What xo models are those?
>>
>>     Does anyone know of any other classrooms using the latest release?
>>
>>         I am not sure what you mean by the js codebase, but if you
>>         mean the sugar web activities. Yes they are available for
>>         optional installment (along with the other activities in ASLO)
>>
>>
>>     Sugarizer
>
>
>
>
> -- 
> Cheers
> Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20170302/40267d9e/attachment-0001.html>