Re: [IAEP] 2017 Goals for Sugar Labs

[Walter Bender]

On Sun, Apr 9, 2017 at 7:56 PM, Dave Crossland  wrote:

> Hi
>
> Thanks Walter. I'd like to better understand some additional context
> before diving in :)
>
> Does this mean Sameer you have stopped the project planning process you
> started, and we should not expect you to restart it again?
>

At the most recent SLOB meeting Samson brought up the fact that we were
still waiting and so I volunteered to write something up to get the
conversation going again.


>
> Walter, are these the goals for this year, or are they your proposal for
> the goals for this year?
>

Not sure I understand what you are asking. I wrote up a draft of goals but
they are not "the goals" until we agree to them.

regards.

-walter

>
>
>
> On Apr 9, 2017 3:31 PM, "Walter Bender"  wrote:
>
>> As per the discussion in the last Suagr Labs Oversight Board Meeting, I
>> had agreed to write a draft statement of goals for 2017. The document below
>> includes feedback from Samson G. I hope this document can serve to
>> revitalize our discussion from 2016 that never reached resolution.
>>
>> Sugar Labs Plans, Goals, Aspirations
>>
>> What is Sugar Labs?
>>
>> Sugar Labs creates, distributes, and maintains learning software for
>> children. Our approach to learning is grounded in Constructionism, a
>> pedagogy developed by Seymour Papert and his colleagues in the 1960s and
>> 70s at MIT. Papert pioneered the use of the computer by children to help
>> engage them in the “construction of knowledge.” His long-time colleague
>> Cynthia Solomon expanded up his ideas by introducing the concept of
>> engaging children in debugging as a pathway into problem-solving. Their
>> 1971 paper, “Twenty things to do with a computer”, is arguably the genesis
>> of contemporary movements such as the Maker Movement and Hour of Code.
>>
>> At the core of Constructionism is “learning through doing.” If you want
>> more learning, you want more doing. At Sugar Labs we provide tools to
>> promote doing. (We focus almost exclusively on tools, not instructional
>> materials.) However, we go beyond “doing” by incorporating critical dialog
>> and reflection into the Sugar learning environment, through mechanisms for
>> collaboration, journaling, and portfolio.
>>
>> Sugar Labs is a spinoff of the One Laptop per Child (OLPC) project and
>> consequently it has inherited many of its goals from that project. The goal
>> of OLPC is to bring the ideas of Constructionism to scale in order to reach
>> more children. A particular focus is on children in the developing world.
>> In order to meet that goal, Sugar, which was originally developed for OLPC,
>> was by necessity a small-footprint solution that required few resources in
>> terms of CPU, memory, storage, or network connectivity. The major change on
>> focus from the OLPC project is that Sugar Labs strives to make the Sugar
>> desktop available to multiple platforms, not just the OLPC XO hardware.
>>
>> Who develops Sugar?
>>
>> Sugar Labs is a 100% volunteer effort (although we do occasionally raise
>> money for paid student internships). Sugar development and maintenance is
>> incumbent upon volunteers and hence we strive to provide as much control as
>> possible to our community members, including our end-users. (In fact, one
>> of our assertions is that by enabling our users to participate in the
>> development of the tools that they use will lead to deeper engagement in
>> their own learning.) Towards these ends, we chose the GPL as our primary
>> license. It has been said of the GPL that it “restricts my right [as a
>> developer] to restrict yours [as a user and potential developer]”, which
>> seems ideal for a project that wants to engage a broad and diverse set of
>> learners. But at Sugar Labs we go beyond the usual goals of FOSS: a license
>> to make changes to the code is not enough to ensure that users make
>> changes. We also strive to provide the means to make changes. Our success
>> in this goal is best reflected in the number of patches we receive from our
>> community. (We achieve this goal through providing access to source code
>> and development tools within Sugar itself. We also actively participate in
>> workshops and internship programs such as Google Summer of Code,
>> Outreaching, and Google Code-In.)
>>
>> Who uses Sugar?
>>
>> Ultimately, our goal is to reach learners (and educators) with powerful
>> tools and engage them in Constructionist learning. Currently we reach them
>> in many ways: the majority of our users get the Sugar desktop preinstalled
>> on OLPC XO hardware. We have a more modest set of users who get Sugar
>> packaged in Fedora, Trisquel, Debian, Ubuntu, or other GNU/Linux platforms.
>> Some users get Sugar on Live Media (i.e., Sugar on a Stick). Recently
>> Sugarizer, a repackaging of some of the core Sugar ideas for the browser,
>> has been finding its way to some users. There are also a number of Sugar
>> activities that are popular 

Re: [IAEP] 2017 Goals for Sugar Labs

[Dave Crossland]

Hi

Thanks Walter. I'd like to better understand some additional context before
diving in :)

Does this mean Sameer you have stopped the project planning process you
started, and we should not expect you to restart it again?

Walter, are these the goals for this year, or are they your proposal for
the goals for this year?



On Apr 9, 2017 3:31 PM, "Walter Bender"  wrote:

> As per the discussion in the last Suagr Labs Oversight Board Meeting, I
> had agreed to write a draft statement of goals for 2017. The document below
> includes feedback from Samson G. I hope this document can serve to
> revitalize our discussion from 2016 that never reached resolution.
>
> Sugar Labs Plans, Goals, Aspirations
>
> What is Sugar Labs?
>
> Sugar Labs creates, distributes, and maintains learning software for
> children. Our approach to learning is grounded in Constructionism, a
> pedagogy developed by Seymour Papert and his colleagues in the 1960s and
> 70s at MIT. Papert pioneered the use of the computer by children to help
> engage them in the “construction of knowledge.” His long-time colleague
> Cynthia Solomon expanded up his ideas by introducing the concept of
> engaging children in debugging as a pathway into problem-solving. Their
> 1971 paper, “Twenty things to do with a computer”, is arguably the genesis
> of contemporary movements such as the Maker Movement and Hour of Code.
>
> At the core of Constructionism is “learning through doing.” If you want
> more learning, you want more doing. At Sugar Labs we provide tools to
> promote doing. (We focus almost exclusively on tools, not instructional
> materials.) However, we go beyond “doing” by incorporating critical dialog
> and reflection into the Sugar learning environment, through mechanisms for
> collaboration, journaling, and portfolio.
>
> Sugar Labs is a spinoff of the One Laptop per Child (OLPC) project and
> consequently it has inherited many of its goals from that project. The goal
> of OLPC is to bring the ideas of Constructionism to scale in order to reach
> more children. A particular focus is on children in the developing world.
> In order to meet that goal, Sugar, which was originally developed for OLPC,
> was by necessity a small-footprint solution that required few resources in
> terms of CPU, memory, storage, or network connectivity. The major change on
> focus from the OLPC project is that Sugar Labs strives to make the Sugar
> desktop available to multiple platforms, not just the OLPC XO hardware.
>
> Who develops Sugar?
>
> Sugar Labs is a 100% volunteer effort (although we do occasionally raise
> money for paid student internships). Sugar development and maintenance is
> incumbent upon volunteers and hence we strive to provide as much control as
> possible to our community members, including our end-users. (In fact, one
> of our assertions is that by enabling our users to participate in the
> development of the tools that they use will lead to deeper engagement in
> their own learning.) Towards these ends, we chose the GPL as our primary
> license. It has been said of the GPL that it “restricts my right [as a
> developer] to restrict yours [as a user and potential developer]”, which
> seems ideal for a project that wants to engage a broad and diverse set of
> learners. But at Sugar Labs we go beyond the usual goals of FOSS: a license
> to make changes to the code is not enough to ensure that users make
> changes. We also strive to provide the means to make changes. Our success
> in this goal is best reflected in the number of patches we receive from our
> community. (We achieve this goal through providing access to source code
> and development tools within Sugar itself. We also actively participate in
> workshops and internship programs such as Google Summer of Code,
> Outreaching, and Google Code-In.)
>
> Who uses Sugar?
>
> Ultimately, our goal is to reach learners (and educators) with powerful
> tools and engage them in Constructionist learning. Currently we reach them
> in many ways: the majority of our users get the Sugar desktop preinstalled
> on OLPC XO hardware. We have a more modest set of users who get Sugar
> packaged in Fedora, Trisquel, Debian, Ubuntu, or other GNU/Linux platforms.
> Some users get Sugar on Live Media (i.e., Sugar on a Stick). Recently
> Sugarizer, a repackaging of some of the core Sugar ideas for the browser,
> has been finding its way to some users. There are also a number of Sugar
> activities that are popular outside of the context Sugar itself, for
> example, Turtle Blocks, which has wide-spread use in India. Harder to
> measure is the extent to which Sugar has influenced other providers of
> “educational” software. If the Sugar pedagogy is incorporated by others,
> that advances our goal.
>
> Who supports Sugar?
>
> When we first created Sugar Labs, we envisioned “Local Labs”—hence the
> name “Sugar Labs”, plural—that would provide local support in terms of
> local-language support, 

Re: [IAEP] [SLOBS] 2017 Goals for Sugar Labs

[Walter Bender]

On Sun, Apr 9, 2017 at 1:08 PM, Lionel Laské  wrote:

> Hi Walter,
>
> Thanks a lot for this long proposal. Great to hear you on that.
> I think that it's more a Sugar history than a goal/vision but it's good to
> read it from a guy that was the major contributor of the history.
>

I don't think it is wise to discuss goals without context. That said, while
you say my email is not about goals, the rest of your reply is in response
to the specific goals I outlined. Curious.

>
> BTW I'm not agree with your goals.
> My view is that it's not a good idea to limit Sugar/SugarLabs to makers.
> We can't target a so small market:
> - RaspberryPI ? RPI is a great tool. I personally used 2 RPI weekly for my
> personal usage. But it's a tool for geeks not for learners. It could be a
> good device as server (we're using it in classroom in France and in
> Madagascar and it's good for XSCE too) but it's a very poor tools for
> children: no screen, no keyboard, no mouse, not even a power adapter. It's
> just a board ! So I don't see the interest of Sugar on it.
>

I think you are failing to see the forest for the trees. I don't know the
extent to which you are spending time in education circles, but for
example, at EdFoo last weekend, the majority of the energy in the
unconference was all about making. The RPi is not a ends in itself but a
door into the energy that is current in EdTech. If we can get some pick up,
we have a great lever for amplifying and growing our community. That said,
the amount of effort required on our end is small -- a GSoC project at most
-- to take advantage of this.

- Trisquel ? Probably a nice Linux distribution but how many users ? Not at
> all a largely distributed distribution like Fedora or Ubuntu.  Why doing
> effort on it ?
>

I mention Trisquel not because it involves any work on our behalf -- Ruben
is doing that work already -- but rather to be able to point to that work
as an example of how the FSF and FOSS movement could rally around us.
Again, to whatever extent that they have synergy with us and help promote
us, this is a benefit.

>
> I can't understand you even mention Windows support in your goals: just
> 99,9% of the PC market ! So if you're a Windows user you can't be a target
> for SugarLabs ? Plus, regarding devices: we should be better on touch
> devices because tablets is the favorite learning tools in classroom today,
> not PC. It's why Android (80% of the tablet market) and iOS are so
> important in my mind. We should go where users - children/teachers - are !
>

I don't know where you are getting your data, but I don't believe for a
second that Windows controls 99.9% of the school market and even if it were
true, the Windows desktop market in schools is waning (not good news for us
either). Chromebooks are are the rise. And, to a lesser extent, Android
tablets. (Apple is losing market share). It is exactly for these reasons I
think we should be putting effort into Sugarizer. It has been discussed --
most recently since Samson's April 1 prank -- that a Windows port is
probably not worth the effort given our limited resources. Still open to
hearing arguments to the contrary.

>
> We can't target makers just because Sugar has synergy with them and
> because we hope they help us to spread the world tomorrow.
>

Why not?


> Our goals should be to deploy Sugar as a mainstream solution for everyone
> not a solution for a bunch of geeks. It's the only way to expand the Sugar
> community. You told about OLPC: the goal of One Laptop Per Child was to
> give a laptop to EVERY child, our goal should be to give Sugar to EVERY
> child too. The marketing effort should be in that way, no need to do
> marketing for makers, I'm sure they found us themselves.
>

I don't think there is only one path forward. And I see no reason to
abandon our GNU/Linux platform as long as we have developers willing to
maintain it and users who want to use it. Even if it is never mainstream,
it shows the way towards a great learning experience.


>
>  Lionel.
>
> P.S.: Regarding Sugarizer maintainability, it's just your opinion. Not
> sure it's the opinion for 20 others Sugarizer contributors. I don't think
> you could judge Sugarizer maintainability only because you've not
> successfully updated TurtleJS activity inside. I don't have success running
> TurtleJS on my side and had a very bad experience when trying to Sugarize
> it, it's not a reason for me to give a judgement about TurtleJS
> maintainability.
>

We can continue to disagree about this too. I think that I am not alone in
expressing the opinion that the way in which you have structured the git
repo for Sugarizer is unwieldy and that there are trivial ways to improve
it. It may be well suited for an individual maintainer (and side kick) but
it is not modeled after any community project I am aware of. As far as I
can tell, the 20 contributors built individual apps but have no easy way of
updating them. (It 

Re: [IAEP] [SLOBS] 2017 Goals for Sugar Labs

[Lionel Laské]

Hi Walter,

Thanks a lot for this long proposal. Great to hear you on that.
I think that it's more a Sugar history than a goal/vision but it's good to
read it from a guy that was the major contributor of the history.

BTW I'm not agree with your goals.
My view is that it's not a good idea to limit Sugar/SugarLabs to makers.
We can't target a so small market:
- RaspberryPI ? RPI is a great tool. I personally used 2 RPI weekly for my
personal usage. But it's a tool for geeks not for learners. It could be a
good device as server (we're using it in classroom in France and in
Madagascar and it's good for XSCE too) but it's a very poor tools for
children: no screen, no keyboard, no mouse, not even a power adapter. It's
just a board ! So I don't see the interest of Sugar on it.
- Trisquel ? Probably a nice Linux distribution but how many users ? Not at
all a largely distributed distribution like Fedora or Ubuntu.  Why doing
effort on it ?

I can't understand you even mention Windows support in your goals: just
99,9% of the PC market ! So if you're a Windows user you can't be a target
for SugarLabs ? Plus, regarding devices: we should be better on touch
devices because tablets is the favorite learning tools in classroom today,
not PC. It's why Android (80% of the tablet market) and iOS are so
important in my mind. We should go where users - children/teachers - are !

We can't target makers just because Sugar has synergy with them and because
we hope they help us to spread the world tomorrow.
Our goals should be to deploy Sugar as a mainstream solution for everyone
not a solution for a bunch of geeks. It's the only way to expand the Sugar
community. You told about OLPC: the goal of One Laptop Per Child was to
give a laptop to EVERY child, our goal should be to give Sugar to EVERY
child too. The marketing effort should be in that way, no need to do
marketing for makers, I'm sure they found us themselves.

 Lionel.

P.S.: Regarding Sugarizer maintainability, it's just your opinion. Not sure
it's the opinion for 20 others Sugarizer contributors. I don't think you
could judge Sugarizer maintainability only because you've not successfully
updated TurtleJS activity inside. I don't have success running TurtleJS on
my side and had a very bad experience when trying to Sugarize it, it's not
a reason for me to give a judgement about TurtleJS maintainability.




2017-04-09 15:31 GMT+02:00 Walter Bender :

> As per the discussion in the last Suagr Labs Oversight Board Meeting, I
> had agreed to write a draft statement of goals for 2017. The document below
> includes feedback from Samson G. I hope this document can serve to
> revitalize our discussion from 2016 that never reached resolution.
>
> Sugar Labs Plans, Goals, Aspirations
>
> What is Sugar Labs?
>
> Sugar Labs creates, distributes, and maintains learning software for
> children. Our approach to learning is grounded in Constructionism, a
> pedagogy developed by Seymour Papert and his colleagues in the 1960s and
> 70s at MIT. Papert pioneered the use of the computer by children to help
> engage them in the “construction of knowledge.” His long-time colleague
> Cynthia Solomon expanded up his ideas by introducing the concept of
> engaging children in debugging as a pathway into problem-solving. Their
> 1971 paper, “Twenty things to do with a computer”, is arguably the genesis
> of contemporary movements such as the Maker Movement and Hour of Code.
>
> At the core of Constructionism is “learning through doing.” If you want
> more learning, you want more doing. At Sugar Labs we provide tools to
> promote doing. (We focus almost exclusively on tools, not instructional
> materials.) However, we go beyond “doing” by incorporating critical dialog
> and reflection into the Sugar learning environment, through mechanisms for
> collaboration, journaling, and portfolio.
>
> Sugar Labs is a spinoff of the One Laptop per Child (OLPC) project and
> consequently it has inherited many of its goals from that project. The goal
> of OLPC is to bring the ideas of Constructionism to scale in order to reach
> more children. A particular focus is on children in the developing world.
> In order to meet that goal, Sugar, which was originally developed for OLPC,
> was by necessity a small-footprint solution that required few resources in
> terms of CPU, memory, storage, or network connectivity. The major change on
> focus from the OLPC project is that Sugar Labs strives to make the Sugar
> desktop available to multiple platforms, not just the OLPC XO hardware.
>
> Who develops Sugar?
>
> Sugar Labs is a 100% volunteer effort (although we do occasionally raise
> money for paid student internships). Sugar development and maintenance is
> incumbent upon volunteers and hence we strive to provide as much control as
> possible to our community members, including our end-users. (In fact, one
> of our assertions is that by enabling our users to participate in the

Re: [IAEP] [SLOBS] Technical Service Request - Project: Sugar Network

[Lionel Laské]

I'm agree with the idea to think to the long-term but I think we can't
leave loyal Sugar user without their tools.

So +1 to process this TSR considering we can't process other requests
without thinking to the long term support of Sugar Network.

Lionel.


2017-04-08 16:39 GMT+02:00 Laura Vargas :

> Once we solve the urgent need to neutralize Spam attacks, I would love to
> open the discussion for long-term support.
>
> Regards
>
> 2017-04-08 9:34 GMT-05:00 Walter Bender :
>
>>
>>
>> On Sat, Apr 8, 2017 at 10:32 AM, Laura Vargas 
>> wrote:
>>
>>> We have supported Sugar Network on a voluntary basis without retribution
>>> since it's deployment on 2014. Unfortunately we ran out of resources and
>>> can't afford to dedicate the required time.
>>>
>>
>> This begs the question, what is next? How will the next issue be
>> resolved? It seems a long-term solution should be discussed as opposed to a
>> one-time patch.
>>
>>>
>>> Regards
>>>
>>> Laura
>>>
>>>
>>>
>>> 2017-04-08 9:24 GMT-05:00 Walter Bender :
>>>
 This document helps clarify what work needs to be done. What is not
 clear to me is why this is work that needs to be funded as opposed to being
 done by volunteers.

 -walter

 On Sat, Apr 8, 2017 at 8:42 AM, Laura Vargas 
 wrote:

> Hello all,
>
> As per SLOB's request in yesterday's meeting, I'm attaching the Sugar
> Network urgent maintenance project proposal.
>
> I hope this documents covers all the information required by SLOB's to
> make a decision.
>
>
> Regards from the Peruvian Amazon forest,
>
> Laura
>
>
>
> 2017-04-02 23:58 GMT-05:00 Laura Vargas :
>
>> Dear Community members, Oversight Board Members and Free Software
>> Conservancy Staff,
>>
>>
>> I would like to add the following request to the upcoming April's
>> Sugar Labs Oversight Board meeting:
>>
>>
>>
>> Our dear *Sugar Network is in #urgent need of maintenance*.
>>
>> Due the the recurrent *spam attacks *we have had during previous
>> months, and due to the fact that we are serving a large group of active
>> users during the local school year, I'm hereby requesting funds to 
>> perform
>> the following technical services:
>>
>>
>> -  The addition of a "Captcha" identifier for the 3 main forms.
>> -  Clean the Spam comments
>>
>> Active users this could help: +40,000
>> Name of who is actually doing the work: Luis Sebastian Silva, Laura
>> Victoria Vargas
>> Funds required:  USD $500
>>
>>
>> I openly declare the existence of conflict of interest associated
>> with any funding request presented by me and/or my husband as long as I
>> continue serving as a Sugar Labs Oversight Board member.
>>
>> Notwithstanding the above, I understand Conservancy acknowledges that
>> many PLC (Project Leadership Committee) Persons are technical service
>> contractors and therefore it would be doable for the Sugar Labs Oversight
>> Board to approve the required funds.
>>
>> According to the Software Freedom Conservancy Conflict of Interest
>> Policy, a conflicted PLC Person must abstain from and must not hear nor
>> read the pre-vote discussions of the matter.
>>
>> Therefore* I will not vote nor participate in any pre-vote
>> discussions of this matter.*
>>
>>
>> Blessings and thanks in advance!
>>
>>
>> Attachment 1: Artwork shared at Sugar Network - English Class Prof.
>> Hilda
>> Attachment 2: Official Conflict of Interest Policy of Conservancy
>> Attachment 3: Spam Comments on Sugar Network
>>
>>
>> --
>> Laura V.
>> * I SomosAZUCAR.Org*
>>
>> “No paradox, no progress.”
>> ~ Niels Bohr
>>
>> Happy Learning!
>>
>>
>>
>
>
> --
> Laura V.
> * I SomosAZUCAR.Org*
>
> “No paradox, no progress.”
> ~ Niels Bohr
>
> Happy Learning!
>
>
> ___
> SLOBs mailing list
> sl...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/slobs
>
>


 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 

>>>
>>>
>>>
>>> --
>>> Laura V.
>>> * I SomosAZUCAR.Org*
>>>
>>> “No paradox, no progress.”
>>> ~ Niels Bohr
>>>
>>> Happy Learning!
>>>
>>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>> 
>>
>
>
>
> --
> Laura V.
> * I SomosAZUCAR.Org*
>
> “No paradox, no progress.”
> ~ Niels Bohr
>
> Happy Learning!
>
>
> ___
> SLOBs mailing list
> sl...@lists.sugarlabs.org
> 

[IAEP] 2017 Goals for Sugar Labs

[Walter Bender]

As per the discussion in the last Suagr Labs Oversight Board Meeting, I had
agreed to write a draft statement of goals for 2017. The document below
includes feedback from Samson G. I hope this document can serve to
revitalize our discussion from 2016 that never reached resolution.

Sugar Labs Plans, Goals, Aspirations

What is Sugar Labs?

Sugar Labs creates, distributes, and maintains learning software for
children. Our approach to learning is grounded in Constructionism, a
pedagogy developed by Seymour Papert and his colleagues in the 1960s and
70s at MIT. Papert pioneered the use of the computer by children to help
engage them in the “construction of knowledge.” His long-time colleague
Cynthia Solomon expanded up his ideas by introducing the concept of
engaging children in debugging as a pathway into problem-solving. Their
1971 paper, “Twenty things to do with a computer”, is arguably the genesis
of contemporary movements such as the Maker Movement and Hour of Code.

At the core of Constructionism is “learning through doing.” If you want
more learning, you want more doing. At Sugar Labs we provide tools to
promote doing. (We focus almost exclusively on tools, not instructional
materials.) However, we go beyond “doing” by incorporating critical dialog
and reflection into the Sugar learning environment, through mechanisms for
collaboration, journaling, and portfolio.

Sugar Labs is a spinoff of the One Laptop per Child (OLPC) project and
consequently it has inherited many of its goals from that project. The goal
of OLPC is to bring the ideas of Constructionism to scale in order to reach
more children. A particular focus is on children in the developing world.
In order to meet that goal, Sugar, which was originally developed for OLPC,
was by necessity a small-footprint solution that required few resources in
terms of CPU, memory, storage, or network connectivity. The major change on
focus from the OLPC project is that Sugar Labs strives to make the Sugar
desktop available to multiple platforms, not just the OLPC XO hardware.

Who develops Sugar?

Sugar Labs is a 100% volunteer effort (although we do occasionally raise
money for paid student internships). Sugar development and maintenance is
incumbent upon volunteers and hence we strive to provide as much control as
possible to our community members, including our end-users. (In fact, one
of our assertions is that by enabling our users to participate in the
development of the tools that they use will lead to deeper engagement in
their own learning.) Towards these ends, we chose the GPL as our primary
license. It has been said of the GPL that it “restricts my right [as a
developer] to restrict yours [as a user and potential developer]”, which
seems ideal for a project that wants to engage a broad and diverse set of
learners. But at Sugar Labs we go beyond the usual goals of FOSS: a license
to make changes to the code is not enough to ensure that users make
changes. We also strive to provide the means to make changes. Our success
in this goal is best reflected in the number of patches we receive from our
community. (We achieve this goal through providing access to source code
and development tools within Sugar itself. We also actively participate in
workshops and internship programs such as Google Summer of Code,
Outreaching, and Google Code-In.)

Who uses Sugar?

Ultimately, our goal is to reach learners (and educators) with powerful
tools and engage them in Constructionist learning. Currently we reach them
in many ways: the majority of our users get the Sugar desktop preinstalled
on OLPC XO hardware. We have a more modest set of users who get Sugar
packaged in Fedora, Trisquel, Debian, Ubuntu, or other GNU/Linux platforms.
Some users get Sugar on Live Media (i.e., Sugar on a Stick). Recently
Sugarizer, a repackaging of some of the core Sugar ideas for the browser,
has been finding its way to some users. There are also a number of Sugar
activities that are popular outside of the context Sugar itself, for
example, Turtle Blocks, which has wide-spread use in India. Harder to
measure is the extent to which Sugar has influenced other providers of
“educational” software. If the Sugar pedagogy is incorporated by others,
that advances our goal.

Who supports Sugar?

When we first created Sugar Labs, we envisioned “Local Labs”—hence the name
“Sugar Labs”, plural—that would provide local support in terms of
local-language support, training, curriculum development, and
customizations. This model has not ever gained the scale and depth
envisioned (we can debate the reasons why), although there are still some
active local communities (e.g., Educa Paraguay) that continue to work
closely with the broader community. There are also individual volunteers,
such as Tony Anderson and T.K. Kang, who help support individual schools in
Rwanda, Malaysia, et al. An open question is how do we support our users
over the long term?

What is next for Sugar?

We face several challenges