A post of no importance

In recent times I have blogged about ‘non community based approach to l10n‘ (mail from Gora Mohanty). There is a particular mail on the gnome-i18n mailing list that provides some inputs towards formulating a plan on avoiding such repeat incidents. To quote:

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

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

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.

It only gets funnier…

I had mentioned Baishakhi Linux in passing in an earlier post. So, today a few of us received an interesting mail from Prof Anupam Basu of IIT-Kharagpur. The original mail is here for ready reference as it is at here. And I have a few points to make which are below. I will abbreviate Prof Anupam Basu as PAB and my responses as SM.

However, at the outset, let me state that it seems that the team working on the project can do well to buy copies of Karl Fogel’s excellent work Producing Open Source Software.

PAB: The release was on the 8th of September and it was planned to make the source code
available upstream, within a few days as is expected of open-source activities.
Please keep your weather eyes open on the SNLTR site.

SM: I recall asking twice about this and, this is the first time we hear about plans
to make source code available upstream. However, it isn't upstream source code that I'd be
interested in. I'd be interested in having access to the source of the distribution itself.

PAB: Mr. Toshi Kubota (mail cc'd to him) is a pioneer in Open-Source and Linux related
movements in Japan. We will ensure that all gpl requirements are adhered to in accordance
with his guidance. Please note that the inauguration was only day before yesterday !!!!

SM: This is what is generally called a straw-man argument. If you note, at no point have
any aspersions been cast on the level of expertise, or, competence of Mr Toshi Kubota.
Instead, what has been asked is a simple question - why have the translator credits been
mangled in the headers (that have been obtained from the .mo files) ? For instance, I don't
recall Promathesh Mondal following any of these steps.

PAB: I know ( because Indranil Dasgupta himself told me on the first day we were discussing
and demonstrating a prelim version of Baishakhi Linux) that the existing Linux versions,
printout of complex Bengali scripts through Firefox was not possible - thanks to Indranil -
this problem is not there in Baishakhi Linux.

SM: If you could point to a suitable sample of such complex scripts I'd be more than glad to
test it out on Fedora9 or rawhide -> Fedora10. As on date, I am yet to see on the Firefox
bugzilla a bug from your team that provides specimen cases that drive home the point that the
complex script rendering is an issue on Linux.

PAB: The contributions may be incremental, (as suggested by Sayamindu - a one line code), but
that is there now. Baishakhi Linux need not make tall claims, it was a very low budget effort
and the spirit should be to contribute more by pointing out bugs and improving on it.

SM: I read two things from this: [i] the distribution does include the one line code that
Sayamindu points out ie. it isn't materially new and [ii] none of the fixes that Baishakhi
claims to be 'features' have the patches attached to the already existing bugs in upstream

PAB: I am pained because my invitations to some of the Open-Source groups to join hands in
these activities was met with absolute silence.

SM: 'Let us be objective first' (quoting you) - who are these 'some of the Open-Source groups' ?
And, when you invited them, did you point out the mode to join and contribute ?

In short Prof Anupam Basu, we met around a year plus back at the ‘Bangla in e-Governance’ meeting and even then I had taken time to ask you to work with our group to push all the work you do into upstream. Not surprisingly, it hasn’t happened. I don’t expect it to happen as well – but your mail was something of a surprise. More so, since you chose to include Sayamindu’s mother in cc: – what were you thinking ? đŸ™‚

Sayamindu has a response as well.

Rewards and Punishment

Traditional concept of motivation (here is a link) hinge upon the crucial concept of ‘Rewards’. Generally, a reward is a tangible object that is presented after the occurence of a particular set of actions, generally positive. The aim is to ensure repeated occurence of the similar action. Rewards are supposed to be more effective if presented in the immediate aftermath of the ‘positive’ action rather than after a time-gap.

I have always been a bit ambivalent towards ‘rewarding’. The underlying cause is because I tend to view rewards as ‘controlling knobs’ in the same category as Punishments. So, for example, a punishment is a deterrent action that is meted out after the occurence of a particular set of actions, generally negative and undesirable. The aim is to prevent repeated occurence of similar action. Thus, by a not-so-long-chalk, rewards and punishment are two sides of the same coin in the realm of motivation. I don’t like ‘controlling knobs’. To me, they appear as artificial constructs that are unnatural. However, the most important annoyance that I notice is that for both the reward-giver and the reward-taker, they have a tendency to become addictive and habit forming.

Now nothing is wrong with doing good work repeatedly and getting appreciated for it. That happens everyday. The implied danger is that rewards, since they are ‘controlling knobs’ tend to provide incentive to positive behaviour. And, lack of the rewards, in many cases (that I have noticed) tend to not produce the same quality of output as compared to when rewards were announced. For long, the necessity of rewards have been put in the context of Maslow’s Hierarchy of Needs or in the context of hygiene factors. Either way, from a personal interpretation of the theories, rewards should not be mixed up with ‘fringe benefits’ and thus form part of the ‘hygiene quotient’. In a fairly complex (but not subtle) way, rewards tend to be reductive of the work done. Think for a moment how often we hear the word ‘awesome’ or ‘cool’ or even the phrase ‘awesome coolness’ (or their cousins). Overuse and over extension of the concept of cool results in the relativity of an unique work being lost. Rewards, I think, tend to be similarly reductive.

Quoting from a book by Alfie Kohn:

Managers do not motivate their employees by giving them […] or new status symbols. Rather, employees are motivated by their own inherent need to succeed at a challenging task. The manager’s job, then, is not to motivate people to get them to achieve; instead, the manager should provide opportunities for people to achieve so they will become motivated.

So, it could appear that the actual catalyst towards achieving motivation is providing challenges. In fact, adding choice, collaboration and creativity to the already present concept of challenges could be a potent mix towards achieving an ‘engaged workforce’. In a nutshell, the problem that I have with rewards can be summed up as:

  • rewards tend to be an implicit punishment towards those who did not receive a reward
  • rewards tend to get people to do uninteresting things by providing a wrong kind of incentive
  • rewards tend to be habit forming
  • rewards tend to discourage collaboration (since generally, in the end there is a single winner)
  • rewards tend to discourage risk taking choices (since rewards are for repeat occurence of one single good habit)

I don’t have an answer or an alternative in a way Alfie writes in his articles. However, given that any organization desires to have smart people blowing away challenges through creative solutions, I don’t seem to buy into the idea that constant rewarding is the way towards getting things done.

How to get your translations/localization contribution integrated with existing communities

I happened to re-read this fine piece of penmanship today. And in the light of recent incidents figured that it would not be out of place to muse about a few small steps that can get localization contributions integrated with existing communities.

Some preliminary definitions should set the context for the post:

  • Upstream: the catch-all term for the ultimate source of the project – a place where the core contributors put their work into the version control infrastructure and other related bits like bugzilla/issuezilla etc come together to provide some ‘dashboard’ view of the project. In the context of localization, it usually points to projects like GNOME, KDE, Firefox etc whereas distributions like Fedora, Debian etc are considered ‘downstream’
  • Communities: existing special groups, generally organized around locales who handle the translations/localization of content for the upstream and downstream projects
  • Contributor: in this particular instance it would be the person who has demonstrated interest in contributing localization work for the particular language community

Now comes the short and sweet list of things ToDo:

  1. Discuss and declare your intent to contribute in a public forum – the teams working on l10n are pressed for time since they have to juggle around the string freeze deadlines for a variety of projects. And, since most teams / language communities are made up of a small number of people, there exists a tacit understanding towards tasking. Discussing the intent to contribute in any of the public forums makes it easy for the members to allocate tasks to you
  2. Study the community – most of the members for the language community have been working together in tandem for a long time. Thus, they have a well oiled mechanism to handle the deadlines of the project. Studying how the members interact over mailing lists and / or IRC would provide pointers as to what could be construed as constructive and what is ‘being smug’
  3. Contribute work incrementally – it is always better to start off with small chunks of localization content. That allows the members to review the work and provide pointers in addition to that being a ice-breaker
  4. Acknowledge reviews – the language teams have in-place language consistency standards, processes and guidelines. Acknowledging the reviews and incorporating elements from such guidelines makes for better working relationship
  5. Review work before submission – this shows that you care about the quality of your work and take pride in being a part of the team. The small bits that are required to be reviewed are generally constant and can be converted to a check-list
  6. Update your work status – that helps the ‘leader’ of the language team to assess progress of work and also put in place small tweaks towards meeting deadlines and goals
  7. Get legal clarity – if your employer / employment contract requires you to use a particular ID or provide some extra credit, please ensure that this is discussed upfront with the team and all issues are discussed towards mutually agreed upon clarity
  8. Learn the basics – take time to learn the basics of
    • Version Control Systems of the upstream project(s) you will be contributing to
    • Usage of IRC
    • Usage of mailing lists
  9. Expect and accept rejection – there may be multiple reasons as to why your intent to contribute to a particular project may be rejected. And instead, you could be pointed to some other project that the language team is also working on and asked to contribute. There could be number of reasons for that. Expect such events and accept them.
  10. Being a good contributor begins with being a good citizen (a phrase I borrowed from Pradeepto). And, that starts off with small steps.

    [Thanks to Richard W Jones for his initial page]

What a waste of talent and money…

These days I am generally averse to government sponsorship of (aka investment in) Open Source, especially if the government in question happens to be the Government of India.

I had earlier blogged about BOSSLinux and in recent times I tend to abhor politically motivated over-the-wall Open Source on taxpayer money. For example, take a look at this cache.This is the collection of over-the-wall translations of GNOME files. The fun part is that language teams exist for a significant number of the languages that are part of the collection. And yet, the files have the curious header: “Language-Team: Bangla (INDIA) (info.gist@cdac.in) \n” for bn_IN example. I don’t recall anyone contacting the group working on bn_IN for this and coordinating the work in that community. The discussion over the past few days on #indlinux also shows that the ml_IN community has not been contacted, neither the or_IN.

The reason why C-DAC desires to undertake this nonsense is fairly clear. Currying political favor with the incumbents at ministries, re-inventing already undertaken tasks is something that the stellar agency is becoming excellent at in recent times. Language computing in India is a big ticket item. Various e-Governance projects are looking towards reaching out to various language communities for greater outreach. There is work going on in standardization and so it is a good time to start acting silly. For a few languages that don’t have all the Unicode issues resolved, there seem to exist translations. Amazing is what it can be called. Why would working with the communities in the form of collaborating be something that is beyond the intelligent folks at C-DAC is what bothers me. These folks have been around for a while ie. they are not newbies starting up a project, they are smart. So, if they are upto such stupidity, there has to be a reason to this madness. Trying to fork translation communities instead of collaborating is a sad way to move forward.

Moving on, let’s take another piece of oddity. Baishakhi Linux which says:

Society for Natural Language Technology Research (SNLTR) developed Baishakhi Linux 1.0 (pdf link) in collaboration with MAT3 Impex and IIT Kharagpur. This is a free Bangla Linux that has been built over Ubuntu 8.04 distribution. All computer related decision making and office activities, such as document writing, preparing presentations, web browsing, sending and receiving emails as well as spreadsheet calculations can be carried out in Bangla using this distribution. All Bangla compound words can be viewed and written in Baishakhi Linux, and this special feature distinguishes it from the other localized Linux distributions. Even in spreadsheet application (an office suite for calculation) all types of mathematical calculations (addition, subtraction, multiplication, division etc.) can be done in Bangla including fraction number, which is also a unique feature of this distribution.

The bits that are termed as ‘salient features’ have not been contributed upstream. What a waste.

ps: If this bug gets closure, a lot of issues would be resolved.

Good things happen when good people come together…

The Durgapur Linux Users Group or dgplug started around 5 years back when Kushal and few of his friends got together with the usual aim of creating a group of users of Free and Open Source Software. It wasn’t an unusual LUG. At that point in time there were a number of such groups forming all over the country. Kushal and his friends took the well beaten path of approaching schools and colleges, helping set up install fests, guiding a few students in their projects. Sometime around the beginning of 2006, they registered #dgplug on Freenode. Even this was a known way of going forward. A lot of LUGs in India have their own (and perhaps registered) IRC channels. However, things did change from here onwards.

As per the current system of education, students of engineering (especially Computer Science and Information Technology) have to undertake a mandatory period of summer training. While the regulation was with all good intent, the side effect has been the exploding growth of ‘infotech’ houses which offer such training to the students at a cost. The current rate in West Bengal is around 3000 – 6000 INR per student. The students don’t really ‘learn’ anything at such places. They pay up the fees, meet with fellow students and at the end of the duration of the training obtain a ‘certificate’.

So, the #dgplug folks, largely led by Kushal figured out that a far better approach towards training could be undertaken if the training went ‘virtual’. Thus, IRC was chosen as the medium of communication and a ‘Summer Training’ curriculum was drawn up. Blogs and word-of-mouth was used to let students know about this. Not surprisingly, a large number of students signed-up to be part of this somewhat experimental training program. Experimental because, although a few FOSS projects do have regular classrooms, they are mostly focussed on specifics of the project and don’t blend with the curricula that the students would be familiar with. #dgplug also signed up a fairly impressive cast of mentors who could guide the proteges into the world of FOSS and especially coach them about how to become involved with various communities and sub-cultures that exist.

Since the mentors are from across various timezones, keeping the classroom virtual has worked out really well for both the protege students and #dgplug. The medium of IRC also allows transcripts or logs of the meetings to be archived for easy reading offline. The method is elegant and simple. The mentors pick up the topic and hold a classroom. They also provide homework to the students. The content of the homework is not something that can be copied from existing documentation, but requires some amount of original thinking. After the students learned about version control, the answers for the homework went into the training repository of #dgplug at http://dgplug.org/training/

At the end of the training, the students are expected to undertake a project for an existing FOSS community and submit it to the respective upstream. Pretty neat.

So, all this ends up achieving something significant. While this is a small beginning with a group of students and mentors, it does prove that IRC can be used to coach and mentor new contributors. And, it also provides some empirical evidence that coaching in FOSS need not be outside of the existing academic curricula. It can start from within and slowly gather momentum to bring about substantial changes. Even earlier, small study-group like environments to teach GNU/Linux have met with a reasonable amount of success viz. GLT-Madhyamgram, having a lot more training on #dgplug from mentors willing to contribute a small portion of their time would lead to impressive results.

Durgapur may be a small speck on the map of the country, the IRC channel #dgplug and the screencast channel surely isn’t. Not with a number of GSoC candidates from the region. And certainly not with the amount of activities that it conducts.

Update: If you are interested in becoming a mentor to a new batch of students and guide them towards contributing to FOSS, please join #dgplug on Freenode.