Exit Dokeos, 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 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 better and understand the complex processes of PHP and HTTP. In one year time I was Zend Certified. 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 the 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 requirements, 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. Several of us calculated the cost of providing services to Dokeos were actually higher than what we earned (in short, we were investing in Dokeos).

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, or 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, I decided that 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 are already doing 95% of the technical work, organizing yearly and monthly events much more successfully 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 of September to December, I gave an agreed period of time 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 and 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 in Dokeos that same day (so the current Dokeos is still one month back in terms of developments in comparison to the Chamilo version 1.8.6.2 just released). 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 is that the project lost, in just a few months, all of its full-time developers, its lead developer, all of its development community and most of its active forum contributors. The good thing is that they were all gathered inside the Chamilo project.

What does this mean? This means that if you were a community member of Dokeos in the past, you will be better at home in the Chamilo community now (or at least from the end of the month, when the website will be 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 a mistake). 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.

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 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: http://beeznest.wordpress.com as I should probably have done since the very beginning… :-)

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.

Joining us for lunch?

In BeezNest Latino (the new name of Dokeos Latinoamérica), we have lunch together every Wednesday at a nearby restaurant. It’s a tradition, and it’s on the company. Today though, a few of us got there about 5 minutes later than the firsts, and were greated  with no seats left and two separate tables with people having lunch independently. This already happened once in the past (in over a year), but today I was in a particularly bad mood (doesn’t happen much) so I decided to take action and avoid this repeating itself. I thought of a series of ways to explain that, and then I thought about this:

And these were my questions to my team:

• Who recognizes this? (most people do)
• What looks like the most important part of this picture?
• Do you find the food important? The place? The people? (I hope everyone will agree that the people there are the most important…)
• Are the members of the “meeting” or “reunion” or “lunch” separated in three little tables? Why?

This facilitated a lot the discussion that came afterwards, where I explain the only reason we were having lunch together is to be able to discuss of things a little bit out of the business context, and that I hoped they were appreciating it as much as I did.

Well, anyway, when will *you* join us for lunch?

Training course for the Zend certification

We’re preparing a great training course for PHP in Lima (not remote though) that will start in February, exclusively in Spanish and exclusively during the week-end. I’m telling this here because we managed to gather 4 (and possibly 5) of the only 5 Zend certified engineers of Peru to teach it. I’m sure that’s going to be a great event. It’s going to be a high-level course, so there will be a qualification exam to enter it. If you have developer friends in Peru, pass the word: http://www.dokeoslatino.com/cursos/php

Stopped using InPhonex

I started using InPhonex, a VoIP provider for individual customers, about 2 years ago because I needed a professional phone number in Lima, Perú, and there were very little providers for this kind of number at the time. During the first 6 months, I had disconnect problems almost every week. While discussing with InPhonex support, it appeared they changed their codec, then something was supposedly wrong with my internet line (I had another IP line from Belgium working just fine on the same phone, same internet connexion). Finally, I gave up and accepted it would be up 4 days per week, and then unreliable the 3 other days, in average.

This being said, I had a lot of business cards printed with this number, so I was reluctant on letting it go. So finally, two years later, as I managed to use another phone number on all printed stuff and got to make almost everyong forget about it… my number 705 97 28 is no more. That’s US$13.95 less wasted per month. Really… not very happy.

PHP Day Lima 2009 – Retrospective

Before I forget all about it, I want to make a note of what happened, what was good and what could be improved for the PHP Day event we organized jointly with Mobile Bridges, another software development company in Lima.

The schedule was the following (translated to English for the purpose of this article):

• 5.00-5.10pm: Welcome words
• 5.10-6.00pm: High availability, efficiency, efficacy and interoperability in PHP – Humberto Bejarano, RPP
• 6.00-6.50pm: Flash with PHP – Alexander Quevedo, Mobile Bridges
• 6.50-7.40pm: Increasing the coverage of PHP solutions in scenarii of Microsoft platform – José Alania and Daniel Ramirez, Microsoft (or partners)
• 7.40-8.00pm: Break
• 8.00-8.50pm: Experiences with PHP: “El Comercio” case – César Soplín, El Comercio
• 8.50-9.10pm: High efficiency of PHP applications in Firefox 3.5 – Percy Cabello, The Mozilla Foundation
• 9.10-9.30pm: High efficiency of PHP applications in Internet Explorer 8 – Jorge Oblitas, The Mozilla Foundation
• 9.30-9.45pm: Word from the organizing communities
• 9.45pm-10.00pm: Words of closure

First, a few words about the program… The idea was to be really useful to the PHP developers community. The title “High efficiency of PHP applications in Internet Explorer 8″ was actually proposed by Microsoft. As much as this title doesn’t make sense for me as a PHP developer, the title was imposed for the Firefox part (I opposed to that), so both talks sounded as ridiculous to me.

Enter the actual speeches.

The first speaker, after presenting the configuration of his media website, was holding the position that files (on disk) were the most efficient (=fast) way of caching data (faster than database and memory accesses). Any person having followed a Computer Architecture course would understand how impossible that is. A few assistants were surprised and asking to confirm that they heard well… the only point we got to was to make the speaker admit that *maybe* implementing an additional in-memory caching system would improve this further.

When asked to please continue the questions & answers in the next room to leave place to the next speaker (we were already 15 minutes out of schedule at that point, which was entirely caused by him), he denied and said he would be taking *just one more question*, and actually took 3 more, lasting 10 more minutes. On several occasions when sharing comments with speakers in other events (and notably one in France), I was told the most unrespectful thing to do for a speaker was to take more time than allowed (if not invited to), as it was actually directly reducing time for other speakers.

That would explain why I was upset with such an answer. He also mentioned there was no recognized PHP certification, which is wrong (the Zend certification has been around for more than 5 years now and is internationally recognized).

The Flash with PHP stuff was actually interesting in terms of PHP development. It discussed a library that allowed conversation between PHP and Flash apps.

Now before I detail the third speech, let’s just say that we had specified to all speakers that the presentation had to focus on what is useful to PHP developers, and not be a commercial show, so to speak. Microsoft people approved that before being programmed, but apparently we have a different notion of what is a commercial speech. The second slide (after the title) was saying in huge letter: INTEROPERABILIDAD, and the speaker at the time explained how, as a huge development company, Microsoft was pushing towards interoperability. I had to laugh. When you know about Microsoft’s huge lawsuits in Europe because they don’t want to disclose how to work with their NTFS filesystem and about not making Internet Explorer independent of Windows, and so many other things around this…

Anyway, the talk was about the new integration work of PHP in Microsoft Server 2009’s IIS, and how it was faster than Linux. I wonder how much money Microsoft is pouring into the PHP integration marketing glass, but I’m sure it’s much more than what it is actually putting in development. Then a short explanation on how to install PHP on a Windows Server, actually passing over all the crispy bits (like the IIS configuration), and then flying over to their new web-based installer which allowed to install open-source software in PHP (Drupal, SugarCRM, …) which, “of course”, was not to be used in production because only the professional, paid-for, versions of open-source software were actually safe to use in production (referring to SugarCRM, between others). So basically, a kind of CPanel made by Microsoft to automatically install and configure open-source software, all the way calling it innovation. When detailing the efficiency of the solution, one comment that slipped through was that the IIS server was *just* a little slower than a Linux solution.

In the end, 3 speakers shared the 40 minutes speech, and one more (all Microsoft or Microsoft partners employees) helped answer the questions. It felt like they needed to actually be that many to answer questions about Microsoft’s movement of so-called “interoperability” and “high efficiency PHP integration”. The only question I had was why there was never an effort on developing a native PHP library for Active Directory, instead of passing through buggy, undocumented LDAP compatibility mode in order to be able to do that (and if Microsoft’s intention was so good, why not put 3 developers on it for a month). The answer was fuzzy, and then the Microsoft marketing clown, Jorge Oblitas, came to the rescue from the public (he wasn’t invited into this talk as far as I knew but hey, any help to answer my question was welcome) and explained that it *wasn’t that easy*. I agreed at the time that it was probably not that easy, but actually thinking back I don’t think 3 developers for a month would be a low estimate. It’s like taking the secret Active Directory documentation from inside the Microsoft’s library and developing a C library that respects the PHP libraries standard (and apparently they are keen to mention that they have a lot of people working on this).

Anyway, this talk got me upset because of the lack of accuracy, the lack of respect for the pre-set organization (two speakers on the list, one more appearing out of the blue and another answering questions of the public!?) and the underlying commercial features about how open Microsoft was.

I couldn’t assist to the fourth talk, mainly due to administrative stuff I had to do at that point, but I was told it was “good” and killed the Microsoft speech about how easy it was to install PHP on Windows, by an example of a, Ubuntu system and a sudo apt-get install apache2 libapache2-mod-php php5-mysql

Nor could I assist to the entire Firefox presentation, but people were reporting it was good and useful.

I did, however, assist to the Internet Explorer 8 speech, and it was neither useful for PHP developers, neither innovative and neither sincere. One of the most important stuff they hammered down was that it was *safer* than Firefox because it was actually reporting suspicious websites more than was Firefox. But we all know that, from the user base of Internet Explorers 6, 7 and 8, Microsoft gets much more visibility on what sites might actually be suspicious. Instead of sharing that database, making something really useful for everyone, they’re keeping that well locked down and consider it a primary feature of their new browser.

When discussing the possibility of PHP developers to actually use Internet Explorer 8 to test their developments *without* the need to install Windows, the answer was pretty much “just buy a copy of Windows, it’s not that costly”, going down into the least it can cost you (US$100 if you’re under a campus agreement up to US$700 – for Windows 7, that is). Apparently this is what is considered “acceptable” by Microsoft and a real help to PHP developers. Apparently, this point actually upset the speaker and put him in a corner, where he started saying ungraceful stuff like that he thought that we preferred Linux because it was a better system, not because it was cheaper, which kind of got him a very bad press from the whole audience.

Finally, the community word allowed me to mention the bi-monthly PHP events we are organizing, and allowed the other organizers to indulge themselves with the great organization and thank the audience.

It did, however, prove interesting to get 77 PHP developers together that night, and I think I’d better get things done by myself next year, to make this really good and avoid a night of Microsoft commercials.

The PHP Perú forum is a great tool to get those PHP developers contacts together and organize meaningful events.

Using crontab

I found a great page that gives a very short an concize manual for using crontabs: http://www.adminschoice.com/docs/crontab.htm

Style broken when installing Dokeos on one local computer then seeing it from another

A frequent question I’ve been asked is why, when installing Dokeos on a local computer, then trying to see it from another computer, the styles are broken (the homepage appears as a list of links from top to bottom).

This is all a question of Name Resolution (or DNS).

How you did it

The initial problem lies on how you did the installation on your local computer: you downloaded Dokeos, then took the easy way and installed it on “http://localhost/dokeos/”, or “http://127.0.0.1″, or even your local IP “http://192.168.0.15″ for example. Didn’t you?

Well, Dokeos remembers that, and asks you, during the installation process, what URL you want to access your portal with. You remember that?

Why this is a problem

As Dokeos remembered it, it will now serve the future pages as if they were starting with http://localhost, or whatever name you gave it during the first install. You can check that, from the other computer, by pressing CTRL-U in your navigator. You will see links like this for the query to the stylesheet (CSS): http://localhost/dokeos/main/css/dokeos_blue/default.css. Well, guess what… “localhost” for the secondary computer is not equal to “localhost” for the main computer. In fact, “localhost” on the secondary computer is pretty much itself, so he’s trying to look like this: http://myself/dokeos/main/css…

This means that the secondary computer is expecting Dokeos to be installed locally as well, which, in general, is not the case. If it was the case, you would probably get even more problems in the current situation anyway.

How you should do it

The *best* solution is to give the first computer (the server) a public name. This public name can be a public subdomain name (like courses.yourinstitution.com for example), but this implies an access to defining such a name. This name will be permanent and equal for all, so everybody will know where the computer is and you will define this subdomain name at the moment you install Dokeos, then use it with all the other computers. If you don’t have a permanent internet connexion, however, and you use an external domain name server (the one from your internet service provider for example), this configuration will not work.

The second best solution is to have a local name server and define a name for the Dokeos server on that local domain name server. This works like above except you don’t need an internet connexion for that to work. Sometimes, the router can act like a name server (see your router’s documentation).

The third solution (which is not one of the best one, but still works in a closed environment) is to make sure the server has a fixed, permanent IP address, and define a unique name for the Dokeos server (like say: “www.dokeos.local”) then define this name on every computer (including the server).

Under Linux, this is done by defining a line with the fixed IP address of the Dokeos server, a space, and the given local domain name (www.dokeos.local for example) in the /etc/hosts file (you need root permissions to edit this file).

Under Windows, the same file exists with the same format, but you have to look a bit deeper to find it: C:\Windows\System32\drivers\etc\hosts.

Don’t hesitate to report if you found a better solution.

The free software activist game – draft

If you are a free software activist like me and want people you expose free software to in conference, large meetings and other gatherings like that (preferably developer-oriented) to understand what the value of free software is, here is a game proposal for you to try out (please report on the success of this method if you do implement it). It is inspired from a recent SCRUM course we took here at BeezNest Latino.

General considerations

• You will probably need 30 minutes at a minimum to implement the game
• This should work for 30 to 150 people, which should all be in the same room
• You will have to explain the rules to each teams category separately (they can already start working one you’re done explaining, but they will have to stop exactly 10 minutes after starting)

Material

• 1 sheet of paper for each participant (can be a quarter of A4, or even smaller)
• 1 pen for each participant (this might be costly, so you can depend on each participant having one or having minimum 2 pens per team)

Preparations

• Try to use maximum 10 minutes for the whole preparation process, so max 2 minutes to get team leaders to line up in front of you, max 2 minutes for you to explain the rules to all categories, and max 2 minutes for them to get back to their seats and start working.
• Try to plan for enough space to give each team its own round-circle
• Plan to distribute pens and papers quickly and efficiently
• Assistants will have to form teams of 5 (minimum 5 per team, can be up to 8 but you’d better ask for 5)
• Teams will be split in three “types”: type A, type B, type C
• Give one paper and one pen to each participant
• In each team, there will be: 1 team leader, 1 salesman, 1 developer, 1 designer, 1 quality assurance guy (software tester)
• You (and ideally a few other guys) will represent the Product Owner: that is, you will receive the work done by each team, through the salesmen, and decide which is best for your company. The price is considered equal for each feature.
• If there are more people than what makes an equal number of teams in the three categories, assign more teams to category C

Rules

You will have to explain the rules to each category of teams at a time: first, teams A*, second, teams B*, third, teams C*. Try to give each team a number (A1, B5, C3, …)

The following rules are true for all teams, but there are a few rules specific to each team category:

All

• Will have 10 minutes to complete the game (develop one feature – you can imagine something appropriate to the circumstances here, or you can use the list of features suggestions below)
• The salesman will have to present his product to all product owner in 30 seconds
• The product owner will decide (secretely) which team won for each category, and will ask the other categories to vote as well (on the back of their paper, or by folding the paper in a specific way)
• All members of the group must write something on his paper
• Team leaders help the other members of the team who are having difficulties (they are the scrummasters)
• Salesmen make sure they understand the product and all its goodness (including quality and design)
• Developers make sure they describe the feature in many details
• Designers make sure they draw a set of screenshots for the salesmen to present at the end
• Testers make sure they test every detail of the system (including the user interface) and confirm with the developer and designer that every feature works
• Teams can choose whether to sell their software or the fruit of their work

Teams A

• Will be considered as representing companies being located in the same city, so they will actually compete very closely with the other teams in category A
• All of A teams will develop the *same*, proprietary, feature
• Team leaders and salesmen can “spy” on other teams

Teams B

• Will be considered as representing companies being located in different countries/states of your continent, so they will have to compete if they have a very competitive product
• All of B teams will develop different, proprietary, features
• Team leaders and salesmen can “spy” on other teams

Teams C

• Will be considered as representing companies worldwide which already have a competitive product based on open-source software
• All of C teams can decide to work with other teams in order to get several features back to their customer
• They can only sell what they developed directly, they are forced to “give away” the rest

Features list suggestion

• Store contacts
• Send an e-mail to a contacts
• Store an invoice
• Request the status of a stock of products
• Request information about a company
• Chat
• Find an address
• Show a street on a map
• Show a translation
• Find an image
• Find the definition of a word
• …

Ending the game

The assistants have to put their sheets in the hands of the salesmen and the salesmen will stand-up and go line-up in front of the stage, once the time is up for their category. Teams not sending their salesmen in line will be eliminated (they delivered behind schedule).

Each salesman comes in a line to present his product (30 seconds max). He says his team number (e.g. A3) and starts describing his solution. He stays on stage until all salesmen have given their description (should be 2.5 minutes max for 5 teams)

At the end of each category, the other categories vote for the best team. You count the vote (“Put your hand in the air, all people voting for team A3″) and declare the winner.

Note that categories A and B should not know that category C was able to share their work. This is why categories A and B will actually understand better the point of free software.

Conclusions

Whatever the results are, they should always tend to these conclusions

• a majority of teams of category C have performed better, because they were allowed to share, and they made an effort to learn from each other, while concentrating on its own customer’s satisfaction
• the salesmen are necessary because they are the ones through which the work of the team is presented. The best salesmen give a considerable advantage to its team
• sharing, in the same environment (which is a competitive international market), leads to better solutions than the equivalent non-sharing mode
• all assistants will have spent a good time

These rules are to be considered licensed as Creative Commons BY-SA (http://creativecommons.org/licenses/by-sa/2.0/)

A series of short, good articles about PHP

I just realized, through Chris Shifflet’s twitter feed, that there is a website called PHPAdvent, that gives a list of articles by celebrities or half-celebrities of the PHP world (including a few interesting ones about PHP advocacy).

http://phpadvent.org/2008