ReciclaRed, a software libre edu project in the Canary Islands

ReciclaRed finished last December. During a whole year 20 students have been working hard to install and configure 14 computer labs in some public schools placed in Las Palmas de Gran Canaria. Canary Islands, Spain, as part of a project financed with EU funds through the Canary Islands Employment Department of the Regional Government.

This project was assigned to FUNDESCAN, a well known local foundation. Grupo CPD, the company I work for, was the technological partner. For ReciclaRed, a director, some teachers and one administrative were employed.

Beside cabling and building up the network of every computer lab, the students recycled hundreds of computers donated by public administrations and private companies and configured them as thin clients, using software libre to do so.

Students also learned to install and configured distros like Debian, Kubuntu or CentOS. All thin client systems had KDE as the default desktop with KOffice and KDE-Edu apps installed, among others. Software like LTSP, XEN, Mediawiki, Joomla, Firefox, OpenOffice, etc were also used.

This project wouldn’t be possible with propietary software and it has been a clear success story with local media coverage (check this article in spanish). Some wiki pages written by the students and teachers has been already published. The rest will be public soon (with free license).

We have linux on schools, so now what?

Teachers usually prepare their classes at home, so they need the same software there that it is installed at the school they work in, with the same version of any app. As they do with books, teachers need to make agreements on the software they install in computer labs. This is not just a pedagogical, but a technical and a management need. This is the first problem the have to face.

In Spain, due to political reasons, regional governments are in charge of the technical issues that deals with computers involved in education. So they select most (or all) of the apps you find in a computer lab of any public school. This is one of the reasons we have been so successful in promoting free software at schools. It is a political decision and teachers support it (although it takes time). But other countries do not have global solutions for this, since each school or teacher have independence for choosing the applications to work with at school. This is not an advantage from a managing or a supporting point of view (it doesn’t have to be a disadvantage either if there is a good coordination).

Let’s assume that this problem is solved.

Supporting the software and creating documentation around a single app is hard to do and takes time. To teach teachers and students to use the software chosen takes a while too, so it is impossible for edu projects to follow short release periods, as software libre distributions do. They soon get out of date, unsupported. So teachers and students end up having at home newer versions of the software they have at school. This is already a problem for those teachers that already have good skills using linux.

In addition, each distro have its own politic related with repositories and versions of packets they include and support in any release. Even if a single (or group) of schools follow it, still there is a problem with what people have at home.

One of the things that should be done by schools or regional govs. in order to reduce the impact of this problem is to create and maintain their own repository of packets to ensure they all use the same version of the same app they have at school. This is a good point for students also.

In my opinion, this repository should be distro independent, so teachers (or students) can install the distro they want (from the official distro repository, or from a installation CD), and add this edu repository, so they have the same version of any app. This can also include Windows versions of edu apps. This doesn’t work at 100% but there are technical ways of getting close.

This is a better approach than preparing a complete edu distro and having to support the installation process, hardware drivers, desktop configs, etc.. Distros already take care of that and they do it well because they have the experience.

What makes the difference if you use KDE, and I think the best thing this can be done, is to be able to download and install from the edu repository the profile (configured with kiosk mode) you have in school (if you use KDE), with all the apps, so teachers have the same configs and apps in a semi-independent desktop.

By doing this, what people in charge of edu projects can do, is to put more effort on spreading their experience selecting and configuring the desktop (improving usability), on promoting a community around the software they install and on connecting that community directly with distro, desktop and apps communities, instead of putting so much effort on technical stuff related with live CD installation, hardware configurations, release periods etc. in uncontrolled environments. To deploy, update and maintain the software on computer labs and other dependencies in schools (controlled environments) is already a huge project that takes many resources.

This is not the politic big edu projects are following in general. They are promoting that people at home install the same complete distro they have at school, adding an unsustainable and non scalable effort to the technical people they have. That politic have to change if we want to give response to the increasing demand we gonna face during the following years. Specially, if computer stores begin to sell machines with linux preinstalled, so regular users won’t have to install that whatever linux operative system they (or the store) choose anymore (probably different than the one they have at schools).

Are we trying to beat one monopoly by supporting another one?

Lately news about the support Mozilla is receiving from Google has made me think…

Firefox is a great tool, specially is you use Windows. With Linux or Mac/OS you have more good choices.

I promote firefox everywhere I go, specially in courses where I teach. Most of the computer labs I teach in have Windows XP, so one of my objetives when I teach beginners is to break the Windows+MSN Messenger+Hotmail+Windows Live+MSNSearch association that most of them love (because it is the only thing they know).The combination Windows+Firefox+Google+Goolge talk+Gmail+Blogger is a natural option but…

Am I fighting against a monopoly by supporting another one?

I’ve decided I’m going to change some of the exercises and introduce more tools to avoid this situation I’m worry about.

Firstable I’ll use Yahoo again, like in the early days, once in a while, so students get confortable with it as well as with Google. Almost nobody uses Yahoo in Spain. I’ll also use Opera, not just Firefox, until I find another browser libre (kde browser for windows?) that I like. I’ll try to use pidgin or PSI as a IM client (kopete for windows?) and, by now, I’m not going to promote any webmail but Gmail or any blog tool but Blogger. I’ll think about it anyway.

By doing this, I hope my student get more open to try different tools and I calm my worries about what it looks like it can happen in the near future.

If you have any suggestion, I’m open to read and consider it. Maybe switch to linux + KDE….right?

KOffice in schools

Following disccussion taken place at Edu-day in aKademy 2007, here is a more precisely opinion than I expressed there:

Right now a big fight is taking place in market between MS Office and OpenOffice. The appearance of the free software suite and ODF has brought a new interest to a sector long time dominated by the old man. But there are, at least, two more choices:

* KOffice, from the KDE desktop

* GNOME Office suite with gnumeric and Abiword in front.

Both free software products, specially designed for linux desktop, are really mature solutions but, for whatever reason, do not have a good market position.

KOffice is a great suite. It’s applications are well integrated and the guys that are working on it are good developers with great ideas. That’s what it has moved me to write this, to try to help them to get the attention that other office suites have. KOffice is another example of a good product not having its way because market decisions, that is, users or customers decisions.

What do they have to do in order to attract more attention and more users?

I’m sure they know it but let me make some suggestions anyway.

Linux desktops are being really successful in some sectors but, overall, education is the one where is doing better. I think that, if KOffice team focus even more energy in the education market, they can win a small battle that will help them to get into other sectors, into other battles.

Why should they do that? Why is the education sector a good target for KOffice?
1.- OO and M$ are putting more attention on other sector, specially business.

2.- From an usability point of view, both are hard to use and have tons of features that students never use. This means that a small team of smart developers can fit their needs by doing things different. KOffice developers have those skills and the resources needed to become relevant in this new market.

3.- MSOffice and Openoffice are heavy apps. In many schools only old computers are available, so performance problems come along. This has been going worse lately. KDE + KOffice is a killer solution from a performance point of view.

4.- They (M$ and OO) try to be a “one for all” type of app. In education it is much better to use one app for one purpose. Specially with little kids. GNOME has done a good job on this and KOffice has good technical points to achieve it. Only heavy integration with other apps and between office apps justify that politic. OO has a very weak point here, integrating with desktops. M$ only integrates with M$ products the way KDE or GNOME can do it.

5.- Most of the users (specially teachers) do not use anything but the word processor from a office suite. So for most of them, a office suite is not needed. Politics and non experienced (in computers) teachers think they do. Integration with the desktop and other apps is a solution for both of them. In one side, we give teachers what they want. In other hand, we make student use it with apps they like.

6.- Kids use drawing apps. M$ do not have any good one. Integration with the word processor is needed. KOffice is doing a good job on this.

7.- KOffice can be integrated with other apps and desktop features that students love, like IM clients, audio and video players, web services, etc. KOffice can become fun to use. Users see Office suites as boring. They are.

8.- The visual design is not adapted for kids in OO and M$. KOffice can outstand both, specially with the realease of KDE4.

9.- Internationalisation is a key feature for schools that M$ do not have.

10.- First world governments are putting money in linux for schools and they believe (wrongly, in my opinion) that office suites are a key app to teach. Being competitive in this sector will bring a huge attention to this project and to KDE in general.

11.- It would be a good reason for politics to decide to switch from Windows to KDE, avoiding including OO for many profiles, specially students under 12. It would show how powerful linux(and KDE) is in adapting itself to special needs.

12.- KDE is getting popular in schools. KOffice can take advantage of that.

13.- KOffice can have different interfaces for different profiles without having to rewrite the code. An interface for little kids would be an outstanding first step.

14.- KOffice is more suitable to get people involved in its development since is part of KDE project.

15.- Focusing on education do not means to abandon the actual path. I think that, if it is done the right way, putting effort on education would attract more energy into the KOffice team, so the total manpower can be balanced. If that attraction do not happens, the effort is worth it anyway because of the increasing of KOffice users in schools.

16.- It opens a new unexplored market, that means innovation. Innovations is equal to excitement, that means more energy added into KDE.

After my experience in mEDUXa, this is really clear to me. I know people from other edu projects agree, like the guys from Skolelinux. Education is a big opportunity for KOffice. If they (we) don’t go for it, somebody else will. It is just a matter of time.

Big deployments of desktops and Kiosk Mode

Another item included in Edu-day discussions was related of the importance of the kiosk mode. I’ve written this while travellling and haven’t checked grammatical errors. I’ll do it the following days. But today it has been published info about the aKademy 2007 and I think it is the right day to publish this. Sorry for my english.

The kiosk mode is a key feature in KDE for big deployment because many reasons. This post go through two of them:

1.- Reduce the amount of data to transmit for updating desktops.

2.- Allows a systematic method of setting profiles for users so costs are reduced.

All the features of the desktop and the kde apps can be controlled in one directory, in a few number of .txt files under /usr directory. This means that, by changing a really few light archives, we can control desktop configurations and set different profiles with heavy customisation, that the user cannot change. This is basically what kiosk mode allows us to do. When we talk about thousands of computer with different profiles, like in mEDUXa (35,000 with 5 profiles each), this is a big issue.

When we talk about homogeneous networks or deployments, we do not refer to the network itself, specially the bandwith. This usually depends on geographical factors hard to control, so its heterogeneous. Traditionally this has been a huge problem in many places. The Canary Islands are no exception. Not just because they are seven islands in the middle of the Atlantic sea, but because they are volcanic, so there are many mountains.

Lets resolve a simple math problem. If I have to change a configuration in a desktop that is placed in user space, in a .txt file of 2 KB for example, it means that, if I have 10,000 users in 100 schools (100 users per school), I should send to school servers 2×100=200 KB through my network, and then make an update of 2×100= 200 KB in each school (if some users are able to log in with different profiles, the number grows) through its LAN. That is a total of 200×100=20,000 KB, something around 19.5 MB.

If the configuration change means 3 archives of 30 KB each, placed on the user space, and we have 1100 schools, 300,000 users and 5 profiles, you add the problem of bandwith limitations (we have ADSL of different bandwith and many satellite connections in many schools) to this equation, and then, the enormous cost of sending technicians from one island to another one… sleeping well gets harder. Kiosk mode makes a difference.

First of all, kiosk mode is set by text files, really light. By configuring features in a centraliced way, you only have to make one change (under /usr) per profile in a machine (if it is set locally), and not per user. This is a huge reduction on the amount of data that needs to be updated, so the control of that process and the possible point of failure are drastically reduced.

By setting the features configurations under /usr/local/share, we avoid user from changing them.

Lets take a look at firefox, for example. If you use a proxy to navigate, this browser doesn’t let you place that feature in the system space, so you cannot block it from being manipulated by users. Since the browser is used almost every day many times in a computer lab of every school, we can say being optimistic, that at least, once each two days the teacher is going to have a problem. He is going to tell the school coordinator about it so he/she will send the report to the centralised support department, that a user cannot navigate, lets say, once each two weeks. The technician will take about 5 minutes to figure out if it is a network problem by checking it, connect to the machine by ssh, check the browser, go to the user profile and verify the proxy configuration. 5 minutes a week per school means 5×1100=5500 minutes, that is 12 working days (8 hours each). If the cost of an hour is 30 €, for example, that means about 2700 € per every two weeks, 5400 €/month. If the computer lab is used 8 months per scholar year, not following the kiosk mode in this case cost about…. 43,000 €

Of course you need to set a solution for that before the disaster takes place. So you can make all kinds of hacks to solve a structural problem of the app or go directly and substitute it, if there is any available, by another one with the same features, that can be integrated in kiosk mode (KDE app). If there is any, you pay somebody to fix it (hopefully the developer) or…..kill yourself. Or even worse get killed by teachers or students because you don’t solve the problem.

Of course this is not a real problem. They can be even worse. But it shows clearly how important is for big deployments that all desktop and apps features can be configured through the kiosk mode and why it is such a relevant argument for electing KDE. This can help people understand why windows has such a huge cost of support per machineper year.

But kiosk mode is not just a feature, it is an agreement of a community to follow some development rules that allow other people to customice the desktop and apps in a systematic way, simplifying the action of setting and changing configurations and avoiding failures because of users actions. It is even more, it makes possible to extend the concept of scalability to the desktop, by allowing to offer different profiles in the same machine without multiplying the points of failure in a linear way. This means that in the future we can achieve the idea of a student using different profiles during his scholar life but having the same user space, saving all the data and customisations he has made in school and taking them home. Only with kiosk mode is possible to think in a profile for the math class, another one for chemistry, etc. for each student. Each of them with requirements established by teachers, implemented centrally by technicians and deployed in a short period of time.

So I have two important suggestions for KDE developers.

1.- Make all your features configurable using kiosk mode.

2.- Document them. So projects like mEDUXa can apply them and users can take advantage of them.