[Sugar-devel] Deployment feedback braindump

[Tomeu Vizoso]

On Mon, Aug 10, 2009 at 18:53, Daniel Drake<dsd at laptop.org> wrote:
> Hi Tomeu,
>
> 2009/8/10 Tomeu Vizoso <tomeu at sugarlabs.org>:
>> Hi,
>>
>> some thoughts follow. Please keep in mind that these are just my
>> personal opinions and that not everybody at Sugar Labs share the same
>> idea of what SLs is or should be.
>
> Thanks for the response.
>
>
> What you are saying makes sense -- it is indeed a nice idea to keep
> SugarLabs as more of a loose structure, as a place for collaboration
> on anything that might further the general mission.
>
> It is a sensible idea to keep SugarLabs away from doing too much work
> on the OS building and deployment implementing side of things, because
> as you point out, even when you exclude those broad topics there is
> still a lack of resources on the bits that remain.

There's also the benefits of having a clear upstream/downstream
separation. Having the same people working on both aspects without
clear processes gets very messy at medium term.

> That said, in a way, the "gap" that we're discussing is in some ways
> more important than any of the Sugar features currently being worked
> on, because the large majority of sugar users are currently a long way
> away from even having access to the features that were finished 6
> months ago. Difficult.

Agreed, though if we stop making new releases, other people might get
the message that Sugar is dead thus not worth of deploying, packaging,
etc. But I'm ok with slowing deployment of new features for now and
focusing on bugfixing, polishing, etc

> I disagree about local labs being key to filling the gap. While a nice
> idea, I think it is necessary for there to be a central and
> location-independent deployment-focused upstream, otherwise there will
> be a lack of coordination accompanied by lots of duplication of work.
> Local labs need to feed into something bigger, which doesn't currently
> exist, although it could probably sit under the realm of sugarlabs if
> the right people were to step up.

Well, such work would be certainly welcome to happen inside Sugar
Labs, even if carried by other organizations, local labs or not. I
would like to clarify that the term local lab might be misleading
here. There's nothing wrong in Solutions Grove being a local labs and
also becoming the global services provider of SoaS, for example.

Though I think it would be more likely that we would see a local lab
working in several countries in latin america, other giving services
in South East Asia, etc. similar to how companies divide the global
market. There are good reasons for that.

> Also, when talking of scale, I am a little wary of local community
> efforts because they have previously proven disruptive to deployments.
> The sad reality is that you absolutely require more of a NGO or
> business setup to be working with the relevant authorities. And when
> this happens, the community efforts automatically become a bit
> distanced. For example in many of these places, the "official"
> organisation receives permission from the government for their staff
> to enter government schools - but only their staff (not community
> volunteers).

Local labs don't need to be all community efforts, can be companies,
governmental organizations, etc. Whatever works best for them. With
such a broad mission, we won't be able to find a single organizational
structure that works everywhere.

> You mention lack of involvement and feedback from deployments -- why
> do you think this is?
> Here are some of my thoughts:
> - The majority people we're working with are alien to the idea that
> they might be able to talk to the people who are writing the software
> that they are using. Since when has anyone been able to do that? Us
> open source people are still the oddities in the world.
> - People are afraid or mythed by the idea of this stuff being public
> and global ("why would I want my feedback to be public?"), and are
> confused/challenged by mailing lists.
> - The people most able to give the kind of feedback you are looking
> for are the teachers, who are probably even more distanced from these
> ideas. Many will lack connectivity and english language skills.
> - Many people who support the project with technical skills (e.g.
> Linux) come from purely academic backgrounds which means they
> understand the technical stuff well, but have little interest,
> experience (and sometimes ability) to become good community members.

That matches pretty well my observations. We have a disruptive message
to pass regarding community participation, which is pretty much the
same problem that Fedora or any other global open source project
faces. Local entities (ambassadors, user groups, local labs?) play a
very big role there because it's very hard for me from Prague to
explain to someone in the Andes how we can work together. But if that
person goes to an event organized by her local university and
establishes personal relationships with other people working with
Sugar in her community, that's a very good first step towards
cooperation in the global stage.

> To put it plainly: in my opinion, wishing for substantially more
> involvement from deployments is not realistic. SugarLabs would benefit
> from being proactive here, especially by using the telephone rather
> than email to contact deployments, but this is of course subject to
> the "where are the resources?" question. Hopefully over time a
> proactive approach from our side would likewise encourage a proactive
> approach to communication from the deployments, but I suspect we'll
> have to be patient. and yes, this makes your job pretty difficult.

It sure is very hard for me to get myself in direct contact with a
teacher in Nepal, but we don't strictly need for everybody to directly
work with everybody else. Big successful movements will organize
themselves in such a way that every person will relate to those other
members with whom can best work together.

Teachers in, say, Peru don't even need to know that Sugar Labs exist
to benefit from our work, but if Sugar Labs is the only trans-national
place where Sugar work happens, then someone in their country needs to
be part of Sugar Labs if they want their work to have the greatest
impact in their country.

>> On Sun, Aug 9, 2009 at 19:41, Daniel Drake<dsd at laptop.org> wrote:
>>> At least from what I have seen, this kind of clarity seems to be
>>> missing from discussions that define the Sugar platform nowadays, as
>>> well as in the code that is flowing through the system. Does SugarLabs
>>> still have a high degree of interest in bigger-than-you-can-believe
>>> deployments in remote and really difficult parts of the world on
>>> low-spec hardware, or are we moving towards looking at occasional
>>> 30-student deployments on powerful computers in schools along the
>>> Charles? Or are we trying to do both?
>>> Are we still focusing on 6-12 year olds or has that changed?
>>
>> How do you expect that the SLs volunteers know what OLPC deployments
>> need if they don't voice their needs? If you look at the Sugar commit
>> logs, you will see that almost all commits are from someone sitting in
>> a room somewhere in Europe, working on their free time. By which kind
>> of epiphany do you expect them to know what's best for OLPC
>> deployments?
>
> I think you misunderstood my position here. I am personally having
> trouble trying to formulate this kind of feedback because I no longer
> know what is important to Sugar. Maybe it is a personal
> misunderstanding, but after seeing some recent discussions and
> features I feel that some of the core goals that formed the project in
> its earlier stages have been lost. I am glad to see your response
> which suggests that these things are still important to you at least,
> so this will help me gather my thoughts.

I see, one of the things I would like to see us getting from this
thread is to understand better the nature of the resources we have
today. Though volunteer open source hackers are notorious by enjoying
tackling hard problems that may be of little practical use to people,
I think our case is special because we can have a very big impact of
the lives of others through our work. But same as with involving more
people, we need to transmit the right message in the right way.

>> That's an interesting statement, do you think we are grossly
>> overestimating the capacity of our users?
>
> In many cases, yes. We are also missing various opportunities to
> automate things which would really make basic system usage much
> smoother in a classroom. At the same time, most of my experience has
> been in classes within the first month of usage, so I'm not too sure
> how their skills develop.  But really the classroom use of these is
> often limited by the teacher who usually does not pick up things so
> fast.

Agreed, we cannot expect Sugar to be used in a single way, so we need
it to have some degree of configurability and let it be flexible
enough so it works well for different user profiles. There's also the
balance between usability and discoverability.

>> You mean that you cannot open that library bundle by clicking on its
>> journal entry?
>
> Correct me if I'm wrong, but none of the methods that could be used by
> deployments to distribute materials this way in mass would result in a
> journal entry appearing for their users. These methods are installing
> through a package into /usr/whatever/library or unzipping into
> ~/Library.

Didn't thought about pushed updates, can they execute post-install
scripts? If so, they could use copy-to-journal.

>>> So I guess my wishlist from this email would be these items:
>>>  1. for SugarLabs' aims to become as clear as OLPC's 5 principles
>>
>> Why is the current mission statement not clear?
>>
>> http://wiki.sugarlabs.org/go/Sugar_Labs
>
> Because it's a mission statement. It's fluffy by design. It doesn't
> answer basic questions like what kind of computers are being targeted,
> which classroom environments  (if classrooms at all?), which learning
> models, target ages of children, if the focus is on code or content,
> if good infrastructure is important, how or if it is different from
> the other efforts of ICT for education, etc.

Well, if Sugar Labs becomes a deployer of machines for learning, then
it would make sense to have such stuff. But then we would be trying to
replace OLPC.

OLPC is/was formed by very smart people with lots of funding. We are
probably less smart and have almost no funding at all. What makes us
think we can succeed in taking over OLPC's role?

I think Sugar Labs should instead try to fulfill a role that no
deployer can take, but they need in order to succeed in their
missions. Same as Fedora and Ubuntu need the GNOME and the Apache
Foundation to succeed in their mission.

Thanks,

Tomeu

> Daniel
>