If you have been following my blog, you may have noticed that I see Sugar Labs as having done a lot of progress recently in the sustainability front. This has been thanks to the efforts of several individuals, who gathered around Sugar Labs in the believe that computers could radically improve the educational opportunities of children anywhere in the world, and that none of the pre-existing software environments was the best suited for the task.
It has been an awesome adventure, maybe the biggest in my life, but time has come for me to move to less thrilling matters. This doesn't mean that I'm cutting completely with Sugar, just that it will take now just a small part of my free time. I intend to skim through a couple of mailing lists, to organize bi-weekly meetings for the development team, and to review patches in the queue of my modules as time permits. I'm aiming to dedicate to all this only 5 hours per week to Sugar matters, so I will have to be very strict on where this time is spent.
I'm starting just now to look for my next job, so if you know of a position for someone knowledgeable of the GNOME platform, Python, with a good sense of FOSS communities and a taste for diving into big codebases, please do forward to me at tomeu@tomeuvizoso.net. Here is my resume.
Monday, January 25, 2010
The Karma Project: Code Less, Teach More
My last post listed some of the organizations that are putting some of their resources to work on Sugar with us. Though that list is complete to the best of my knowledge, there's another partner of Sugar Labs that is doing a great effort to work with others in improving educational opportunities around the world: OLE Nepal.
OLE Nepal is running a deployment of 4400 OLPC XOs and are working on content creation and teacher training along with laptop distribution and maintenance. They started by using Squeak Etoys as the platform for their materials, then switched to Flash because they couldn't find enough people with Squeak skills, and finally have launched the Karma project, which is based on HTML5 technologies.
They have released the 0.2 version and are now starting to port their existing content to Karma, some which you can see (and play!) here: http://karma.sugarlabs.org/.
I think this project is extremely relevant for the reasons that Bryan Berry outlines in Karma: The Code Less, Teach More Software Framework:
I don't know of any other effort that can compare to Karma in educational content authoring, so it strikes me as very bold and far-sighted that educational NGOs in developing countries are taking FOSS components and are assembling them to create frameworks that the Adobes and Microsofts of the world have failed to create. So kudos to OLE Nepal and all the volunteers involved!
OLE Nepal is running a deployment of 4400 OLPC XOs and are working on content creation and teacher training along with laptop distribution and maintenance. They started by using Squeak Etoys as the platform for their materials, then switched to Flash because they couldn't find enough people with Squeak skills, and finally have launched the Karma project, which is based on HTML5 technologies.
They have released the 0.2 version and are now starting to port their existing content to Karma, some which you can see (and play!) here: http://karma.sugarlabs.org/.
I think this project is extremely relevant for the reasons that Bryan Berry outlines in Karma: The Code Less, Teach More Software Framework:
I have written a number of articles in olpcnews.com about the need for an activity framework built on openweb technologies (JavaScript, HTML). Here is the argument in three sentences. A large proportion of software developers are familiar with these technologies. This proportion is even larger in developing countries. The larger software industry is steadily embracing openweb technologies for web, mobile, and desktop development. Please note that Karma lessons can run both online and offline.
I don't know of any other effort that can compare to Karma in educational content authoring, so it strikes me as very bold and far-sighted that educational NGOs in developing countries are taking FOSS components and are assembling them to create frameworks that the Adobes and Microsofts of the world have failed to create. So kudos to OLE Nepal and all the volunteers involved!
Friday, January 22, 2010
Sugar Labs has changed
Less than 10 months ago I wrote a post about how Sugar Labs had managed to attract top professionals to contribute their leisure time, effort and talent to our mission of improving the educational opportunities of children all around the world.
Today I'm happy to look back and see how what was a 100% volunteer-run organization has welcomed other organizations to pool their resources to keep improving Sugar. In most cases these efforts have went on quite discreetly, even if they amount to a significant share of our new developments.
The organizations that are putting their employees to work on upstream Sugar are:
OLPC has put 3 of their engineers to work on Sugar through 2009, they have sold more than 1.5 million of machines with Sugar on them, so they have some interest.
* Daniel Drake (dsd) has taken maintenance of the 0.84 stable branch, has sent several patches for fixes and has contributed one major feature: OLPC mesh support.
* Sayamindu Dasgupta (unmadindu) has kept working on everything localization, improving the book reading capabilities of Sugar and is currently working on improving font size selection in Sugar. He is also maintainer of the 0.84 stable branch along with Daniel.
* Martin Langhoff has kept working on the integration of OLPC's school server with Sugar and has also been doing great work fixing regressions in Sugar's journal and handling of usb sticks.
Paraguay Educa is a NGO that is implementing an OLPC deployment in Caacupé, Paraguay. They have distributed 4000 XOs and though being a very small organization, they have surpassed any other OLPC deployer in working with the upstream communities of the software they use.
* Raúl Gutiérrez Segalés (rgs) has been working with Walter Bender on TurtleArt, a software that introduces young learners into algorithms and computation. He is also leading the technical team and has encouraged his colleagues to be bold and join the FOSS community.
* Martin Abente (tch) has been working on adding to Sugar the capability of using 3G modems. Aside from his involvement in Sugar, he is the main author of a logistics system specially developed for the task of deploying 1-to-1 programs. This system has been made FOSS by Paraguay Educa and is being offered to other OLPC deployments.
* César D. Rodas (crodas) is not working on Sugar (yet!), but he has been assigned to make Fedora 11 run well on the XO-1 machines. This is very important for Sugar Labs, because until there isn't a new release for the XO-1, +1.5 million machines will be stuck with very old software: Sugar 0.82 and Fedora 9. This is also important because deployments start to feel empowered to take on tasks that were seen previously as too hard to be taken by anybody outside the OLPC headquarters.
The Ceibal Plan is the name of the government project that has universalized computer access in primary education, Uruguay is the first country in the world to have achieved this and I'm happy that Sugar is the chosen software for each of the 366.000 machines. They have been modifying Sugar downstream to better adapt it to their needs, and have realized that by not upstreaming their work, it will be more expensive for them to update to new versions.
* Daniel Castelo (Daniel_C) has been put in charge of upstreaming their 3G modifications on top of the work that Martin Abente is doing. He is also working on adding printer support and has been thinking of implementing ADSL connections.
* Esteban Arias (esteban) has made excellent work adding accessibility features to Sugar and is now submitting them upstream. He's starting small for our next release (0.88) but he has lots more of very interesting stuff to upstream.
Though I find these developments very reassuring, I'm still quite a bit worried about the rest of the iceberg. If an organization deploying only 4000 machines is able to work internationally to develop the software to their local needs, which opportunities are losing the deployers of the million of machines that don't dare to participate in the development process?
There's also the issue of module maintenance: all Sugar modules are currently maintained by volunteers. When OLPC took maintenance of the 0.84 branch, they actually took work out from the shoulders of those volunteers, but the rest of the contributors are actually increasing the work that maintainers have to do because of feature discussion, code reviewing, bug triaging and stabilization. If the three volunteers that are maintaining most of Sugar run out of money and need to find a normal job, who is going to do that work?
Aside from module maintenance, there's also the roles of Feature Manager, Development team coordinator, Product Manager, System Administrator, etc. that need to be carried by someone. Deployments are going to need to participate in these other areas if they want to keep having a healthy place where to work together and pool their resources.
All in all, given what 2009 brought us, I'm thrilled when I try to imagine what 2010 has in for Sugar. Have a happy hacking year!
Today I'm happy to look back and see how what was a 100% volunteer-run organization has welcomed other organizations to pool their resources to keep improving Sugar. In most cases these efforts have went on quite discreetly, even if they amount to a significant share of our new developments.
The organizations that are putting their employees to work on upstream Sugar are:
One Laptop per Child
OLPC has put 3 of their engineers to work on Sugar through 2009, they have sold more than 1.5 million of machines with Sugar on them, so they have some interest.
* Daniel Drake (dsd) has taken maintenance of the 0.84 stable branch, has sent several patches for fixes and has contributed one major feature: OLPC mesh support.
* Sayamindu Dasgupta (unmadindu) has kept working on everything localization, improving the book reading capabilities of Sugar and is currently working on improving font size selection in Sugar. He is also maintainer of the 0.84 stable branch along with Daniel.
* Martin Langhoff has kept working on the integration of OLPC's school server with Sugar and has also been doing great work fixing regressions in Sugar's journal and handling of usb sticks.
Paraguay Educa
Paraguay Educa is a NGO that is implementing an OLPC deployment in Caacupé, Paraguay. They have distributed 4000 XOs and though being a very small organization, they have surpassed any other OLPC deployer in working with the upstream communities of the software they use.
* Raúl Gutiérrez Segalés (rgs) has been working with Walter Bender on TurtleArt, a software that introduces young learners into algorithms and computation. He is also leading the technical team and has encouraged his colleagues to be bold and join the FOSS community.
* Martin Abente (tch) has been working on adding to Sugar the capability of using 3G modems. Aside from his involvement in Sugar, he is the main author of a logistics system specially developed for the task of deploying 1-to-1 programs. This system has been made FOSS by Paraguay Educa and is being offered to other OLPC deployments.
* César D. Rodas (crodas) is not working on Sugar (yet!), but he has been assigned to make Fedora 11 run well on the XO-1 machines. This is very important for Sugar Labs, because until there isn't a new release for the XO-1, +1.5 million machines will be stuck with very old software: Sugar 0.82 and Fedora 9. This is also important because deployments start to feel empowered to take on tasks that were seen previously as too hard to be taken by anybody outside the OLPC headquarters.
Plan Ceibal
The Ceibal Plan is the name of the government project that has universalized computer access in primary education, Uruguay is the first country in the world to have achieved this and I'm happy that Sugar is the chosen software for each of the 366.000 machines. They have been modifying Sugar downstream to better adapt it to their needs, and have realized that by not upstreaming their work, it will be more expensive for them to update to new versions.
* Daniel Castelo (Daniel_C) has been put in charge of upstreaming their 3G modifications on top of the work that Martin Abente is doing. He is also working on adding printer support and has been thinking of implementing ADSL connections.
* Esteban Arias (esteban) has made excellent work adding accessibility features to Sugar and is now submitting them upstream. He's starting small for our next release (0.88) but he has lots more of very interesting stuff to upstream.
Though I find these developments very reassuring, I'm still quite a bit worried about the rest of the iceberg. If an organization deploying only 4000 machines is able to work internationally to develop the software to their local needs, which opportunities are losing the deployers of the million of machines that don't dare to participate in the development process?
There's also the issue of module maintenance: all Sugar modules are currently maintained by volunteers. When OLPC took maintenance of the 0.84 branch, they actually took work out from the shoulders of those volunteers, but the rest of the contributors are actually increasing the work that maintainers have to do because of feature discussion, code reviewing, bug triaging and stabilization. If the three volunteers that are maintaining most of Sugar run out of money and need to find a normal job, who is going to do that work?
Aside from module maintenance, there's also the roles of Feature Manager, Development team coordinator, Product Manager, System Administrator, etc. that need to be carried by someone. Deployments are going to need to participate in these other areas if they want to keep having a healthy place where to work together and pool their resources.
All in all, given what 2009 brought us, I'm thrilled when I try to imagine what 2010 has in for Sugar. Have a happy hacking year!
Saturday, January 16, 2010
A week at LATU (part III): More about developing with Sugar
Daniel Castelo kindly pointed out some important subjects that were discussed in my visit to Montevideo but I had forgot to mention in the last post.
Sugar Labs is providing a site where activity authors can post their activity bundles and Sugar users can search, download, rate, etc. This site is based on Mozilla's AMO which powers addons.mozilla.org, some more details in this older post. The colleagues at LATU asked about deploying their own instance, so they could better tailor what is offered on it to Uruguay's specific needs. I think that right now this is not a good idea because AMO allows us to display activities based on the Sugar version of the client and we can quite easily explain in the description or a comment if an activity makes most sense for a particular deployment. Also, AMO allows users to create collections of activities, so we could see collections specifically prepared for Uruguay classrooms.
We also dedicated quite a bit of time discussing the upstreaming of some features that the LATU has developed in-house, but I think this is more relevant for the community side of things so I leave it for the last post of this series.
Perhaps the most serious single issue I heard when asking for feedback there was that the XOs got sometimes in such a state that a full image reflash was needed. This means that any work that hadn't been backed up would be lost, which is quite bad if we consider that many kids won't have enough discipline (or media) to backup all their relevant work. I have been told that the first suspect cause is the internal flash filling up to a point where the machine doesn't boot any more.
Some ways of attenuating the problem are: making it easier to delete unneeded stuff from the journal by implementing selection of multiple entries, update to a version that doesn't leak temporary files, deploy school servers capable of accepting backups from the XOs and add a simple way to backup the journal to a pen drive.
The next and last post will be about what we discussed about how an organization like LATU can interact with FOSS communities to their best profit.
Sugar Labs is providing a site where activity authors can post their activity bundles and Sugar users can search, download, rate, etc. This site is based on Mozilla's AMO which powers addons.mozilla.org, some more details in this older post. The colleagues at LATU asked about deploying their own instance, so they could better tailor what is offered on it to Uruguay's specific needs. I think that right now this is not a good idea because AMO allows us to display activities based on the Sugar version of the client and we can quite easily explain in the description or a comment if an activity makes most sense for a particular deployment. Also, AMO allows users to create collections of activities, so we could see collections specifically prepared for Uruguay classrooms.
We also dedicated quite a bit of time discussing the upstreaming of some features that the LATU has developed in-house, but I think this is more relevant for the community side of things so I leave it for the last post of this series.
Perhaps the most serious single issue I heard when asking for feedback there was that the XOs got sometimes in such a state that a full image reflash was needed. This means that any work that hadn't been backed up would be lost, which is quite bad if we consider that many kids won't have enough discipline (or media) to backup all their relevant work. I have been told that the first suspect cause is the internal flash filling up to a point where the machine doesn't boot any more.
Some ways of attenuating the problem are: making it easier to delete unneeded stuff from the journal by implementing selection of multiple entries, update to a version that doesn't leak temporary files, deploy school servers capable of accepting backups from the XOs and add a simple way to backup the journal to a pen drive.
The next and last post will be about what we discussed about how an organization like LATU can interact with FOSS communities to their best profit.
Friday, January 15, 2010
Producing Open Source Software by Karl Fogel
Finally finished reading Producing Open Source Software from cover to cover. I found it very well written and full of stuff relevant to any FOSS contributor. I was surprised as I read how about 90% of the content matched what I had learnt by practice during the last 3 years. I'm very grateful to Marco Pesenti Gritti who passed all this knowledge to the Sugar team.
Anybody has had any experience giving this book for reading to people who still had no knowledge of FOSS?
Anybody has had any experience giving this book for reading to people who still had no knowledge of FOSS?
Wednesday, December 30, 2009
A week at LATU (part II): Developing with Sugar
This is the second part of a series of articles about the week I passed earlier this month at Montevideo, working with the Ceibal Plan. See here for the introduction. This post is about the technical issues that were discussed, a subsequent one will go briefly over the management and community issues.
The first hours were dedicated to a quite complete walkthrough of all Sugar dependencies, modules and python packages. Daniel Castelo displayed interest in contributing short descriptions of each package for the API docs, will be great if he finds some time to do so.
The next subject we discussed were techniques for easily developing in a regular Linux distro and then testing on the XO. Though since the start of the project we have desired to develop Sugar on Sugar itself, there's still some work to do so you can run a stable instance isolated from the recent changes and a second one running inside it. So the idea is to develop in a machine running for example GNOME and run a Sugar instance inside Xephyr, with its own D-Bus session bus and all. Once you are happy with how it runs there, you can test easily on a XO (or any other target machine) by mounting with sshfs the dirs that contain installed Sugar code onto the dirs with old code. And voilà, an XO running the last unstable Sugar code.
Another area in which developers new to python have generally doubts is with debugging. In languages with a slow compilation process and with direct access to memory, using a debugger such as gdb is often the best first resort, specially if one masters the debugger being used. But in Python, given that between adding a logging statement and running it is such a short lapse, this is generally preferred over a full-fledged debugger. If you already know the code being debugged, you may be already suspecting of some assumption that is not correct, and often with just one more logging statement you can reach the cause. For cases when a debugger is needed pdb is a good equivalent to gdb. If you prefer a graphical debugger, winpdb works well and also allows you to attach to a running process.
Another subject discussed was localization, in order for their work be accepted by upstream, it needs to be fully localizable. We didn't got into details here because it's well explained in the Sugar Almanac, it contains a lot of practical information for activity authors and also shell hackers. Thanks to OLPC for funding the initial work on the Almanac and also to Faisal Anwar and Media Modifications for keeping contributing pro bono.
An issue that was raised several times was a way for Sugar code to execute privileged actions without relying on sudo, as Ceibal's anti-theft scheme relies currently on users not knowing the root password. They plan to remove this limitation soon, but anyway a better way is PolicyKit.
Another important subject was content distribution, they have been bundling books inside a "Library" activity that contains code copied from Browse. Though this is the approach that I like the most in recent releases of Sugar, for their machines running 0.82 I recommended to look at content bundles.
Then they showed the work they have been doing together with Paraguay Educa in adding to Sugar the possibility to connect to 3G networks, using NetworkManager for that (thanks to Dan Williams for his support). Its upstreaming is going smooth thanks to Martin Abente's hard work and the people at LATU are already thinking about extending it for ADSL connections. Kudos as well to Andrés Ambrois for providing a patch for selecting graphically your provider and data plan. This feature is a great example of contributions bringing more contributions, making more worthwhile doing the jump and start working with upstream.
Sugar has survived surprisingly long without printing support. Even if the people actually using Sugar say that they won't actually print much because of logistic issues, this has been mentioned often as the big missing feature in Sugar. In Uruguay the need is mainly for parents whose children bring their XOs home and they have a printer there. Thanks to all the Linux and GNOME infrastructure we leverage, implementing printing support will be much easier than resisting further, so LATU's Daniel Castelo is proposing a way going forward in this issue.
Another subject was sugarizing C applications. This means that the code and resources are all contained in a bundle along with some metadata, the main window would be maximized and have a couple of X properties so the Shell can recognize and track them, and that it implements collaboration with Telepathy and stores its state in the Journal, through D-Bus.
One last subject was discussing how through the extensions mechanism in Sugar they can develop new features without the release cycles causing them to do costly rebases each time.
The first hours were dedicated to a quite complete walkthrough of all Sugar dependencies, modules and python packages. Daniel Castelo displayed interest in contributing short descriptions of each package for the API docs, will be great if he finds some time to do so.
LATU's R&D team with Martin Abente and me, photo courtesy of Martin Abente
The next subject we discussed were techniques for easily developing in a regular Linux distro and then testing on the XO. Though since the start of the project we have desired to develop Sugar on Sugar itself, there's still some work to do so you can run a stable instance isolated from the recent changes and a second one running inside it. So the idea is to develop in a machine running for example GNOME and run a Sugar instance inside Xephyr, with its own D-Bus session bus and all. Once you are happy with how it runs there, you can test easily on a XO (or any other target machine) by mounting with sshfs the dirs that contain installed Sugar code onto the dirs with old code. And voilà, an XO running the last unstable Sugar code.
Another area in which developers new to python have generally doubts is with debugging. In languages with a slow compilation process and with direct access to memory, using a debugger such as gdb is often the best first resort, specially if one masters the debugger being used. But in Python, given that between adding a logging statement and running it is such a short lapse, this is generally preferred over a full-fledged debugger. If you already know the code being debugged, you may be already suspecting of some assumption that is not correct, and often with just one more logging statement you can reach the cause. For cases when a debugger is needed pdb is a good equivalent to gdb. If you prefer a graphical debugger, winpdb works well and also allows you to attach to a running process.
Another subject discussed was localization, in order for their work be accepted by upstream, it needs to be fully localizable. We didn't got into details here because it's well explained in the Sugar Almanac, it contains a lot of practical information for activity authors and also shell hackers. Thanks to OLPC for funding the initial work on the Almanac and also to Faisal Anwar and Media Modifications for keeping contributing pro bono.
An issue that was raised several times was a way for Sugar code to execute privileged actions without relying on sudo, as Ceibal's anti-theft scheme relies currently on users not knowing the root password. They plan to remove this limitation soon, but anyway a better way is PolicyKit.
Another important subject was content distribution, they have been bundling books inside a "Library" activity that contains code copied from Browse. Though this is the approach that I like the most in recent releases of Sugar, for their machines running 0.82 I recommended to look at content bundles.
Then they showed the work they have been doing together with Paraguay Educa in adding to Sugar the possibility to connect to 3G networks, using NetworkManager for that (thanks to Dan Williams for his support). Its upstreaming is going smooth thanks to Martin Abente's hard work and the people at LATU are already thinking about extending it for ADSL connections. Kudos as well to Andrés Ambrois for providing a patch for selecting graphically your provider and data plan. This feature is a great example of contributions bringing more contributions, making more worthwhile doing the jump and start working with upstream.
Sugar has survived surprisingly long without printing support. Even if the people actually using Sugar say that they won't actually print much because of logistic issues, this has been mentioned often as the big missing feature in Sugar. In Uruguay the need is mainly for parents whose children bring their XOs home and they have a printer there. Thanks to all the Linux and GNOME infrastructure we leverage, implementing printing support will be much easier than resisting further, so LATU's Daniel Castelo is proposing a way going forward in this issue.
Another subject was sugarizing C applications. This means that the code and resources are all contained in a bundle along with some metadata, the main window would be maximized and have a couple of X properties so the Shell can recognize and track them, and that it implements collaboration with Telepathy and stores its state in the Journal, through D-Bus.
One last subject was discussing how through the extensions mechanism in Sugar they can develop new features without the release cycles causing them to do costly rebases each time.
Saturday, December 19, 2009
A week at LATU (part I)
LATU stands by Laboratorio Tecnológico del Uruguay and is in charge of the technical aspects of the Plan Ceibal, as well as the overall coordination of the project. As part of their responsibility in making the software deployed on the OLPC machines as useful as possible in their context, they are spending considerable resources in the development and support of Sugar.
Because they were until recently on the initial phase of the project, they have carried that work on their own, without participating in the community nor working together with other deployers of Sugar. Now that every child in public primary schools in Uruguay owns a XO laptop, they are starting to think about optimizing their Sugar work by pooling resources with others and coordinating with upstream's schedules. The LATU also has a big interest in that their work benefits other countries using Sugar, as part of Uruguay's participation in international cooperation. I have the hope that most of what they learn when working with Sugar Labs will help them take the most of other free software projects they use, such as GNOME (chances are the laptops that will be given to high schoolers in the next years will be running that).
The concrete issue they found when developing on their own was that every time that their upstream (OLPC) produced a new image build, in order to benefit from the improvements in that release they had to apply the customizations made locally, solve any conflicts and retest everything. If they had contributed those modifications to Sugar, OLPC images would have come with them and no further work would be needed. Reaching the point in which they can directly use the OLPC images as-is is still a bit far away, but every bit that they integrate upstream is a step in the right direction and reduces their development and support costs. Also, when their employees work within the communities that maintain their software, they work directly with the most qualified engineers in those technologies, increasing local capacity.
Through Walter's mediation, Miguel Brechner contacted me a few weeks ago proposing visiting them in Uruguay to explore ways for integrating their processes with those in Sugar Labs and other free software projects they use such as OLPC. I was lucky enough to be able to take the chance to also attend Ceibal '09, a wonderful event about which I blogged here.
Another happy circumstance is that the LATU took the initiative of inviting Paraguay Educa, the deployers of OLPC and Sugar in Paraguay, to send one of their engineers to Montevideo in order to participate on the sessions. It was a big pleasure meeting Martin Abente (tch in #sugar), who wrote about his trip (in Spanish) here and hope I can meet in person the rest of his team soon.
This is the first time since a year ago that I have been paid for working on Sugar, so I have high hopes in that we are going to find soon business models that will sustain further development of Sugar. Would be a sad situation if upstream development of Sugar had to halt because the core developers had to end their involvement in order to fulfill their real-life responsibilities. If that happened, deployers of Sugar (responsible for more than a million installations) wouldn't have a place where to pool resources and coordinate their work.
I'm going to blog two more parts about the week I spent there, one focusing on the technical aspects and the other will be about the management and community side of things.
Because they were until recently on the initial phase of the project, they have carried that work on their own, without participating in the community nor working together with other deployers of Sugar. Now that every child in public primary schools in Uruguay owns a XO laptop, they are starting to think about optimizing their Sugar work by pooling resources with others and coordinating with upstream's schedules. The LATU also has a big interest in that their work benefits other countries using Sugar, as part of Uruguay's participation in international cooperation. I have the hope that most of what they learn when working with Sugar Labs will help them take the most of other free software projects they use, such as GNOME (chances are the laptops that will be given to high schoolers in the next years will be running that).
The concrete issue they found when developing on their own was that every time that their upstream (OLPC) produced a new image build, in order to benefit from the improvements in that release they had to apply the customizations made locally, solve any conflicts and retest everything. If they had contributed those modifications to Sugar, OLPC images would have come with them and no further work would be needed. Reaching the point in which they can directly use the OLPC images as-is is still a bit far away, but every bit that they integrate upstream is a step in the right direction and reduces their development and support costs. Also, when their employees work within the communities that maintain their software, they work directly with the most qualified engineers in those technologies, increasing local capacity.
Through Walter's mediation, Miguel Brechner contacted me a few weeks ago proposing visiting them in Uruguay to explore ways for integrating their processes with those in Sugar Labs and other free software projects they use such as OLPC. I was lucky enough to be able to take the chance to also attend Ceibal '09, a wonderful event about which I blogged here.
Another happy circumstance is that the LATU took the initiative of inviting Paraguay Educa, the deployers of OLPC and Sugar in Paraguay, to send one of their engineers to Montevideo in order to participate on the sessions. It was a big pleasure meeting Martin Abente (tch in #sugar), who wrote about his trip (in Spanish) here and hope I can meet in person the rest of his team soon.
This is the first time since a year ago that I have been paid for working on Sugar, so I have high hopes in that we are going to find soon business models that will sustain further development of Sugar. Would be a sad situation if upstream development of Sugar had to halt because the core developers had to end their involvement in order to fulfill their real-life responsibilities. If that happened, deployers of Sugar (responsible for more than a million installations) wouldn't have a place where to pool resources and coordinate their work.
I'm going to blog two more parts about the week I spent there, one focusing on the technical aspects and the other will be about the management and community side of things.
Subscribe to:
Posts (Atom)