Creating multiple git forks using upstream branches

Working with Git is… complex. It’s not that it’s from another world, and the complexity is probably worth it considering the crazy things it allows you to do, but sometimes it’s just mind-bloggingly complex to understand how to do things right.

Recently, we’ve had to manage a series of projects with changes that cannot be applied directly to our original Git repository on Github, so we decided, after giving it some thought, to make several forks of the project (instead of branches), to manage more clearly permissions and the real intentions behind each of the forks.

This would allow us a few important things:

• define precisely permissions based on the repository
• use the repository to pull changes directly on our servers
• have some level of local customization on each server, using local commits (and subsequent merges)
• keep easy track of the changes that have been made on requests from some of our “customers” (they’re not necessarily commercial customers – sometimes they’re just users who decided to go crazy and show us what they can do, and we want to show that in public)

To do that, we need to fork our project (chamilo/chamilo-lms) several times over.

So the first problem is: you cannot fork the same project twice with the same user.
Adrian Short (@adrianshort) kind of solved that issue in his blog article, saying that you can just do the fork manually, creating an empty repo on Github and filling it with a copy of the main repo, then adding the origin remote manually.

Even though that works, the Github page (starting from the second fork with the same user) will *not* indicate it has been forked from chamilo/chamilo-lms: you’ll have to issue the
git remote -v
command to see that the upstream is correct.

The second problem is that the article doesn’t dive into the details of branch-level forks, so this article intends to solve that particular missing detail, and in that respect, the Github help is definitely useful. Check Syncing a fork help page if you want the crunchy details.

To make it short, there are 3 issues here:

• fetching the branches from the original repo (upstream)
• getting the desired branch to be checked out into your local repo
• defining that, from now on, you want to work on your repo as a fork of that specific branch in upstream (to be able to sync with it later on)

The complete procedure then, considering my personal account (ywarnier) and the original chamilo/chamilo-lms project on Github, with the intention to work on branch 1.9.x, would look like this:


git clone git@github.com:chamilo/chamilo-lms
git remote -v
git remote rename origin upstream

(here you have to create the “chamilo-lms-fork1” repo by hand in your Git account)

git remote add origin git@github.com:ywarnier/chamilo-lms-fork1.git
git remote -v
git push -u origin master
git branch -va
git fetch upstream
git branch -va
git checkout --track remotes/upstream/1.9.x


This should get you up and kicking with your multiple forks in a relatively short time, hopefully!

Creating a new branch in Mercurial

A really good guide on branching is available here: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

In my case, I wanted to branch a previous version of my code to launch a parallel branch for bug-fixing of the previous release. I used the Chamilo code repository on google code. I already had a local copy (in /var/www/chamilo), so what I did was:

• cd /var/www
• hg clone chamilo -r [the changeset of the previous release, in my case 5c49a5e35ade ] chamilo-1.8.8.6 (this last bit is the destination dir)
• cd chamilo-1.8.8.6
• hg branch 1.8.8.6 (from there on, the default destination for my commits here will be the “1.8.8.6”, which will only exist after my first commit)
• did some changes
• hg commit -m “Fixed security flaw …” index.php
• hg branches (this shows that there are effectively 2 branches, the “default” and the “1.8.8.6”)
• hg log -l3 (shows that we are effectively at changeset 5c49a5e35ade + 1 commit)
• hg push –rev 1.8.8.6 (with double dash) (this pushes only in branch 1.8.8.6 – this triggers a warning asking me to confirm the creation of a new branch in the upstream repository)
• hg push –new-branch –rev 1.8.8.6 (these are  two double ‘-‘, by the way)
• because I cloned from the local repository, I actually just pushed in my “local upstream”
• cd ../chamilo
• hg push –new-branch –rev 1.8.8.6

Done. Now all normal people will keep sending to the default Chamilo branch, but anyone wanting to improve 1.8.8.6 will just be able to commit to that branch. Not sure yet that “1.8.8.6” was the right name choice, but it’s too late to lament on that.

Drupal: Aplicación para la gestión de contenidos

¿Que es Drupal?

Drupal es un C.M.S (sistema de administración de contenidos), que permite a varios usuarios publicar, administrar e organizar la información en su Web. Es una aplicación de código abierto construida mayoritariamente en PHP con licencia GNU/GPL, escrito en PHP, desarrollado y mantenido por una activa comunidad de usuarios. Destaca por la calidad de su código y de las páginas generadas, el respeto de los estándares de la web, y un énfasis especial en la usabilidad y consistencia de todo el sistema.

 

Información General
Sistema Operativo	Multiplataforma
Uso	Gestor de contenidos
Licencia	GPL
Web	http://drupal.org
Demo	http://www.drupalgardens.com
Lanzamiento Inicial	01 de Enero del 2001
Iniciador del proyecto	Dries Buytaert
Eventos	http://groups.drupal.org/events
Proveedores oficiales	Acquia/Drupal
Casos de éxito	http://buytaert.net/tag/drupal-sites
Logo	Historia del logo de Drupal
Instalador	Drupal 6

Documentación
Manual de instalación
Manual de administración
Manual de desarrollador
Introducción a Drupal
Guía de estructura de Drupal
Guía de construcción de sitios
Guía de diseño

Conozca más Aplicaciones de Software Libre :  Aquí

Firma de convenio entre la Asociación chamilo y la Univerdiad de Tocantins – Brazil

El 20 de Agosto del 2010 la Asociación Chamilo – Bélgica y la Universidad de Tocantins – Brazil firmaron el convenio de colaboración, a fin de  contribuir a impulsar el crecimiento de la plataforma e-learning Chamilo.

Firmaron convenio de colaboración el Ing. Yannick Warnier, fundador y líder de desarrollo de chamilo; Geraldo Silva Gomes Vice-Rector de la escuela de postgrado de UNITINS; y el Rector de la Unitins. Gracias al convenio la comunidad de Chamilo se beneficiará de documentación, pruebas y traducciones al portugués.

Del mismo modo en el mes de Agosto la empresa Contidos Dixitais (España) y NoSoloRed (España) también  firmaron convenios de colaboración con la Asociación Chamilo – Bélgica para ser socios oficiales de Chamilo .

La comunidad de Chamilo agradece de manera especial el apoyo y gestiones para estar presentes en Brazil:

• Geraldo Silva Gomes Vice-Rector de la escuela de postgrado de UNITINS
• Igor Yepes, Docente y Coordinador Académico de UNITINS, y esposa
• Marco Sousa, Docente de UNITINS y Contribuidor de traducciones de Chamilo, y esposa
• Luciana Machado Fraga, Coordinadora del Curso de Sistemas de la UNITINS y esposo.

Los miembros oficiales de la asociación esta creciendo  si de manera personal o su empresa desea ser parte puede escribirnos es nuestra sección de contactos para darle toda la información que necesita.

Exit Dokkeos, Enter Chamilo

Those of you watching closely the Dokeos code will have noticed… I stopped contributing to the project in December 2009, along with my team of 12 and all of our fellow community members. The only changes we sent were actually customer requirements, so no way to avoid that. But that’s it.

I officially stopped working with Dokeos on January 1st, 2010. As many huge actors in the open-source (MySQL/MariaDB, OpenOffice.org/LibreOffice, …) and PHP development world at the end of 2009, it was time for a big change. On one side I think it is just sad to let go of something you’ve been involved in with so much of your love, sweat and personal motivation. On another side, there was no possible compromise between a company that strengthened its fist around the open-source software neck a little bit more each year.

I started working with Dokeos for a reasonable hourly fee in 2004, and continued working (for the same fee all along, that is) until the very end of 2009. But I accepted the conditions were somehow something I could accept in exchange for the possibility to work on free open-source software full-time. Well… It wasn’t really full time at first (more or less 10 hours a week), then it became full time in 2006 and became an unbearably high load in 2007, then I started hiring people to help me.

Hiring people is not easy. You have to find the right ones… the chosen ones. The ones that would do the things exactly like you under the same conditions, or that would do them differently, but with the same results. Or even without the same results but for the same reasons. Anyway… it is a wonderfully complicated process. Even more when you want to achieve something for the software you are desperately involved in. That’s what I did. That’s why we are now a 12-people strong company that’s producing more FLOSS than any other company here in Perú (and possibly than a whole lot of supposedly open-source companies around Latin America). That’s where following a dream can lead you, and that’s also why accepting conditions opposed to your dreams is not an option when you reached that level.

Dokeos was a very simple application when I started working on it. And I was a very unskillful developer at that time. In 6 months time, I managed to get much more qualified and understand the complex processes of PHP and HTTP. In one year time I was Zend Certified and started writing articles about PHP and web development. In two years time I had become Dokeos’ lead developer.

In 4 years time I had become the leader of a development company that would represent Dokeos and spread the Dokeos trademark and quality image throughout Latin America, injecting all benefits into the open-source software. Then, apparently, the Dokeos company considered this wasn’t as good enough for them, so instead of them embracing the opportunity I was offering (of showing off a very productive international extension), I was asked to contribute a fee to use the trademark (that we had been developing ourselves since 2007 – see Google Trends).

Then, right in the middle of 2009, we reached breaking point. We argued (me and the Dokeos leadership) about the very principle of using and developing FLOSS and the fact that it wasn’t worth upsetting the community by removing a bunch of useless features to appear in a “professional” version rather than “adding” true, worthy features in a special compilation.

The problem was an ethical problem all along: removing existing features, be they only in the beta version of Dokeos, implied people from the community had already contributed to these features through feedback or patches, and we were just stealing their work to get a few more lines on a marketing folder about the pro version. Just not worth it in my point of view. I remember commenting (I don’t know if in June or later in September) that if he really wanted to move things like that, then I couldn’t see why I should follow him, and that I would probably launch a fork to avoid the software dying this way (which was an unweighted comment at the time – obviously not that far out).

A little bit later, and in an unrelated aspect, as a group of three main providers for the Dokeos company, we asked for better communication and planning in our work with Dokeos. All denied. It became worst. Less communication, less planning. We wouldn’t know when someone new was joining the team or leaving it, except by talking with the person itself. We wouldn’t know when a customer was a  customer. No information about what type of contract he had or the remaining amount of hours of support. This became a nightmare to manage.

In response to our requests (or should I say suggestions), the Dokeos company asked for all the developments to be planned and a budget to be established. Sadly, this implied bigger investments still, to work for Dokeos (where I don’t object about planning and budgeting, we had so far pretty much tried to get full agile, developing and reporting frequently, with less long-term planning, as a reflection of what customers needed). Several of us calculated the cost of providing services to Dokeos were actually higher than what we charged (in short, we were investing in Dokeos instead of providing profitable services).

This would all have been more acceptable to me if we had received some kind of guarantee that we would have our word to say on the future of Dokeos as a free software, and that we wouldn’t be working our asses off for a trademark that belonged to someone else, to be finally kicked out when it so appealed to the owner.

And so emerged two possibilities: keep doing the same and bend to the rules of someone with whom I didn’t share opinions (and I had already started bending for a while), or find another way to both continue doing what we were doing best, as well as kicking that trademark problem away. After many discussions, with many people involved both inside the Dokeos community and inside other professional communities, it appeared to me that, all in all, we had nothing to lose, and that our community of users and, more importantly, our own customers, would be better served by a split (actually, we were already doing 95% of the technical work, organizing yearly and monthly events much more successfully – in terms of attendance – than the ones organized by Dokeos, writing our own documentation, having our own localized support service, contributing to the Dokeos community much more than the Dokeos ever did, etc).

However, I was hesitant. Mostly because changing the name of a product you’ve worked so hard to promote is just like burning your house down right after you built it. But if this house had a fundamental flaw that made it unstable? We couldn’t live in there, neither could we invite our clients for lunch. Just too dangerous.

So, during the long months from September to December 2009, I gave an agreed period of three months (from a meeting on the 11th of September in Brussels) to the Dokeos company to propose a change in its structure. I reminded the expiry date to Dokeos a few days before it happened, but I was ignored, pretty much the same way so many of the users that ask Dokeos for quotes regularly are ignored because they don’t look professional enough… At this point (is was the 11th of December), I decided it was time to move on.

We stopped submitting code patches and new features to Dokeos that same day (so the current Dokeos was still one month back in terms of developments in comparison to the Chamilo version 1.8.6.2 when it was released in January 2010). I professionally announced my intentions and the ones of my company and finished the pending tasks we had been assigned, and officially stopped working for Dokeos on the 1st of January 2010.

The sad thing about Dokeos was that the project lost, in just a few months, all of its full-time developers, its lead developer (myself), all of its development community and most of its active forum contributors. The good thing is that they were now all gathered inside the Chamilo project. Dokeos was also now free to free itself from its community chains (which apparently is what it wanted).

What does this mean? This means that if you were a community member of Dokeos in the past (not only a customer), you will be better at home in the Chamilo community now (or at least from the end of January 2010, when the website will be [editor note: now “was”] much better equipped to host a series of interesting services). If you were a Dokeos customer… well you can hold to your hosting contract in Dokeos. Maybe you will be upgraded to a free Chamilo version within 6 months, or maybe there will be a new Dokeos version within that time, with half the features there are in Chamilo (but hey, some people say that less is better) and double the bugs… The only thing I can assure you is that if you were happy with my work in the past (which basically means the leadership of versions 1.6.5, 1.8.0, 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.8.6 and 1.8.6.1 of Dokeos – or all of them in the last 4 years), you will be happy to follow the Chamilo project.

To let you get a taste of what’s inside this new (minor) version, you can have a look at our demo portal: http://campus.chamilo.org

We have already received a lot of e-mails to support us in our initiative, and I thank you for that. Not having collected the authorizations to publish them in full with names, I’m just quoting a few:

“Hi Yannick, I think you’ve done well. Greetings and all my support to you in this new project” – from Italy

“… and as much as I was telling you this for the Dokeos project, I would like to contribute in the limits of my abilities to the Chamilo project” – from Spain

” Congratulations with this important step!  I think this will help this nice electronic learning environment much better.” – from The Netherlands

“… sounds exceptional to me…” – from Argentina

“Best of luck with this new branch-project!” – from Mexico

“I’m starting to collaborate with Chamilo and I’m happy for your enthusiasm in the the new enterprise. I hope I will be carried away by the enthusiasm.” – from Italy

It goes without saying that we didn’t use the Dokeos database to send this e-mail (that would have been an ethical mistake in my opinion). We rather contacted about 1000 contacts we made through events, blog posts, social networks, bug reports, etc.

Now let’s go to the practical topics…

What about Dokeos Pro and Dokeos Medical? Will they have equivalents in the Chamilo project?

The short answer is NO. Chamilo will be a free package. Additional extensions might be sold separately in case they require important investments that need to be covered, but the politics will be specific to Chamilo providers.

That question, though, has been worrying a lot of people since the creation of these “versions”. The truth is… it’s very easy to understand. In Chamilo, we want software to be free and accessible. If you want the videoconference or Oogie, you can get them from the sources of Dokeos. Any competent developer + sysadmin should be able to install it and get it running. Obvioulsy a lot of people have done so. You can find very cheap services on the internet of people that will do it for you. Furthermore, the Chamilo administration documentation will include clear installation instructions for all these, where the Dokeos installation documentation hid them to mark the difference between the free and the professional packages.

The software, however, is not everything in an e-learning project, and if I have to work for you, then I will charge you. On one side because I need to pay my bills, on another side because I couldn’t help everybody at the same time if I were helping for free. Easy enough to understand, I think.

Now the second point is that, as much as we’d like everything to be free, there are some things that nobody is actually willing to pay, like the development of a new tool that *we* think that will improve your e-learning experience, but that *you* don’t want to pay for (because you want to see it before you buy it). In this case, we’ll develop the extension and charge for it until the expenses are covered. This way, we allow people to get the exclusive use of a tool for a reasonable period of time (ahead of their challengers). This means that there *will be* professional versions of Chamilo, yes, but they will not be based on software options, but rather on a set of services (training, invitations to events, unlimited support, free course content and much more that we will soon detail on our website).

Whether these professional version of Chamilo will be endorsed by the association is something we still have to discuss, but we (BeezNest Latino aka Dokeos Latinoamérica) will definitely be at the cutting edge of e-learning technology, and will provide both new developments for the free version and productivity-improving packages that will first need to be covered financially to ensure more innovation comes faster in the future. This being said, most of our business will be generated from services, and we will not redirect development resources towards non-free products.

On a side note, the Chamilo Association, defending the open-source project and the safe use of the Chamilo project name, will be promoting contributions to the open-source software through the allocation of grants. These will be considered part of the financial cover for our possible non-free modules (i.e. you will not have to pay yourself to get high value solutions delivered to your door, as long as you support the association).

Will the videoconference and Oogie tools be free in Chamilo?

As explained a few weeks ago, they have always been. What isn’t free is the service to install them, but the code of both tools is GPL, and as such is public. I have personally contributed considerably to both, so in virtue of the General Public License, I am free to re-use it and re-distribute it. So as far as I’m concerned, the tools will be made available more obviously when time allows (the change of name is considerably time-costly, so you’ll have to be patient).

This being said, “Oogie” is a trademark, so we won’t be using that name either. Rather something like Chamilo-Office.

Why would you work so much for something that is free? Wouldn’t it be easier to just abandon and work for Microsoft?

Points of views are things that might change quickly over time, but personal beliefs tend to be more permanent. It is my belief that the open-source model works (sell the services, not the software), and it is my intention to be a personal proof of that. Now that doesn’t mean it’s easy money, and I’m certainly not doing it to become rich. I believe that by getting involved deeply in the open-source software development, I can help people and do my “social responsibility” move as well as develop a stable and comfortable professional career. Comfortable is not exactly the correct adjective for my current situation, as I’m working an awful lot of overtime to kick-start this project, but I think that getting through 2009 with a company of 12 and without a single budget-based lay-off shows just how strong we could be in a strong economic context. 75% of our work has been open-sourced in 2009. We hope we can maintain that rate through 2010. And yes… it would be easier (but more boring) to work for Microsoft, certainly.

Conclusion

Now is time to give you a nice and short conclusion:

• we were many unhappy amongst the Dokeos community
• 90% (at least) of the active contributing community agrees and is moving with us to the Chamilo project
• the Chamilo trademark is defended and shared by an association, as part of its goals, so the same split will not happen again
• we (my company and I) used to develop the Dokeos software for 65% in 2008 and 2009, and it reached 85% with other developers coming along with us
• if you were our customer, the service to you will only get better
• if you were part of the Dokeos community, you will feel a bit lonely staying there, most probably
• I will not work for the Dokeos company in the future, unless deep structural and philosophical changes are made

I hope to see you join the Chamilo community soon. The best you can do right now is register on our website: http://www.chamilo.org and let us know that you are willing to give us a hand, or just let us know you are supporting the initiative, morally (that’s good enough for us). You will receive notifications later this month on how to best contribute to the project and make it a success. If you are our customer, don’t contact us, we will contact you very soon with more details.

This blog will continue existing for the sake of continuity, but I will be slowly moving on to the more professional BeezNest’s blog soon: https://beeznest.wordpress.com as I should probably have done since the very beginning… :-)

2012-07 update

• The Chamilo project is now used in 180 countries around the world
• Our community reached 1,000,000 (self-registered) users this month (we do count reductions in numbers as well)
• We have customers with Chamilo campuses ranging from 200,000-employees to 50-customers
• We have been interviewed *many* times by radios, podcasts and magazines (printed and web)
• We are organizing around 10 events per year (both in-person and virtual) and participate to around 50 others per year, promoting Chamilo and how to use or contribute to the project
• Chamilo received 2 open-source awards in 2011 (Packt Publishing and Portal Programas)
• The Dokeos project closed its development repository to the public less than two months after we left and created Chamilo (in an attempt to prevent us from re-using fixes they would possibly develop – in the end we returned the system and they are now re-using most of our fixes and ideas, because we remained open to all). This also removed the possibility for us to “compare” our development speed with them through tools like Ohloh’s.
• Chamilo now has local national (and official) groups in Belgium, Spain and Peru (and is currently preparing one in France and one in Venezuela)
• Chamilo now integrates key usability features for the teachers directly from the browser: recording your voice, generating voice from text, drawing, photo retouching, drag & drop of documents, etc.

In terms of what our first goals were in 2010, we certainly reached them. The business around Chamilo took time to launch though, but we have now reached a step where our customers come pretty much on their own. The future is bright.

Building a free open-source development business is not easy

Note: I’m talking about free, public, open-source software here, not that hacked open-source stuff that you just provide to your customers.

Mostly, the difficulty of managing an open-source business is that there are even less good management people that know what free open-source software is than there are good management people at all. And then when an open-source business in launched, it’s most probably because the initial entrepreneur knew what open-source software was and thought he had a good idea on how to make business with it. Sadly, the combination of technical, legal and management skills necessary to do that well are extremely rare.

And let’s imagine you would have that… you then realize that software development (in any form) is one of the most costly services there is. I mean… non-open-source businesses can get away with selling their software several times and generating money from multiple sales, that will end up covering the initial, huge, development costs. But in a truly open-source fashion, you shouldn’t sell any of the software you develop. You should just sell the development service (and other services around it). And then you fall into yet another problem: the development staff of an open-source development company is actually the less profitable staff. Trainers’ services can be sold on the basis of the software, but then their efforts have to be directed towards the development team. Salespeople can made tremendous benefits on the sale of services, but then a service is actually something quite difficult to get a fixed agreement on, so sometimes the services (in particular the development services) take more time than initially planned. Times = money. You crunch on the profit the salesman did. Then what’s left should be directly invested into R&D to follow producing competitive software, because otherwise you’ll just have to wait until someone develops the next cool thing your customers will want.

And just in case you would hope something like that, your development team will probably be very motivated by the opportunity to contribute to open-source software, but don’t expect them to work a minute of their time for free to help a community member. That’s not what they signed for…

So what? You probably benefit from tools that have been open-sourced and that you would have had to develop otherwise… True, but that doesn’t represent nearly a tenth of what this project is actually costing to you and the customer, and even when it would, you would have to keep a constant eye on new open-source solutions (technology watch). And who will do that if your developers are already busy respecting that deadline the client asked for and for which he would probably have looked for someone else if you didn’t accept it?

Well, believe it or not, we are managing it. In 2009, about 75% of our developments were open-sourced, but we still *had to* do a 25% part as closed source (at least temporarily), and we have a very, very tight budget. So I’m wondering… is it really a good idea to do business this way? Shouldn’t we just open a non-profit association to do that instead of getting killed by the amounts of work weighing down on us to get the budget, the time and release as open-source?

These days, I’m trying to hack the model a little bit. I will not fall into the trap of either developing everything closed-source and then supposedly “release it next year”. That is just an excuse for never doing it. There will never be an advantage, for a single business, in doing the additional work of releasing a one-year-old piece of software. It will be too old already. This will imply remastering it, which implies a considerable budget, which implies having sold a lot of this product. But how do you sell a lot if people know you’ll make it public later? Doomed.

So there are a few possibilities here:

1. find the killing combination of software + services and sell services at a price considerably higher than what it costs, in order to finance your development services with the profits
2. improve sales by focusing on content creation and training, and consider the development as a hidden cost
3. develop a system based on the software as a service model, where people do not have a practical way of using your (free) software without going through you, but that just doesn’t make much sense if you really embrace the open-source philosophy
4. using people’s creativity: put a system in place that will allow you to get a small fee on the sale of one person’s creation to another person…

I’ll be trying 1, 2 and 4 this year and see what that leads to.

Too busy

I don’t know what’s happened but August was supposed to be a quiet month and then all of a sudden dozens of work requests appeared and we have been completely drowned with work. The good news in all that is that a lot of new features are coming out for the benefit of all in Dokeos, but I’m not sure I can sustain the rhythm of 4 hours night sleep for much longer…

We’ve also been working a lot with Mercurial the last few weeks and, although the system is very flexible, it has pretty much become our nightmare to work with it, mostly because of poor implementation of the Eclipse – Mercurial plugin, which has proven… not buggy, but *very* unintuitive (we were doing pretty well with Subversion before). As a team of 10, having to spend 10% of our time resolving unsubmitable commits is just a pain in the *** and makes us loose a lot of time and efficiency. This being said, we have decided to go for the terminal way (like command-line, not suicidal) for now to avoid the upsetting plugin.

We now have a central public repository, private client development repositories, and a private “pro and medical” versions repository, that we use to develop customized versions of Dokeos for specific activity sectors.

I am also *trying* to improve what the Dokeos internal network can do for you, as there is a lot of space for improvement there right now.

There are a lot of free software conferences planned for the end of the year (where I have my own lorry space) and I have been invited to Edutic in Chile on the 23rd of September (invitation to Dominican Republic was abandonned for crisis reasons).

Dokeos event for Americas

DOKUDA - Dokeos Users Days America

If you’re a fan of Dokeos and plan to head to South America during the next few days, then you definitely want to get to DOKUDA, the 25th and 26th of June 2009.

We’ve been preparing the event for about a month now, and should get about 500 different people every day, over a two-days period. All the conferences are in Spanish, so you’d better understand it a little bit, but we are really welcoming warmly any North American or Canadian wanting to pay a visit to this international event.

All the information is on the afore-mentioned website, really, but there are a few things I’d like to point out:

• the event will be free and non-for-profit (possible benefits will go into development of educational projects here in Peru)
• the event has been advertised in an incredible amount of external websites, thanks to an amount just as incredible of people just motivated by Dokeos
• the event is divided into two days of talks: one technical day and one business/institution day
• we’re going to have the honor of having two speakers from Spain (+ one in videoconference) and two speakers from Uruguay, who will join the fun and talk about their experiences with Dokeos and the future of e-learning in America (Central and South, mostly)
• a technological fair has been organized at the same time, so companies can show off their products
• we’re going to have talks about new Dokeos 1.8.6 features and the plans for the future
• we have invited national ministers to get to know how e-learning can help their institutions
• we have over 16 talks in total, with topics all centered on Dokeos
• some OLPC XO will be there, to show what can be done with Dokeos

In conclusion… this is going to be a GREAT event. Don’t miss it. Any doubt, just comment here or fill the contact form on the website!

OLPC project, Escuelab and Dokeos/Chamilo

Today I went to the Escuelab in the centre of Lima to meet with Alberto, Kike Mayorga and Kiko Contreras.

My visit was apparently taken with great interest and they’ve video-interviewed me for some time to talk about DOKUDA and my projects with Dokeos and the OLPC (now updated to Chamilo and the OLPC). Apparently, the idea to have Dokeos/Chamilo run on one of the XO itself was never thought about, and that seemed to be an announcement of uttermost interest to them that this *could* be done at all. They suggested I try straight away (which I did) but my knowledge of Fedora was a bit limited at this point to know where exactly to download the packages. I did try some rpm -q and yum install commands, but without success (yum install apache seemed to trigger the download of something unrelated, I’ll have to investigate this further). Although this is unrelated, I saw that one could actually run Ubuntu on these (not that I have intentions of trying that shortly).

Apparently the problem that would be solved by the install of Dokeos on one of the XO is that when the government is sending XOs to remote areas, it also sends them with a PC pre-installed with Linux, which is supposed to serve as a server for the XO. However, people in remote areas cannot manage them, so someone around tells them “That thing is useless, just install Windows to be able to use it”, and they do. Of course, this is an illegal copy of Windows in most cases.

This brings two moral problems:

1. Children are curious. When they’ll want to know how the system works, Windows won’t give them the ability to analyse this.
2. Children want to share. How will the teacher deal with the student wanting to share some proprietary software which most certainly costs about one year of his parents’ revenue? Make him a software pirate at the age of 6 without letting him know about it?

Installing Dokeos on one of the XO’s (where Windows *cannot* be installed) ensures the system can remain there and is “transportable” (they can go on a walk and write about what they’re doing into Dokeos directly if the teacher goes with his XO as well). The only problem so far would be the disk space (and possibly the RAM, but Dokeos uses very little RAM per script loading).

Sebastian Silva apparently is also part of the “team” but is currently in Bolivia if I understood well.

One of the plans of the team is to setup a bus trip in remote areas equipped with the laptops in order to update the systems, reinstall the PCs under Linux and explain them how to use them. That sounds like a lot of fun. I’ll be tracking that project.

Escuelab already confirmed they *did* want to come and show their projects during the e-learning event at the end of June (DOKUDA)

Dokeos used on XO/OLPC in primary school, Uruguay

Ana Elena, from Uruguay, sent this video to Dokeos Latinoamérica the other day. We first discussed in a blog comment on the Dokeos Latinoamérica’s blog, then I wanted to know more about their project, so this was their answer…

Cute, isn’t it? The teacher also explains that the next step for them is to have the parents get into Dokeos as trackers of the children’s progress (and that the children actually *want* them to see what they’re doing).

We have invited them to the Dokeos Users Day America, on the 25th and 26th of June, in Lima, Perú (if you’re reading this with interest, then you should come too!)