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.

At some point in time during the week, I’d put them in the tickets as feature enhancements. However, for the time being, here’s a couple:

• Lotte should allow me to click on a file that is not yet translated for my language and, add it to the collection. If I recall correctly, the current way to add it is to download the .pot, convert to the appropriate .po and, upload it with comments etc
• Lotte needs to allow “Copy from Source”. This should accelerate translation by removing the extra step of having to actually select, copy and paste. This comes in handy when translating strings within tags or, brands/trademarks and so forth
• Handling and using translation memory could be built into Lotte. For a particular file in a specific language within a project, it could perhaps provide suggestions of translated words. In the future, allowing teams to add their glossaries would make it a more powerful tool too. Having said that, I’ve always wondered what happens when team glossaries are created from files across various projects – is there a license compatibility soup problem that could crop up ?
• A Transifex installation could provide notifications of new files or, updated files for the language. This could be limited to the files for which the last translator is the person receiving the notices or, ideally, could be for the language itself.
• Statistics – providing each language a visual representation of commits over time or, per contributor commits would also be a nice addition

So much for Transifex, in fact, I need to write out all of that in a nicer way so as to allow the possibility of these turning into GSoC projects within Transifex.

Coming to Virtaal. With lokalize being unbearably useless for me (it adds garbled text or whitespaces into files when using the stock F11 supplied one) and, before it is commented, no I haven’t filed a bug yet, getting the files done was a bit more important at that specific point. So, mea culpa. But I do check with every yum update and, it is still the same. The specific issue with Virtaal is that each time one gets a new string loaded for translation, the text input area loses the input method details. Which means that it is a constant game of switch back and forth between the inputs. Sadly enough, this is the only software that currently works for me (I don’t want to set up a local pootle/transifex instance and, do web based translation)

I finally managed to add it to my Safari Bookshelf (for some odd reason I had to delete a book to free up a slot inspite of not being over quota) and, I did have high expectations from it, Jono has been active and visible in various communities and, I expected his enthusiasm to reflect in the writing. The book is a good one and, definitely worth a read. Interesting chapters are: Building Buzz, Measuring Community, Handling Conflict and, Hiring a Community Manager. A couple of observations about the book:

• it draws on the shared experiences and, “stories” from various personalities and, projects making it somewhat of a “comfortable” book to read. You get to see that there are patterns to the problems across various communities and, tribes and, such patterns can be addressed
• it isn’t “preachy” or, prescriptive or, even full of homilies. That’s a saving grace really. However, the deliberately chatty nature of the book sometimes becomes a bit too full. However, not mandating prescriptions to “fix” communities is a good thing to have in a book
• It does have the usual attempts to define what a community manager does (including the by now cliche of “herding cats”). The end definition is somewhat more easy-on-the-ear (read the book for that :))
• it doesn’t delve too much into the measurement aspects of the vitality of a community and, somewhat implies that the entire effort to build up and, sustain a community is somewhat of a “soft” skill issue. That, I’d say goes against the grain of the intent of the book – to demonstrate the easy of formation of communities and, the significant efforts to keep them sustained. And, although the anecdote about the 5-A-Day is insightful, on the whole, it doesn’t break new ground in statistical assessment or, deriving sense out of the number crunching
• I’d have liked to read about examples from upstream projects like GNOME, KDE and, Mozilla. Because of the size and, nimbleness of their releases, the community experiences would have far more anecdotes about processes, tools and workflows. The book does justice in talking about the importance of having open and transparent processes, however, it doesn’t delve too deeply into the catastrophic failures that can happen if the vital emotions of Belief, Respect, Accountability and Trust are thrown to the winds. There have been ample cases in the world of Open Source where one or, all of the foundations have crumbled and, havoc ensued. Dispassionate discussion about them helps bring out the case for the need to have a vigilant community.
• I recently read Cultivating Communities of Practice by Etienne Wenger, Richard McDermott, William M. Snyder (linky) and, expected The Art of Community to demonstrate the validity of legitimate peripheral participation in the Ubuntu community. There aren’t too many examples of those.

In short, although the books falls a bit short of my expectations, it is a good read and, a book to have on the shelf. It does not lend itself towards creating neat little check-boxes like, say, a Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel (linky). Or, it isn’t aimed for companies who want to build a community around their products/services as is documented by Dave Neary in his blog.

On a related side note, the other books which I read and, would recommend are: 97 Things Every Project Manager Should Know, 1st Edition by Barbee Davis (linky) and, 97 Things Every Software Architect Should Know, 1st Edition by Richard Monson-Haefel (linky). Both are extremely nice read especially because they have a diverse range of inputs which make it topical. There’s a need for a 97 Things Every Community Manager Should Know as well

Lastly, it would be delicious if the Safari folks allowed the bookshelf to be treated like an actual library bookshelf – check-in and, check-out books at will as opposed to waiting for a specific number of days to be able to remove the books. Oh well ! you can’t have it all I guess.

Some of the common aspects of the texts I have stumbled across include attempts to have a model defined, description of a rudimentary framework of tasks, an analysis of infrastructure that facilitates collaboration and, a broad overview of the character of a community. Either way, I am a bit tired about “community” as a word and, I feel that it is beginning to suffer from over-use and under-statement. A primary driver for that feeling is the tendency to look at “communities” as if they were thriving specimens on a petri-dish, isolated and unperturbed in their own imaginative evolutionary cycle. That is simply untenable as a hypothesis and, impossible in real life. Communities are constituted by groups of people and, people react to the push-pull of daily life around them – the political issues, the personal issues and, the social intricacies. As much as communities try, other than a basic tenet that binds them together, there isn’t much difference between the growth of a community and, the evolution of family. The same basic principles of Belief, Responsibility, Accountability and Trust ensure that the forward momentum is not stalled.

The paradox is that having stated the above, I ended up attempting to box-in the “community” into some nice tangible parameters so as to enable explanation. Fun !

The decline of a community or, even a sub-aspect of a community can also be traced to a larger sense of hubris and, a lack of plan in terms of moving forward to embrace change. The hubris part is perhaps derived from moving away from a central core idea that was the genesis of the community and, attaining a false sense of being indestructible to external forces. Statistics are important – but statistics are external representations of symptoms – for example, wiki edits; commits to version control; activity on mailing lists; number of contributors; mass of consumers all these indicate how the community (or, tribe) is moving forward. They do not capture whether the general direction is based on the central core theme and, is moving across a wider spectrum without getting too diluted.

Why can’t “communities” be replaced by “tribes” ? Makes for a better understanding of the complexity of interaction that ensures a sustaining environment for a group of people who perceive a need to exist. And, would be able to come together to arrive at decisions that ensure sustenance. Most communities/tribes are specialized formations of people who find a common space to talk about and extend their areas of interest. As such, the need to “fabricate” a community is somewhat redundant while the need to work on providing a “commons” is important.

ps :The post is rambling in essence, at some point I’d like to re-visit this and, collate the other thoughts.

The post is brought to you by lekhonee v0.4.1

One of my colleagues had the following to say about OLPC in Nepal:

“Nepal has had perhaps one of the most active grassroots OLPC community, that became active in the fall of 2006. The OLPC Nepal movement has needed to develop its deployment plans, school server architecture, and strategies of interfacing with government. The most active members of the OLPC community within Nepal formed a local non-profit organization in July 2007, OLE Nepal, to implement Nepal’s initial OLPC deployments. All of these became the exemplars for later deployments ..”

What has prevented the development of such a movement in India? Bangladesh? Srilanka? Pakistan? Bhutan?

The fun part about this is that there is no single silver bullet response. A primary issue with the effort around OLPC in India has been the lack of investment in building up a community around the project. While there has been breakthroughs around the deployment and proof-of-concept runs, there hasn’t been a single sustained thrust in ensuring that there is a buy-in with a larger group of people who contribute. Which means that while there are significant areas where OLPC could do with community love, there hasn’t been any plans made in public on them.

A much secondary issue is the lack of clarity about who is OLPC in India. For a certain period of time, any OLPC related issue was discussed with the team handling the Khairat pilot. Moving on, there exists a lack of structured information about how the organization plans to work – what the plans moving forward are and how it plans to attract volunteers to the cause. Scaling up the deployments and notching up the numbers is a measure of success. Another yardstick is how much of interest has been developed with newer contributors.

CDAC is a government funded agency and takes up projects from
Government which are based on deadlines which are sometimes strict and
harsh. We work towards deadlines and are answerable to the funding
agency on things we commit. Localisation activity happens to be one of
them.

I tend to hold on to the theory that both the distributions in essence (BOSSLinux and Baishakhi Linux) should be no different that other Linux distributions who work ‘within‘ the community in harmony and collaborate to innovate. Expanding on what I already wrote about working with existing L10n communities, a means to make this possible is to have a release plan available for public view. All the major distributions have a release schedule available in public and an immediate effect of this is that it makes it possible for potential contributors and existing communities to comprehend how the pieces fit in.

Having a release schedule also makes it easy to assess how much work would be required to be put into localization of a particular language, since the components of the distribution in terms of GNOME/KDE/Xfce etc would be targeting a particular release of the desktop environments. The bits that are specific to the distribution viz. installer, configuration toolkits can then be done by the team in charge of the distribution or, the community around the distribution. Taking an example nearer to home, there is much to learn from how to work ‘in’ the community if one takes a long hard look at how Fedora operates.

The reasons that the community got lumped with a huge load of translated files was that there was a lack of communication and synchronization with the folks doing L10n and there was a lack of transparency in the infrastructure that produces the distribution. These are not insurmountable problems, but these are required to work within the community and collaborate to produce high quality of Free Software.

Here is an organisation which is willing to make crucial contributions
to the community at its own defined speed. I would want to believe
that this is one of the larger contributions any government agency has
made to the localisation efforts. Government has its interest in the
effort and so has its own temporal goals. We need to meet those goals
and so sometimes we need to take a path which satisfies our funding
agency.

Every distribution has its own defined velocity of releases and logic of cherry picking components from upstream to integrate. Taking a path to satisfy the funding agency should not be at odds with the community at large within whose framework the work is being undertaken. If, they are at odds, it is the onus of the Program Manager for the distribution to talk with both the funding agencies and the community towards providing accurate and transparent communication.

Should a major chunk of contribution go unnoticed just because we did
not satisfy the egos of those in ‘power’?

In the realm of FOSS, contributions are not merely contributions of code or content. Contributions define the nature of the group that is contributing, and, whether they desire to learn about the civic rules into which they desire to integrate themselves. Through learning comes awareness and via awareness one transforms into a good citizen in the FOSS world.