It is an interesting piece. There’s another interesting thread on a mailing list here.

I would have expected it to talk more about the possibilities of doing OLPC stuff in India rather than becoming a somewhat neither-here-nor-there kind of non-committal response to the $35 device that the Ministry of HRD so loudly released. To understand what can bring about the adoption of OLPC India, one would have to probably go back to a post I wrote some time back.

The problem that was highlighted still remains. There is no community of any form,shape or sort around the OLPC in India when compared to OLPC efforts/initiatives and deployments in other countries (the nations that are so eloquently held up as shining examples of OLPC success). There is a significant lack of a downstream community of volunteers and participants and, more importantly, a lack of any sort of publicly discussed plans as to whether any educational institute would volunteer students for a while to keep the deployments going forward. Then of course there is the added discourse around availability of the actual XO hardware.

When I met Dr. Nagarjuna at GNUnify (that’s February this year), he indicated that he was actively looking at using the Sugar Desktop Environment on standard COTS desktops available much easily from vendors because there wasn’t much clarity about the how and when of the hardware availability. In fact, this has been a murmur that has been around for a while – what specifically is the value add of the hardware if the desktop environment is available via a standard Linux desktop/distribution. Which is where an active group of developers working on activities that would be useful in the context of the deployment is a good thing to have. And for that to happen, there needs to be work on building a downstream community – contributors who use the artifacts provided by OLPC and Sugar to develop their own thing.

A distinct advantage that OLPC/XO/Sugar has is brand recognition. Anyone who is peripherally involved in doing things around Free and Open Source Software in India know these names. They may not fully understand the depth of work or, the roadmap of the individual projects, but the name recognition is a jump-off point that should be utilized much more. For example, in a space like the College of Engineering Pune, which has a fairly active mailing list for FOSS related stuff, holding a 2 day event with the aim getting work started on new or, un-maintained activities, teaching the basics of testing/QA stuff would probably be more useful than just wishing about growing a community. I am fairly certain that there would be other institutions like CoEP where a day-long or, similar camps can be organized. Why aren’t they happening ? On that I have no clue.

Here is a question for the candidates.

To advance to the goal of freedom for software users, we need to develop good free software, and we need to teach people to value and demand the freedom that free software offers them. We need to advance at the practical level and at the philosophical level.

GNOME is good free software, and thus contributes at the practical level. How will candidates use the user community’s awareness of GNOME to contribute to educating the communityn about freedom?

“In what way would you ordinarily refer to “an operating system based on a Linux kernel and using mainstream, mainly community-developed components and applications”? (Distributions representing such include Debian, Gentoo, Fedora, Open SuSE, etc. Android does not qualify, nor does WebOS, etc.)”

If you like to see it translated in a language of your choice, sign-up here.

This year we have been able to reach out to a number of events and groups which helped us take the message of the Four Foundations to them. That has been good. We have also noticed that a larger number of those signing up to become Ambassadors are students or, are dipping their feet into the FOSS way of doing things. So, here’s the area in which we need to work our hardest.

Earlier I wrote:

Additionally, if during the initial days, the new Ambassadors are encouraged to actively participate in any other part of the project, it should lead to greater involvement and appreciation of the Foundations. This of course has the advantage of helping them build the social connects and network across projects/amongst individuals which is an invaluable part of being an Ambassador. It also builds up the required confidence in the Ambassador to go out and evangelize about contributing back to various projects and upstream. Because, if one has already drunk the Kool-Aid, talking about it is dead simple.

And, it is true. An Ambassador is the face of the project to the external world. It requires people skills but more importantly, it requires an intrinsic knowledge about the project that takes time and effort to build up. Unless an Ambassador takes a keen interest in the various projects within Fedora and, contributes to at least one of them, it is an uphill climb for most. More so for a student who is just learning the ways of FOSS and, gathering experiences via Fedora.

In the coming months, the plan is to put in place a stronger coaching plan for these student contributors so as to tap into their huge talent and, the capacity to produce stunning results. We have always been surprised by the sheer amount ideas that come up when students are gradually pointed to a direction.

Stay tuned. Exciting stuff is going to happen.

Talks have transcripts and, they are whole blocks of dialogue which have a different feel when undergoing translations than the User Interface artifacts that make of the components of the software I translate. In some kind of confusion I turned to the person who does this so often that she’s real good at poking holes in any theory I propound. In reality, it was my turn to be shocked. When she does translations of documents, Runa faces problems far deeper than what I faced during the translation of transcripts. And, her current toolset is woefully inadequate because they are tuned to the software translation way of doing things rather than document/transcript/pieces of text translation.

In a nutshell, the problem relates to the breaking of text into chunks that are malleable for translation. More often than not, if the complete text is a paragraph or, at least a couple of sentences – the underlying grammar and the construction are built to project a particular line of thought – a single idea. Chunking causes that seamless thread to be broken. Additionally, when using our standard tools viz. Lokalize/KBabel, Virtaal, Lotte, Pootle, such chunks of text make coherent translation more difficult because of the need to fit things within tags.

Here’s an example from the TED talk by Alan Kay. It is not representative, but would suffice to provide an idea. If you consider it as a complete paragraph expressing a single idea, you could look at something like:

“So let's take a look now at how we might use the computer for some of this. And, so the first idea here is just to how you the kind of things that children can do. I am using the software that we're putting on the 100 dollar laptop. So, I'd like to draw a little car here. I'll just do this very quickly. And put a big tire on him. And I get a little object here, and I can look inside this object. I'll call it a car. And here's a little behavior car forward. Each time I click it, car turn. If I want to make a little script to do this over and over again, I just drag these guys out and set them going.”

Do you see what is happening ? If you read the entire text as a block, and, if you are grasping the idea, the context based translation that can present the same thing lucidly in your target language starts taking shape.

Now, check what happens if we chunk it in the way TED does it for translation.

So let's take a look now at how we might use the computer for some of this.

I just drag these guys out and set them going.

Get them out of context and, it does make threading the idea together somewhat difficult. At least, it seems difficult for me. So, what’s the deal here ? How do other languages deal with similar issues ? I am assuming you just will not be considering the entire paragraph, translating accordingly and then slicing and dicing according to the chunks. That is difficult isn’t it ?

On a side note, the TED folks could start looking at an easier interface to allow translation. I could not figure out how one could translate and save as draft, and, return again to pick up from where one left off. It looks like it mandates a single session sitdown-deliver mode of work. That isn’t how I am used to doing translations in the FOSS world that it makes it awkward. Integrating translation memories which would be helpful for languages with substantial work and, auto translation tools would be sweet too. Plus, they need to create a forum to ask questions – the email address seems to be unresponsive at best.

In fact I wanted to talk with him about how massive the momentum built up by Transifex has been. Just two years ago, in 2007, Tx was a GSoC project within The Fedora Project aimed at looking at managing translations from a developer’s perspective. Today, it is a start-up which is hiring employees, relocating to newer offices, has a foot-print across a significant portion of upstream community projects and, most importantly, has clients willing to pay for customization services and, developer services. Tx isn’t only helping translation communities by allowing them to craft their work in peace – it is keeping developer sanity with the fire-n-forget model of the architecture. I hear that PulseAudio, PackageKit developers are strong supporters of Tx. That is tremendous news. The provocative nature of Tx is also based on the charm that it has been bootstrapped. That should provide hope to developers thinking along the “product” route.

I would say that these two years have done Dimitris good. His focus on the road Tx should take has become more vivid and, he has a deeper insight into the changes he wants to bring about via Indifex. There’s nothing more exciting than keeping a close watch on his team and his company for news that would come up soon. Tx is coming up with a killer set of features in the upcoming releases. That should get the attention of a couple of clients too.

Throughout the afternoon we ended up talking about getting youngsters up to speed to think beyond patches as contributions and, starting tuning their thoughts to products. Dimitris opines that patches are excellent jump-off points but in order to become a valuable contributor, one must start thinking about “architecture”, “design”, “roadmap”, “milestones” and all such issues that form part of the theory classes but never see implementation in real-life scenarios. In addition, there is also the need to inculcate the “CC thinking” in everyday work of creativity – be it code or, content or even be it hardware and standards (the “CC thinking” is a fancy short-hand towards thinking about Open Standards, Open Protocols and so forth. In a somewhat twitter-ish way, we compressed it to a meta-statement we both could relate to and agree with).

Dinner and post-dinner with a couple of us was another story. Having a bunch of hard-core “Fedora” folks in the room creates a passion. Sitting back to savor the flames of discussions and, interjecting with a leading viewpoint to keep the debate flowing is the best way to get action items resolved. Nothing wasn’t touched upon – from the way to get best out of *SCos to mundane stuff like getting feature requests into Tx, OLPC and Sugar, or, talking about the general issues within the IT development community in Greece. And of course, the frequent checks on Wikipedia to validate various points in the argument. We could have done with an offline Wiki Reader yesterday

I think I finally went to sleep at something around 0200 today – which is impossibly past my standard time. There are photos aplenty, though I don’t know who will be uploading them. There was food, there was coffee, cakes, and, there were friends – in short, a nice day.

Sometime ago, I was shopping for an off-line translation tool. I was fed up with Lokalize’s issues and, the fact that it wasn’t letting me do what I wanted to do at that point in time – translate. Additionally, I wasn’t in the mood to actually install a translation content management system to do stuff. Face it, I am an individual translator and, calling in the heavy shots to get the job done was a bit silly. So, I turned to virtaal. Actually, I think I was goaded into giving it a try by Runa.

Virtaal was, at that point in time, not really a good tool And, you can figure from the blog link above that I wasn’t interested in it too much. However, since I ended up giving it a chance (you cannot simply ignore a recommendation from her) I ended up running into two issues. One was predominantly more annoying than the other and, in effect was what was putting me off the tool. However, the developers took interest to get it fixed and, in the latest release have resolved it.

The other bug was resolved in an even more interesting way – over IRC with hand-holding to obtain the appropriate debug information and, then on to editing the file to put in the fix. At the end, the fix might be trivial. But the level of interest and care taken by the team to listen to their users is what makes me happy. In this aspect, the other development crew I can mention is Transifex. I haven’t met most of them and yet they keep taking suggestions, reports via every communication channel they are on – blogs, micro-blogs, IMs, IRC and trac. That makes them visible, gets them into the shoes of the users and, I am sure it earns them invaluable karma points.

Yesterday, while helping (I just did the file editing while Walter did all the brain muscling) to close the other bug, I felt incredibly happy to be part of a system where it isn’t important who you are or, where you are from. What is important that you have a real desire to develop better software and, make useful artifacts for all.

As it goes – “Your mother was right, it is better to share” link to video.

The post is brought to you by lekhonee v0.8

An immediate benefit of any project participating in the Summer of Code is the ability to get exciting extensions or, innovations via a group of highly talented individuals – both mentors and, contributors. Having had the opportunity to look at the projects from fairly close quarters over a period of years, there are a couple of things that stood out. Some of them are listed on my wiki page. I’d say that the most important thing is to “have a plan“. A stage of proper planning which sets the expectations and deliverables for a GSoC proposal goes a long way in becoming a successful proposal. That, coupled with a scheduled update-review cycle makes it a proposal that has a constant communication channel. I was reminded of the this fantastic mentoring how-to today while reading the latest issue of The GNOME Journal (as an aside, you should read this issue).

If you look at the wiki page I pointed out earlier, you’ll note that I mention an “annual round-up”. This by itself is very trivial to do and yet very important.. It provides an yardstick by which to measure the success or, failure of a GSoC experience of being able to generate sustained and relevant participation. For example, if projects did more of this kind of “where are they now ?” series, it provides upcoming and potential contributors with role-models they can look up to or, be like.

That single act of being able to have role models makes for a tremendous motivation to become a sustained contributor to Free and Open Source Software.

At some point in time I should start getting familiar with the JOSM application and, upload the logged data using the script here.
For now, it is great fun.

The post is brought to you by lekhonee v0.7