In contrast to the well laid out elaborate discussions about meeting date and time yesterday’s meeting on #indlinux had a stand-up feel to it. The raw logs have been made available here. While the aim of the meeting was more to figure out what is stalling the forward progress of the “IndLinux Society” the secondary objective was to figure out the “organisational structure” that could be adopted. I got busy sometime into the meeting and so here are a few thoughts on hindsight.

To begin with (even before we go into structure issues) it is important to figure out what IndLinux wants to be. Around 2 years back the goal was to be the “upstream” in all-matters-Indic for distributions alongside other objectives. 2 years down the line that idea really will not fly. The distributions have put in place their own workflow as have the various projects and imposing an additional element in the workflow would meet with a small amount of hassles. A very casual way of handling this would perhaps be through progress tracking how Indic is faring across projects and distributions – an automated process similar to the “Damned Lies” would work well when hosted on the IndLinux Server.

The broad objectives of the “IndLinux Society” (?) were already discussed and agreed upon. So moving forward the thing to consider for IndLinux might be how to create a “stack of applications” on top of the in-progress localised desktop and move towards solving issues that are not being currently addressed by various upstream projects and distributions. These could relate to fonts and specifications, publishing/DTP, spellcheckers and word corpora (collaboration with existing bodies who have the work done and releasing them under appropriate licenses), OCR, AT-SPI bits. All these are sub-projects which have to be mapped to the objectives and then further on made more granular through task-based breakup and milestones. Milestone creation would allow the tracking of the project and arriving at a conclusion on the success or failure of the projects. Additionally, it would also equip IndLinux once the “body” is formed to participate into a Summer of Code like program and offer projects based on these goals.

Additionally, it would be a good time to look for staffing the project with the main aim of putting in place a metrics based system. The immediate need would be for the following: Project Manager (initially also someone who can coordinate with the companies doing Indic in India), Community Engineer (in order to get more developers to commit code) and a Server Administrator. Given the broad objectives of the project all the 3 positions should be made accountable to the project and these should be paid positions with remunerations in place. At this stage it may seem funny (or even nonsensical) to be talking about staffing and monies, but it would help a lot to be prepared and be aware of what the scaling up would require and mean.

As regards a legal body and the form it can take I’d rather say one starts looking at these folks. It is a working model that provides a good public private collaboration and if it works for them there’s no reason why it should not work for IndLinux.

Just in case you were wondering, here are the numbers.

For those of you who don’t visit the site, the iLUG-Cal wiki has a proposed FOSS Certificate Course drawn up largely by Pradeepto. The content is kept intentionally general so as to enable the cultivation of the basic hygiene of FOSS. There’s a subtle difference between programming in FOSS and making FOSS a practice or, as someone said “a way of life”. The course is aimed more towards the latter than the former. So, if you don’t want to go clicky-clicky on the above URLs here’s what the structure looks like:

[1] Programming - How to program? Note : Not specific to any language of the day or the latest buzz word. (40 hours)
* How to Design Programs - some elementary ideas
* Elementary Programming Best Practices
* Constructs and Structures that are part of everyday programming
* Collaborative Programming Practices
* How not to program?
* Choice of Programming Languages
[2] Version control. (6 hours)
* First, Second and Third Generation of Version Control System
* Introduction to Version Control as a workflow
* What are the fundamental aspects of setting up a Version Control System
* Examples of various Version Control System
* Setting up and Administration of a Version Control System using either CVS or Subversion
* Becoming aware of the developments in Version Control Systems - follow the commits
[3] Bug tracking (3 hours)
* Various Bug Tracking Tools
* How to report a bug
* How to follow bug reports
* Setting up a method to track bug reports
[4] Collaborative ways - mailing lists, irc, wikis etc.(Handout) (15 hours)
* Participating in collaboration
* Best behaviour on mailing lists
* Best behaviour on IRC
* Netiquette
* How to work with wikis
* Setting up and Administration of a wiki
* Content on a wiki used for brainstorming
* Overview/General introduction on documentation, testing and localisation ( and tools involved in each of the process )
[5] Day-to-day Linux(y) stuff - Bash [this should be a compulsory part of the course] (25 hours)
* Preliminary system administration
* Troubleshooting issues
* Network
* System
[6] Introduction to Bash scripting. (18 hours)
* Becoming Comfortable with Bash scripting
* Using Bash to complete system administration tasks
[7] FOSS : Licensing, copyright and patents. (8 hours)
[8] External Reading
[9] Project (appropriate bits from an upstream project) - (30 hours or more)

I am informed that Mrugesh is also doing up similar stuff for the NRCFOSS node in Mumbai. That’s good news. What is excellent news for the course is that there are identified folks who are keen to deliver content which is already present in a cohesive format. A discussion late last night on IRC also came up with the idea of coaching the participants in Bug Triaging/Zapping as part of the course. A very basic approach to this would be to set up a machine that has the “devel” builds for the Operating System, the applications and the desktop environment and allowing the participants to reproduce upstream bugs for the userland to get a feel of what proper bug reporting would be. Now a small percentage of the bugs would require fancy hardware or extensive knowledge – but a large percentage of them would be nicely handled/triaged if the coaching is on-the-mark.

The single most important thing that is happening is that the “commit to mailing lists” is being slowly but surely replaced by “commit to tasks”. One hopes that this will lead onwards on to “commit to upstream projects” and the hype over the Google SoC regarding the number of participants from India will be justified. Although it would be best served if all the aspects of FOSS are taken care of. “FOSS” as an word is constrained to “software” and even though the notion of “free culture, free knowledge” is talked about it would be good to see some action on those fronts too. There’s a large amount of work (and this is heavy lifting) that needs to be done in the areas of Open Access, PLoS, SELF Project

There is a need to talk about the MIT OpenCourseware bits and figure out how relevant parts from them can be integrated into the syllabus.

The mandatory post this time. There are a few openings in the Software Engineering (i18n and others), Quality Engineering and Language Maintainers (Telugu and Marathi). All the openings are based out of Pune, Maharashtra, India. While I’d really love for folks to apply online through the Career Portal (use India as the option in the drop-down list for the country) in case you don’t really get to the page mail me your CV in Open Document Format at sankarshan {dot} mukhopadhyay {at} redhat {dot} com with an appropriate $SUBJECT.

Additionally, there are a few emerging groups who are yet to put up their requirements but will do so soon. So, if you are a developer and have upstream contributions (userland, kernelspace, applications, whatever), would like to work at Red Hat, do drop me a line at the above e-mail address and I can pass this news to the relevant hiring managers and we can get down to an informal chat to figure out what would work best.

Note: The above is besides the open positions in Support Services (based out of Pune) and Professional Services (based out of Mumbai and other cities) for which I have already posted on various mailing lists. The positions for Support and Professional services are also available from the Career Portal.