[IAEP] Sugar Digest 2013-02-04

Walter Bender walter.bender at gmail.com
Mon Feb 4 11:51:42 EST 2013


Kim Toufectis commented on my post [1] about online services:

:Appreciative of the ideals upon which SugarLabs and OLPC formed, it’s
deeply troubling to envision a commercial entity like FaceBook
integrated into the Control Panel.

:For a system in which a proprietary browser (Opera) or plugin (Adobe
Flash) are controversial even as optional add-ons, can we really be
headed for integrating a private corporation into the heart of the
OS?This is very difficult to understand…

My response:

First, I will dodge the issue. The web-services intervention into the
Sugar code base is not specific to any service provider, rather it is
designed as a plug-in architecture. It is not too much of an
exaggeration to say it is little more than the addition of four lines
of code that add new destinations to the “Copy to” button in the
Journal menu:

+       from jarabe.web import online_accounts_manager as oam
+       for account in oam.OnlineAccountsManager.configured_accounts():
+            menu = account.get_share_menu(metadata)
+            self.append(menu)

Raul and I added a new module to Sugar extensions that provides a
general framework for managing and accessing online accounts, in a way
that is service-provider agnostic, the online accounts manager
imported from jarabe.web.

We are also working on a patch to the Journal detail view that will
display comments made to shared entries. This is a generalization of a
mechanism I built for the Sugar Portfolio activity, which displays
comments made on Journal entries when your portfolio is shared using
the existing Sugar collaboration framework.

Regarding the Facebook icon on the control panel shown in the sketch I
posted, this is misleading. This is just a place holder. As I
mentioned in my blog, we are working on a panel that can be used to
manage all of a user’s online accounts, in a manner similar to GOA.
(We may just use GOA with a Sugar wrapper, depending upon what
dependencies it introduces.)

So far, I think it is fair to say we are not “integrating a private
corporation into the heart of the OS”.

End of dodge.

There are several issues raised by our proposal (none of this code has
yet been reviewed and accepted):

(a) Should Sugar facilitate integration with online services?
(b) If so, should we do it in such a way that is service-provider agnostic?
(c) Why specifically are we working on a Facebook plugin?

In regard to the first question, one could argue that the Sugar
collaboration framework is capable of internalizing whatever services
a user may want, and hence there is no reason to open the door to
external services. Further, one could argue that the Sugar Browse
activity provides sufficient access to online services that there is
no need to provide any additional interfaces.

Personally, I don’t think it is realistic or pragmatic to try to
contain our users or to replicate every service that might be of
interest within our own framework. We don’t have the resources to do
that, but even if we did, such an approach is not, in my opinion,
aligned with the goals of the project. I want children to use Sugar as
a “free as in freedom” and safe place to learn, however, I don’t want
to confine them to that space: they should be launched out of Sugar
into the broader world of computing and the web, hopefully shaped by
their experiences with Constructionism and with free software. Indeed,
one of the most rewarding experiences of the project is to watch
children who grew up with Sugar submitting patches to reshape it into
a something new and better. Just as we provide a mechanism to
inter-operate between Sugar (an environment for exploration) and the
GNOME desktop (an environment for productivity), I envision children
learning to move fluidly between the garden of internal web services
provided by our collaboration model and external services.

As far as being agnostic as to which services our framework *can*
support, I think that from the technical perspective, this is a
requirement. We cannot be in the business of censoring on behalf of
our users. We leave decisions as to what to learn up to the local
communities in which Sugar is deployed. Where we have a deliberate
influence is on how it is learned. We try to strike a much-needed
balance between consuming and creating, between critiquing and
reflecting, and this is reflected in the affordances we provide: the
Journal, view source, sharing, etc.

That said, we all make decisions of commission and omission. For
example, on the one hand, I filled a ticket with Youtube regarding
enabling the uploading of .ogv files. On the other hand, when I post
videos, I use Dailymotion, because it supports .ogv. And yet I admit
to still watching the occasional Youtube video. And as you alluded to
in your question: we shipped Gnash instead of Adobe Flash.

Regarding social networking, I blogged this past spring about how the
teachers using Sugar in Amazonas Peru hang out on Facebook [2].
Consequently, when we set up a common space for collaboration and
support for those teachers, we set it up on Facebook [3]. I’ve tried
to get teachers to come to the Sugar channel on IRC, but few, if any,
ever do so. (The default channel of the IRC client we bundle into
Sugar takes them to #sugar on irc.freenode.net, but they never use
that tool. They do manage to find Facebook on their own using Browse.)
If I want to engage with them, I need to go to where they hang out.
The engagement itself, independent of the service used to provide it,
has been rewarding.

As to why Facebook as the place to start building services, there are
several reasons. The first is simply that Raul wrote facebook-gobject,
which he hosted on git-hub [4], that allows you access Facebook’s
Graph API via a set of GObject based objects for easy integration with
GLib2-based code. The second is that Facebook has 1-billion users with
whom we’d like to interact and impact.

There are certainly caveats: First, Facebook is not for children. My
intention is to provide a mechanism for teachers, not children.
Second, Facebook does not provide a place for file (project) sharing,
just a place for talking about projects. We will need other services
for that (dare I say, Google Drive). Third, there may well be other
social networking sites that are aligned with the principles of Free
Software. Help us identify those sites and write plugins for them.
Which services are exposed in a control panel extension is not a
decision we will make unilaterally, but in order to offer a service,
someone needs to write the code. Raul and I are trying to lower the
barrier to entry. Admittedly, by lowering the barrier for Facebook, we
may be discouraging others from trying to compete in this space.

We have an obligation to take these issues seriously and to discuss
them vigorously. They are not decisions that come easily or lightly.
How we open the door to web services within Sugar is still to be
decided.

-walter

[1] http://walterbender.org/?p=641
[2] http://walterbender.org/?p=571
[3] https://www.facebook.com/groups/370964266297045/
[4] https://github.com/rgs1/facebook-gobject

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


More information about the IAEP mailing list