Summary
——-
The goal of this project was intended to have Eucalyptus cloud to
support ARM images so it allows Debian developers and users to be able
to use such facility for taks such package building, software
development (ie. Android) under a Debian pre-set image,
software testing many others.

What was expected to have at the end is a modified version of Eucalyptus
Cloud that supports ARM images on the first place. To date this goal has
been reached but is not complete, read production-ready. Extensive test
needs to be done. Besides that we have another goal which is to get
Debian community to use this new extended tool.

Project overview
—————-
Eucalyptus is a hybrid cloud computing platform which has a Open Source
(FLOSS) version. It’s targetted to be used for PaaS (Platform as a
Service), IaaS (Infrastructure as a Service) and other ‘distribution’
models. It can be used also for cloud management. Given that it has
implemented the EC2, for computing, and the S3, for storage, API, it’s
compatible with existing public clouds such Amazon EC2. Currently it
supports running i386 and amd64 images or NC (Node Controllers) in
Eucalyptus naming.

Eucalyptus is a complex piece of software. It’s architechture it’s
modular composed by five components. Cloud Controller (CLC), Walrus (W),
Storage Controller (SC), Cluster Controller (CC) and Node Controller
(NC). The first three are written in Java and the remaining are written
in C. Our project modifications was targetted to the NC component,
altough there is a remaining task for hacking the UI to allow setting
the arch of the uploaded NC image instance.

The Node Controller is in charge of setting the proper information for
Eucalyptus to be able to run virtualized images. Eucalyptus uses XEN and
KVM hyphervisor to handle internal virtualization subsystem, and
Libvirt, which is an abstraction of the existing virtualization
libraries, for program interfacing.

Having that in mind we are back to our project. For our project to be
sucessful we had various tasks to do. Beginning with understanding such
complex piece of software, followed by hacking the requiered bits and
later integrate the work so it results in a useful tool. Our approach to
the project was then inline with such description.

The project’s history
———————

I started my participation in GSoC approaching Steffen to discuss about
what was expected, or more accurately, what was in his mind. We
exchanged emails previous to my application and that resulted on my
application being submitted. From the beginning I should tell that I
wasn’t much clear on the ‘final product’ of the project, however we
refined ideas and goals during the weeks following to the official
begining of the project. What was clear for me, after all, is that for
this to ‘see the light’ and gain adoption Eucalyptus code needed to be
dealt with.

Our first task was review ARM image creation from scratch, using the
work done by Aurelien and Dominique in previous GSoC. I’ve managed to
get an updated ARM image running under qemu-system-arm. The issues
presented in the past were almost unexistant now that the versatile
kernel is official. You can see this on my first report.

After that being done and sometimes in parallel my main goal was then understand
the internals of the Eucalyptus software in order to figure out it’s
feasibility, where do we need to extend and how big the task is, we
didn’t knew upfront. From the beginning of the project Steffen was kind
to introduce me to the Eucalyptus developers and that have resulted in a
good outcome for Debian, IMHO, to date.

Understanding Eucalyptus internals was quite a fun task to say the less. As you
can see on the first part of the report Eucalyptus is modularized and
the component I was expected to work with was the NC (Node
Controller). Given that I isolated my work focus, I started to focus on
learning the internals about that component.

Node Controller as described is in charge of ‘talking’ with
virtualization hyphervisors in order to arrange things to run guest
image instances. The module has basically one main component: handler.c,
in charge to talk to the appropiate hyphervisor and there are
‘extensions’ (think of OOP polymorphism but acknoledge it’s plain C)
that interact with KVM or XEN.

I figured that if qemu-kvm is ran in Hyphervisor mode we can manage to
run an ARM image with qemu-system-arm. Given that Eucalyptus has
interaction with KVM hyphervisor in place, this answered the question of
the project’s feasibility. First green light on.
>From this point the scope reduced to interacting with the KVM handler
(node/handler_kvm.c) and extend it to support running an image that is
not amd64 or i386.

NC makes use of libvirt to abstract interaction with Hyphervisors. So,
the next phase was learning about it’s API and figure what’s needed to
be modified next. Libvirt uses a XML file for setting Domain (in
libvirt’s naming) definitions. So, Eucalyptus provides a Perl wrapper to
generate this file on runtime and allow the NC to invoke libvirt’s API
to run the instance. Next task then, was adapt such script to support
ARM arch. The current script is taiolred for amd64 and i383. I worked on
that front and managed to get a script prototype, that can later be
improved and support more arch’s.

Generating an adequate Libvirt’s XML Domain definition file for ARM can
be a heroic task. There are many things to have in mind given the
diversity of the ARM processor and vendors. I focused on the versatile
flavour given that I was going to test the image I built on the first
place and it ran fine under qemu-system-arm.
The Perl script wrapper then was adapted for such configuration and it
can be tested independently by issuing the following command:

$ tools/gen_kvm_libvirt_xml –arch arm

The –arch parameter is what I implemented and it’s intended to be
called from the kvm handler on instance creation. With the extensibility
in mind I’ve created a hash to associate the arch with their
corresponding emulator.

our %arches = (
‘amd64′ => ‘/usr/bin/kvm’,
‘arm’ => ‘/usr/bin/qemu-system-arm’,
);

Added the arch parameter to the GetOptions() function and used
conditions to tell whether the user is looking for a particular arch,
arm in our case. The most important parts to be considered are the
, and entries.

hvm

$local_kvm

There’s also and that require to be tailored for arm.

root=0800

As output the script generates an XML template that can be adapted to
your needs and it could be used and tested with tools like Libvirt’s
virsh. So that, it can be useful independently of Eucalyptus. I managed
to get to this point before the midterm evaluation.

Now that we had the XML wrapper almost done, the next task was to make
the handler call pass the arch as an argument to the script, so the
image is loaded with the proper settings and we are able to run it.

Eucalyptus doesn’t have a arch field for NC’s instances. So, after approaching
Eucalyptus developers, with whom we had already being interacting, I
settled to my proposal of extending the ncInstance struct with an arch
field (util/data.h). The ncInstance_t struct stores the metadata for the
instance being created. It’s used for storing runtime data as well as
network configuration and more. It was indeed the right place to add a
new field. I did so by creating the archId field.
Now I needed to make sure the arch information is stored and later used on the
libvirt’s call.

typedef struct ncInstance_t {
char instanceId[CHAR_BUFFER_SIZE];
char imageId[CHAR_BUFFER_SIZE];
char imageURL[CHAR_BUFFER_SIZE];
char kernelId[CHAR_BUFFER_SIZE];
char kernelURL[CHAR_BUFFER_SIZE];
char ramdiskId[CHAR_BUFFER_SIZE];
char ramdiskURL[CHAR_BUFFER_SIZE];
char reservationId[CHAR_BUFFER_SIZE];
char userId[CHAR_BUFFER_SIZE];
char archId[CHAR_BUFFER_SIZE];
int retries;

/* state as reported to CC & CLC */
char stateName[CHAR_BUFFER_SIZE]; /* as string */
int stateCode; /* as int */

/* state as NC thinks of it */
instance_states state;

char keyName[CHAR_BUFFER_SIZE*4];
char privateDnsName[CHAR_BUFFER_SIZE];
char dnsName[CHAR_BUFFER_SIZE];
int launchTime; // timestamp of RunInstances request arrival
int bootTime; // timestamp of STAGING->BOOTING transition
int terminationTime; // timestamp of when resources are released (->TEARDOWN transition)

virtualMachine params;
netConfig ncnet;
pthread_t tcb;

/* passed into NC via runInstances for safekeeping */
char userData[CHAR_BUFFER_SIZE*10];
char launchIndex[CHAR_BUFFER_SIZE];
char groupNames[EUCA_MAX_GROUPS][CHAR_BUFFER_SIZE];
int groupNamesSize;

/* updated by NC upon Attach/DetachVolume */
ncVolume volumes[EUCA_MAX_VOLUMES];
int volumesSize;
} ncInstance;

With that in place what was left was modifying the functions that
store/update the ncInstance data, and also the libvirt’s function that
calls the gen_kvm_libvirt_xml script. I’ve modified the following files:
- util/data.c
- node/handlers_kvm.c
- node/handlers.{c,h}
- node/test.c
- node/client-marshall-adb.c

Most important the allocate_instance() function that is in charge of setting up
the instance metadata a prepare it to pass it to the handler, then
hyphervisor trough Libvirt’s API. The function now has a new archId
parameter as well, to keep coherence with the field name. It also
handles whether the field is set or not. We (Eucalyptus developers and
I) haven’t settled wether to initialize this field with a default value
or not. I’d stepped up and initialized with a NULL value for this string
type var.

if (archId != NULL){
strncpy(inst->archId, archId, CHAR_BUFFER_SIZE);
}

Stores the value only if it’s passed to the function. This is essential to
don’t break existing functionality and keep consistency for later releases.
With this we almost finished the part of extending Eucalyptus to support
arm images. It took quite long to get to that point. Next step: test.

As I mentioned in my previous report the current Eucalyptus packaging
has issues. From the beginning I’ve approached the pkg-eucalyptus team,
who were very hepful. So I myself set me up and joined the pkg team with
commit access to the repo. Even the GSoC is not intended for packaging
labour, I needed to clear things on that side because what we want is
adoption so anyone, say a DSA or a user, could setup a cloud that has
support for running arm instances under amd64 arch.

Over the weeks between mid-term evaluation and past week I’ve worked on
that front. Results were good, as you can see in the pkg-eucalyptus
mailing list and SVN repo.
Eucalyptus has a couple of issues that because of it’s nature and complexity
triggered build errors. Those issues came from the Java side of the project and
few form the C-side. The C-part was a problem with AXIS2 Jar used to generate
stubs for later inclusion on build-time. There’s no definitive solution to date
because one of the Makefile on gatherlog/Makefile issues a subshell call that
doesn’t catches the AXIS_HOME environment variable. I’ve worked around this
by defining it as a session env var from .zshrc. The other problem is related
to the Java libary versioning and most likely (we had to investigate further)
to groovy versioning.

As I explained Eucalyptus has 3 components written in Java. The Java code uses
extensively the AXIS2 library for implementing webservices calls, the groovy
language for JVM, and many other Java libaries. Eucalyptus open source version
ships both ‘online’ and ‘offline’ versions. The difference is basically that
the offline version ships the Java libaries JAR files inside the source code,
so you can build with all required deps.

Our former packaging used a file to list which Java libraries the package
depends on and it symlinked them using system wide installed packages. This
rather than helping out triggered a lot of problems I explaing with more detail
on the pkg-eucalyptus ml. I worked around this by telling the debian/rules
not to use such file to symlink and instead use the existing ones from
the source. The last weekend I managed to get to that point and built
sucessfully the software under Debian. I’ve done that in order to have a
complete build-cycle for my changes, and then test. In fact today I’ve
spotted and fixed a couple of bugs there.

What’s available now
——————–
To date we have a Eucalyptus branch where my patches are sent. The level of
extension is nearly complete, more testing needed. One missing bit is to
change the UI so that the user selects which arch her image is and that
value is passed to the corresponding functions on the Node Controller
component.

We also have an ARM image that can be tested and later automated. I’ve
recently learned about David Went’s VMBuilder repo that extends Ubuntu’s
vmbuilder to support image creationg. I might talk to him to adapt the tool
in order to support creation of arm images and use it to upload to an
Eucalyptus cloud.

I’ve also created a wiki page with different bits on which I was working on.
I’ve yet need to craft it to be more educational. I guess I’m going to use
this report as a source :)

We also had more strong cooperation with the Eucalyptus project and
involved their developers on the packaging and this project, which is
something I consider a great outcome for this project and GSoC goals:
to attract more people to contribute to FLOSS. I’ve also been contacted by
people from the Panda Project and we might cooperate also.

Future work
———–
I plan to keep working on the project regardless the GSoC ends. Our goal
as Debian could be integrating this into the Eucalyptus upstream
branch. We have good relations with them so expect news from that side.
I also plan to keep working with the Eucalyptus team and related
software in Debian, given that I’m familiarized with the tools and
projects.
I’m also planning to advocate SoC for Debian in my faculty. To date we
had already 4 students, IIRC, that have participated in the past.

Project challenges and lessons
——————————

During the project I faced many challenges both in the personal side
and in the technical one. This part is a bit personal but I expect we
learn from this.

First challenge was the ‘where do I sit’ problem. My project was
particular, indeed quite different from the others on it’s nature. I had
to work on a software that is not Debian’s and then come and say ‘Hey we
have this nice tool for you, come test it!’. So, indeed, my focus was on
the understanding of such tool, Eucalyptus, and not much on looking back
at Debian because I didn’t feel I had something to advertise yet and
indeed I got most valuable/useful feedback from Eucalyptus developers
rather than Debian’s, which for the case is OK IMHO. I had great
mentoring. This situation probably looked a bit of ‘isolation’ from my
side, from Debian’s POV, but it was not intended it’s just how it needed
to be IMHO. I felt that I wasn’t contributing directly to the
project. I’ve spoke about such thing with Steffen a couple of times. I’d
like to say that it was also my concern but I probably failed on
communicating this, second challenge.

Third challenge was more technical and related to the first one. Since I
was not writing any code for a Debian native package/program but instead for
other project I faced the situation of where to publish my
contributions. Eucalyptus had some issues on managing their FLOSS repo
and the current development one is outdated comparing to the
-src-offline 2.0.3 release. The project didn’t fit pkg-eucalyptus repo
neither, even we thought to branch the existing trunk and ship my
contribs as quilt patches, but it involved a lot of more work and burn
on reworking something that has issues now. Later on time I branched the
bzr eucalyptus-devel Launchpad repo and synced there with the
src-offline code. I was slow to react on thing I can say.

Fourth challenge was also technical and still dealing with. I was looking to
setup a machine to set a cloud and test my branch. The Dean of my faculty
kindly offered a machine but I’ve never managed to get things arranged
with the technical team. Steffen and I discussed about this and evaluated
options, at the end we settled on pushing adoption rather than showcasing it.
Since for adoption we need a use case, I’ve spend some SoC money on hardware
for doing this. I should have news this week on that side :)

Finally, I’d like to thank everyone on the Debian SoC team for this
opportunity to participate. I like to thank Steffen for his effort on
arranging things for me, Graziano from Eucalyptus for his advice on
working with the software code. The different people from Eucalyptus I
interacted with and showed interest on the project’s sucess. My
classmates and teachers from the Computer Science School at UCSP in
Arequipa-Peru, friends from the computing community in Peru – SPC and
finally my family. Thank you, I learned a lot, specially on the personal
side. As Randy Pausch put: “The brick walls are there to give us a
chance to show how badly we want something.”

Resources
———

Please see the Wiki page[1] for any reference to the project’s resources.

1- http://wiki.debian.org/SummerOfCode2011/BuildWithEucalyptus/ProjectLog

Best regards,
Rudy

What was done so far
——————–
- Extended the ncInstance_t struct on util/data.h adding the archId
parameter. This struct keeps the information regarding a node (nc),
say RAM, Kernel, etc. Currently it has no way to set an arch in order
to be used later.

typdef struct ncInstance_t{
...
char reservationId[CHAR_BUFFER_SIZE];
char userId[CHAR_BUFFER_SIZE];
char archId[CHAR_BUFFER_SIZE]; // arch field added
int retries;
...
}
The Eucalyptus team was OK with this approach that I’ve proposed few
weeks ago. For all my changes the approach is maintain compatibility
with existing features.
We still have to define if we are setting a default value, say amd64,
or keep it unset until the user sets one. For now we will be supporting
amd64 and arm as valid fields.

- Modified the allocate_intance() function to support the archId
field. This involved adding a new parameter and detecting whether its
present and setting de value accordingly. This function is later used
by the doRunInstance() function in node/handlers_kvm.c

- Modified the involved functions that are called by the KVM handlers
and result in passing parameters to the XML file generator for being
used by libvirt’s and KVM and have the image running under
Eucalyptus. The new parameters and field are not required and only
being used if they are set with a value. The archId parameter has been
added as the last one, so existing function calls can work. This could
be rearranged later, but will involve a more extensive revision with
Eucalyptus developers.

- I’ve set a git local repo in order to keep track of the changes to
Eucalyptus. Since this part is a sort of a Eucalyptus branch I took
this approach. Steffen and I are discussing whether to release this as
a pkg-eucalyptus branch (as dpatch, using existing packaging). Either
way I’m putting the diff files form my git repo over the wiki and will
put them on my site too. I plan to use git-svn in order to send them
later to the pkg-eucalyptus repo once we are settled with this.

- Updated the project’s wiki[1] page with information regarding all that’s
involved on my work, so it can be ‘re-played’ or resumed later.

1- http://wiki.debian.org/SummerOfCode2011/BuildWithEucalyptus/ProjectLog

What I plan to to over the next weeks
————————————-
- Finish the modifications to the relevant functions. Expected dealine:
next week.
- Do integration tests:
– Write a test program, there’s an example under node/ that could be
helpful.
– Generate the XML domain definition from Eucalyptus functions. The
full cycle: handler_kvm -> allocate_instance -> get_instance_xml ->
have the XML file properly generated -> qemu-kvm runs the instance
using the proper emulator (arm in our case).
- Test runnning the image I’ve worked on the project’s begining.
- Fixing bits and cooperate with the pkg-eucalyptus team on the
packaging bits.
- Talk to Eucalyptus so they adopt our patches.
- Rock and roll :)

What would be nice to have after the project ends
————————————————-
- The Debian packaging *needs* work. I’ve already discussed this on the
pkg-eucalyptus mailing list. I’ve also committed myself to help on
that side even after the SoC ends.
- Talk with upstream and Ubuntu to coordinate the packaging efforts and
modifications to the software.
- Get adopters to use our work :)

By now, few weeks about to finish the SoC, I can say that it’s been a
good experience and as I stated I’m planning to keep maintaing/working
on the software after that. I’ve already joined the pkg-eucalyptus team
and plan to contribute actively. I’m sad I didn’t managed to get Debconf
this year, time was a constraint again, hopefully we can meet in 2012! I
guess that all by now!

Best regards,
Rud

Debian’s social contract 4th item states:

Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.

When we make decisions, either technical, legal and others regarding the operating system we deliver, this is one of the most referred argument. Altough that’s seen as high priority often we don’t have ways to properly know what our users want. While working on translations on the Spanish team we’ve faced this situation. Do our users find them useful? they are able to understand them? they find that a much familiar wording would be bette than high technical details? We didn’t know. Then, the question still exists.

Altough Debian has ways for users to provide feedback (BTS, mailing lists, IRC,  popcon, etc) none of them is designed to offer a way for the user to provide feedback on features, development roadmap and other non-bug aspects that developers and the project can tally and use for prioritize on releases. It’s rather amusing to note that one of the most valuable assets free software community has is user involvement and contribution.

But before we enter in details let’s start on the basics. For using this information we first need to know who our users are? do we? From my findings and interaction with the community I’ve identified two kinds of Debian users who can be clearly named.

1) The derivatives or pure blends, who use the Debian base and framework to build niche distributions.

2) The lead users (using E. Von Hippel’s definition), who are the developers, contributors and a group of users. Debian is, if not the only, one of the projects who is best for fostering lead users. Most of them at some point involve themselves in the development process and some, later become developers.

There is a more diverse group who are end-users but it’s unclear to me how we can group them. Despite that they probably represent the biggest part of the pie.

So, how we do please everyone? can we? In my opinion we can, at some degree. By implementing tools for first: gather user feedback, make statistical data, tally, we later can take informed decisions. In Debian decisions are voted and the set of people who votes are only developers with their own constraints.

I think this would ease the constant that release-decisions-regarding-foo-tech-legal-issue represented on each release iteration, saving time, health and bits.  It could be useful for knowing more about who are the ones we develop things for. I’m thinking of some sort of Dell’s IdeaStorm.com for software.

What do you think? I’m willing to co-mentor this if someone finds that is an interesting project for GSoC. Let me know!.

Que tal Rudy te saluda Cristian Villalta acabo de leer el articulo y me parece de mucha utilidad pues justo ando trabajando en una tesis relacionada a la gestion de proyectos y software libre. Queria hacerte un par de preguntas:
Que problemas son los mas comunes, desde tu punto de vista, en la gestion de proyectos … y … cual es el impacto del Sw libre en la gestion de proyectos, desde ya agradecido.

Saludos.

Originally posted as a comment by Criso on a subversive act of playful cleverness using Disqus.

Los problemas que he observado en los proyectos de software tienen que ver generalmente con respecto a la gestión de equipo y recursos. Por otro lado, uno de los temas que presenta muchas situaciones complicadas es la definición del ámbito del proyecto y los requisitos del mismo. De hecho, hoy, existe una rama de software que se dedica específicamente a la ingeniería de requisitos.

Para el primer caso, el software libre tiene la ventaja de que los integrantes del equipo o proyecto trabajan en aspectos que son de su interés, de esta manera el proyecto en global se beneficia teniendo mejores resultados, personas comprometidas y apasionadas con su trabajo. Sin embargo, esto presenta el problema de que, generalmente, se pierde un poco el sentido de visualización integral del proyecto, cosa que se suele mejorar con la incorporación de roles de coordinación, por ejm. lo que hace Linus Torvalds o Andrew Morton en el kernel linux.

Además, gracias a las herramientas que ha adoptado la comunidad de software libre para soportar su desarrollo, los procesos generalmente tiene un soporte adecuado por lo que se hacen, hasta cierto punto, eficientes. A medida de que una organización tenga sus procesos mejor estructurados y estandarizados podrá obtener mejor provecho de las herramientas que tiene disponibles, y no al contrario. Esto último es algo que observo en muchas organizaciones, generalmente adquieren software que puede ofrecerles infinidad de posibilidades, razón por la cual otras empresas lo emplean, sin embargo al no tener la base definida es poco el provecho que obtienen pues no se busca optimizar el proceso a través del empleo herramientas.

Respecto al tema de definición de requisitos y ámbito del proyecto, podemos tomar, del software libre, como aspecto relevante la constante interacción con el usuario final a través de sus procesos de retroalimentación y la publicación de versiones en etapa temprana (beta). Esto permite que el desarrollo se realice a medida que se encuentre una necesidad del usuario. Sea un informe de fallo, solicitud de características nuevas, modificación de funcionalidad, etc. estas incidencias son las que usualmente activan los esfuerzos de desarrollo y mantienen una línea de vida constante en el proyecto de software. Si se pierde el interés en el software o no se obtiene esta retroalimentación, usualmente el desarrollo se estanca y suele quedar abandonado.

Hoy, el desarrollo que ha alcanzado el ecosistema de software libre ha permitido que cada vez más organizaciones, empresas, e instituciones adopten las soluciones de software creadas por éste. Por un lado, estudios recientes, como los de Gartner, señalan que para el 2012 gran parte de los productos comerciales de software emplearán componentes de software libre y que por lo menos una tercera parte del presupuesto de las empresas para software de aplicación se destinará a servicios de suscripción.

IDC said “Open Source is the most significant all-encompassing and long-term trend that the software industry has seen since the early 1980’s.”

Gartner predict that “ By 2012, 80 per cent of all commercial software will include elements of open-source technology. ”

A survey of nearly 1000 IT staff in the UK, Germany, France and North America, commissioned by Actuate, showed that fifty four percent of businesses in the UK felt that the benefits of open source outweighed any negative aspects

Another Gartners top predictions for 2008 is that “by 2012, at least one-third of business application software spending will be as a service subscription instead of as a product licence”.

Por otro lado, esto también presenta una situación en la que la demanda de profesionales con conocimiento de tecnologías de software libre se incrementa, mientras que la oferta parece ser cada vez más escasa, según demuestran estudios de Actuate.

Research conducted for Actuate found that six in every ten respondents said there “were serious problems finding the right IT skills to implement and manage open source solutions”

El pasado sábado 22, tuve la oportunidad de ofrecer una charla en mi universidad, la UPC, en la que desarrolle estos temas. El enfoque tenia como objetivo el saber cómo aprovechar, inteligentemente, como estudiantes de computación, las oportunidades y recursos que existen hoy para desarrollarnos profesionalmente haciendo lo que nos apasiona: software libre. En este sentido, conversamos acerca del programa Google Summer of Code como una manera de avanzar hacia tal objetivo, por los beneficios que ofrece a nivel académico y profesional. Además, presenté el proyecto OSS Watch, cuyo objetivo es fortalecer el vínculo entre la comunidad académica y la de software libre a través del desarrollo de material académico que introduzca prácticas de desarrollo de la comunidad en los cursos de computación. A través de esto el proyecto busca mejorar las capacidades de los futuros profesionales que les permitan desarrollar soluciones basadas en tecnologías de software libre.

La charla estuvo organizada por el grupo GNU UPC, conformado por alumnos y ex-alumnos de la universidad, que está en un proceso de reactivación de actividades y retomando proyectos a futuro, de los cuales seguro tendré algún grado de culpa. Las diapositivas de mi presentación están en el wiki que he creado para publicar mis trabajos academicos y proyectos personales.

XOs at Islay - Arequipa

Last August I had the opportunity to visit some OLPC schools in Arequipa together with my wonderful friend Anita Chan, antropologist and Stanford’s professor who is writing a book regarding these issues. We choosed Arequipa due logistics and the city itself, one of the spots I like most in my country, but most important because those schools didn’t got any kind of attention. We thought Arahuay, as being the first one, has got lots of attention and we’ll probably won’t see anything new nor relevant to get more feedback from the field.

Our intention was basically to see and understand how the inclusion of the XO laptops is impacting the school environment and learning process, thus teachers and students. I have to say that for me it was also a learning experience. Adapting myself to a non-technologist mindset for seeing things was challenging and key for discovering and understanding the complexity of this. Most of us, techies, are so excited with the idea of technology solving all our problems that we use to forget that there are other factors to consider, I’ve learned this from Anita.

Arequipa is a region which, as many others in my country, extends from the Pacific Ocean to the andean valleys, geography here is very diverse and poses challenges to communication. The Ministry of Education have deployed OLPC’s XO in schools of Atiquipa, Choco, Machahuay, Mollendo, Huaynacotas, Pampamarca, Sayla, Tauría and Toro. Common factor on those towns is their poverty, complicated transportation and accesibility, one-teacher multi-grade schools with no more than two classrooms per school, and lack of connectivity (i.e. Internet). Getting from Arequipa to most of those towns takes about 12 to 14 hours average, some even 20.

Officials at Arequipa Ministry’s Regional Office where so kind and excited to talk to us, share information and concerns and also helped us to set a itinerary. They seem very entusiast about the project and besides all the problems, on which I’ll elaborate on later, there’s a feeling that this is something that is worth doing it and that the targeted population is the right one, who have been always left from such social programs.

A complicated start

OLPC Peru - Interview

Teachers and kids on the School IE 41050 Virgen de Lourdes – Islay where very enthusiast of having us there, but as long as Anita’s interview was ongoing things didn’t appear that good. Ministry officials, in Arequipa, told us that for most of the towns the teacher and mayor themselves where the ones who went the city and took the machines to their towns using horses at some point of their journey, as they normally do. They also showed their concern about the lack of communication with those OLPC schools as they don’t have chance, more than once a year, for gathering the teachers and exchange feedback. Lack of budget for this project is also a concern, some of the officials try to visit the schools that are near with their own budget or when traveling for other duties of their jobs. Most schools have been never been visited by a ministry official, nor media, almost nobody from “the city”.

We found the kids at the school as they were ready for a demo of their abilities using the XO machines, officials and teachers have encouraged them to do so and look nice to us. The two teachers also showed enthusiasm and, while briefly answering the questions, made their best effort to demostrate that things are going well and by using the laptops they had more proficiency regarding teacher-student interaction and learning process. As time advanced and savvy Anita asked the same questions again while I hanged with the kids, the outcome was different.

Stundents with XOs

While conversation continued a handful of issues appeared. Teachers argued that, by having the XO’s, they had to take office of the logistics duties, which complicated their labor since they had to dedicate additional hours, which could be used for academics, with no extra payment (deduced by their implicit complain). Only one of the teachers attended the training Ministry offered and they asked for additional training. Lack of XO skills was confirmed this when one of them told us that she uses a USB pendrive to copy an activity developed in class to the other students’ machines so they can see it, she didn’t knew about the mesh network. I could notice that most kids were just playing with the XO in the same way they do with kids’s games outside the classroom, which happened once they lost interest of having no clue on what to do. Later, I figured out that altough kids were very interested about games, they even asked me if I had some for install, and they managed to find some such eToys, but while they can read, Sugar’s language was English so they had no idea of what to do next. I had to act as personal software-translator for them and guide one on the game then the others followed. Inquiring the students about their activities and how they use the XO on their daily work confirmed that most of them were clueless about it.

Ministry officials in Arequipa told us that for them is complicated to keep track on the project’s schools. Altough they are the direct reponsibles for the project, most of the time the Ministry of Education conducted activites, such technical visits, without notifying them so there is no feedback. “Ministry sends people directly to the towns, they do their job then inmediately return to Lima, never stop by here”, complained an official.

A silent change

Probably for most of us the concept of ownership is something we almost born with, for those kids it was something they have learned with the XO. When they were given the machines they didn’t carry them home, they left them at school and also used to confuse, and struggle for, parts (chargers). They hadn’t adopted the fact that it was something of their’s. Before the Ministry choosed the school for the OLPC project students were usually found hanging on streets after class, since their parents were at work. By having the XO’s they have transformed this in a reason to keep them busy and at home, were they can show the machine to their friends and family members. Parents also are commited with the project and together with the teachers have established a protocol to keep them informed of any kind of issue regarding the machine, here there wasn’t any kind of atempt of robbery or kid’s abuse to steal the machine. Teachers have instructed students to carry the machine inside their backpack and to report any kind of incident, such losts, inmediately.

Tutoring

For these people having the XO has also brought something else than the sole machine. They have become a center of attention. They feel that they are in direct contact with Lima, which is seen as the country’s ruling center, in a way they are confortable with and prefer over Arequipa’s intermediation. After long time being left, they finally are on the spotlight where people like us, ministry officials and the ministry himself, techinicians and in more or less degree, depending the town, people interested on their progress often visit them. Here we understand why they all were looking so enthusiast about the project at the begining. They were trying to look as they were doing good in order to receive attention. I couldn’t figure this out until later discussions with Anita.

By interacting with the kids I’ve learned very interesting things. I’ve found very talented kids that besides their social conditions have all the potential to learn and take advantage of this tool. In this particular school, those kids, digital natives, are not unaware of technology in fact, ironically, they have an old broken PC in classroom from a previous program and are also familiar with mobile phones. I’ve also noted that some are more advanced than others and share their findings with them, which is a good thing in a multi-grade classroom. Kids feel very stimulated when playing games on the machine and achieving something.

Old/new paradigm

A paradigm for a particular world

Although there has been a lot of discussion regarding the potential benefits of the constructivist model, on which even theorists have differences (Philosophy of Education: An Anthology, Randall Curren, 2007) I hold the opinion that our kids should be the priority. By this I mean that the current deployment have clearly shown their problems, which are not from the project itself, nor the software, nor the people who is voluntering but a vast amount of problems the peruvian education and society have been acumulating from years without solution to date. However, our mission as peruvian citizens, and now I call international community, should not be finding people to blame for, or trying to tag as evil others. We should establish a way to help those teachers, to connect them for sharing experiences and knowledge, to conform groups of volunteers to frequently go those towns and act as feedback agents who also can mentor teachers on taking advantage of the XO and give feedback to the developer community.

Interviewving kids

My advice for people interested on this to be sucessful is to help those schools, to gather and build a community of supporters which can also act as society’s part on this ministry’s venture, since they will not have the resources to properly conduct this and our geography is very particular. But more important because should be on our interest, as society, to foster new generations of good citizens who are agents of change and fight sordid ideas which are poisoning young people minds in our country. For people who doesn’t like the project I do encourage you on focus on your personal interests and move on, let others do their best on what they believe is good and will make a difference. I’m very concerned by the fact that most people is interested on despicting the project withouth considering all the implicancies of this forgeting that the more they struggle for the more those kids are not taking any advantage of the machine and the more we, a developing country, will be wasting money.

Finalmente acepte y empece a trabajar precisamente el 1ro de enero del año siguiente. El entorno de la BVL era más tranquilo, no tenían grandes servidores ni cosas sofisticadas; sin embargo tenian algunos elementos que eran bastante interesantes para mi, y creo que claves en mi desarrollo: el proyecto era relativamente nuevo asi que había algunas cosas por construir, había un esquema de telecomunicaciones con los distintos agentes de bolsa a través de un sistema ATM usando el protocolo x25 (antecesor del modelo OSI, TCP) -también conocido como MEGANET en TdP-, el ambiente era tranquilo, teniamos acceso a Internet y el grupo era bastante ameno.

En este lugar es donde logre desarrollar un conocimiento de buen nivel sobre el sistema operativo OpenVMS, a punto que recibia constantes consultas de los nuevos operadores que ingresaban a GMD y de algunos desarrolladores. Mis inicios fueron en el turno de la noche, donde básicamente se procesaba información e imprimia reportes para el día siguiente, ejecutaban respaldos y se aprovechaba parte del tiempo para dormir. Recuerdo que mi primera noche me recoste sobre el sofá que mis compañeros me recomendaron y no desperte hasta las 7am, todavía no me adaptaba; de hecho antes de eso no acostumbraba a desvelarme.
En algún momento pase al turno de la tarde donde tenia que interactuar con usuarios, vestir formal (cosa que jamas me incomodo, salvo cuando me “sugirieron” que use el cabello más corto -obviamente me rebele!-), y sobretodo conocer en persona a los CVL$algo, osea los usuarios, de entre los cuales había algunas guapas chicas; cosa que felizmente parece ser una constante.

Con el pasar del tiempo logré automatizar algunos procesos en los servidores, escribi cientos de programas en DCL, y en algún punto practicamente tenia todo el tiempo libre consecuencia de eso. Logré configurar el stack TCP/IP (ya que esos equipos solo funcionaban en red con el protocolo DECNET), ejecutar y navegar en Mosaic desde el entorno Motif de los servidores Alpha para ingresar a Internet y los servicios en los que ya era ávido usuario (confesión). Descubri todo el mundo detrás de OpenVMS, las conferencias DEC, los grupos de usenet, de los que aprendi, además de incrementar mi interés en conocer el tema en más bajo nivel.

Ocurrio en algún momento que llevamos un curso de Unix, del que ya había oido porque un usuario del chat de Yahoo! lograba hacer cosas que otros no y me dijo que sabia Unix y que debería aprender puesto que todo ese chat estaba sobre Unix. Rápidamente busque en Altavista o Yahoo! y aprendi qué era este Unix.

Luego de la primera clase estuve más seguro de que si queria aprender esto. Lamentablemente desde mi sitio no tenia forma de acceder al servidor en la red de GMD que estaba en el otro edificio. No contento con esa limitación empece a investigar en Internet hasta que encontre la luz: Linux, un sistemas imilar a Unix que se podía ejecutar en una PC. Los siguientes pasos fueron reciclar unos discos duros de 500MB, reducir el espacio usado por Windows 95 en la PC (Pentium 33Mhz, 16MB RAM) que tenia asignado, descargar durante 1 mes -debido a que reiniciaban el equipo y la descarga FTP no tenia “resume”- una distribución de Linux (creo que RedHat 5.x), y tratar de instalar y configurarla, cosa que logré luego de algunos días.

Cierto día buscando información di con la página del Proyecto GNU y leí su manifesto, e inmediatamente coincidi con el mismo. Esto me animó bastante a conocer, usar y promover esto que ahora sabía que se llamaba software libre. Posteriormente supe que habían distribuciones y encontre a mi subsiguiente amor: el Proyecto Debian. Luego de leer su contrato social, manifesto y las directrices, en donde percibi claramente que cualquiera podría contribuir a éste, levante la mano y dije: yo también. Hasta antes de eso no había sentido tan cercano el hecho de que, además de usar algo, también podía hacer cosas para hacerlo mejor y que beneficie a otros como efecto secundario. Esto claramente fue amor a primera vista, de los cuales uno nunca se separa.

Reemplace el RedHat por Debian, que por ese tiempo era complicado de instalar; lo instale en la PC de mi casa, que había adquirido recientemente, y decidi enlistarme en el grupo de traducción como punto inicial de mi contribución.

De las anécdotas de ese tiempo recuerdo una cuando el nuevo jefe de sistemas, ex marino, ingreso al centro de cómputo para mostrarlo a una visita y empezo a describir las actividades y equipos que teniamos. Al señalar mi PC, ejecutando GNOME 1.x, con una terminal ejecutando top y alguna otra cosa, dijo: desde aquí monitoreamos todo. Tuve dos sensaciones, la primera la obvia (no tenia idea de lo que estaba pasando allí -ya que yo mismo me autorice a instalarlo-) y la segunda fue un poco de ego que me decia: exacto, tengo el control de todo esto (cosa que tampoco estaba lejos de ser cierto).

En algún momento, años después cuando ya había salido de GMD, fui a ayudar a mi amigo Oscar con un tema de backups y para sorpresa mía se trataba de uno de los programas que hice tiempo atrás. Finalmente llegaron a usarlo (Oscar era reacio porque no quería olvidarse las órdenes y sus parámetros) y replicarlo en otros proyectos, fue bastante halagador :)

In the last couple of months I’ve been working on a paper which intends to offer a (not so) new -as you might notice after reading it- approach to what the Debian Project have been managing to produce and what can be done to keep doing it better in the new escenery that we are and will be living in the upcoming years.

My work describes the way Debian have been sucessfully producing lead-users, as described by Eric Von Hippel’s Democratizing innovation book, since it’s conception and what elements were key to have done so. Previously it takes a look on how the process of innovation is really done. Then it describes the current and future world’s escenery according research and current trends, later it makes links between them and gives some ideas for us to keep fostering innovation and play a key role in the free software ecosystem.

With this work my intention is for us to understand what we are, what are we good doing, and how we can keep rocking! I want Debian to look further and be the free software development cutting edge project and atract bright people to work on what they are passionate about.

Hopefully I’ll be in Mar del Plata to discuss about this and also have some fun with you guys I haven’t seen in years!

I’d appreciate any comment or feedback to this. My intention is to turn this work into a collaborative fashion that allow us to make our project much more wonderful!

The full paper is here to download (pdf): http://stone-head.org/talks/debconf8-fostering-innovation.pdf

La objetivo principal, más allá de dar a conocer el software libre como tal, era establecer y reconocer prácticas de gestión y procesos que se puedan rescatar e incorporarlos en el desarrollo de proyectos de software de las organizaciones.

La charla inicio ofreciendo un panorama general de los actores que participan en el desarrollo de proyectos de software libre, como podemos ver en el gráfico adjunto, a saber:

• Proyectos en sí,
• Usuarios finales: que incluye a personas, empresas, sector público, organizaciones sin ánimo de lucro,
• Asociados de los proyectos, que son las organizaciones que apoyan a dichos proyectos, caso gobiernos o empresas,
• Partners de los proyectos, que pueden ser empresas u otros proyectos que ofrecen infraestructura base a los mismos,
• Comercializadores de los proyectos, que son las empresas que se dedican a dar un soporte y canal comercial a los productos desarrollados bajo este modelo de licenciamiento.

Luego de esto explique el esquema de trabajo y gestión de los proyectos de software libre, la forma de organización, su estructura jerarquica, infraestructura de trabajo, interacción entre el grupo humano, etc.

A partir de esta información rescatamos algunos valores o prácticas que las organizaciones que realizan desarrollo de software pueden incorporar para mejorar su gestión y procesos de desarrollo.

Entre estos podemos mencionar a los siguientes:

Confía en tu equipo

Esto se refiere básicamente a que la información acerca del desarrollo, incidencias y progreso del proyecto se maneje de manera abierta, sin ocultar información a nigún integrante del equipo. Todos deben estar claros de lo que ocurre. Un esquema bastante similar al definido por Debian y lo que conocemos como el rol de «dictador benevolente».

Revisa todo, prueba todo

Que trata de resumir la necesidad de incorporar y establecer prácticas de testing en el proceso de desarrollo y aprovechar las herramientas de software, o construir las necesarias, para establecer un ciclo constante de auditoria general y automatización del proceso de pruebas de software. De esta manera a medida que se va desarrollando el proyecto también se tiene a la par un proceso que puede garantizar la validación de su funcionalidad.

Todos los desarrolladores son iguales

Algo que no se refiere a las características personales o de formación, sino a la equidad y valoración de las ideas o aportes de los desarrolladores, sean los más experimentados en el equipo o novatos que se acaban de incorporar. Cualquiera de ellos debe ser escuchandos y sus aportes o ideas respecto al desarrollo o diseño de los proyectos se debe tener en cuenta de la misma manera.

Y finalmente, la premisa que no debemos olvidar:

La mejor manera de finalizar un proyecto de forma exitosa es hacerlo de la forma correcta

Que básicamente nos recuerda que aunque tengamos los procesos definidos, las herramientas necesarias y la infraestructura de soporte para el desarrollo de nuestros proyectos; si los primeros se ignoran y no se siguen desde el inicio del proyecto, por razones de tiempo, urgencia, etc; es mucho más probable que a medida que se desarrolle el proyecto ocurran problemas que si se empieza de la forma correcta.

Esto es lo que cuenta al final del día y puede ser el factor crítico que conduce a pérdidas de tiempo, dinero y time-to-market para una organización. Para que un proyecto sea exitoso se requiere la participación de todos los actores involucrados, que va desde la gerencia hasta el desarrollador. No se trata simplemente de dar indicaciones al programador y encerrarlo un número de días esperando que entregue un resultado maravilloso.

Fue interesante el aprovechar que me antecedio una charla sobre  SCRUM, para vincular muchas de estas practicas que tambien son promovidas por frameworks de desarrollo ágil como éste, que fue expuesto por Tobias Mayer de AgileThinking.net.

Es posible que existan otras prácticas que los proyectos de desarrollo de software en las empresas puedan incorporar, si has identificado o aplicado alguno ¡dejanos saber!.

Existe más información sobre el tema que he tomado como referencia para esta charla. A continuación pongo algunos enlaces de referencia:

• Sitio web del MIT que reune trabajos de post-grado sobre temas de software libre. http://opensource.mit.edu
• Articulo sobre el tema en OnLamp de O’reilly. http://www.onlamp.com/pub/a/onlamp/2006/02/27/what-corp-projects-learn-from-open-source.html
• Consultora Stellman Greene: http://www.stellman-greene.com
• Consultora Construx: http://www.construx.com