ep

Sugar Digest

Kim Toufectis commented on my post 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. Consequently, when we set up a common space for collaboration and support for those teachers, we set it up on Facebook. 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, 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.

Your email is never published nor shared. Required fields are marked *