I wrote as:

Is this the right approach ? Perhaps not. This approach or offering is based on what the developer world makes of the requirements and the processes of the academic world. And in a way that could turn out to be dangerously skewed. Till date, at least for India, the developers have not really sat across with the academicians and educators to question them directly on what they want the software to do, how they want it to behave. I guess the time has come for us to do that. Just imagining (or assuming) the requirements and then trying to figure out the best possible pieces of the puzzle that will complete the jigsaw will only see FLOSS lose credibility.

A friend called up to ask if after all these years I was advocating a Top Down model. I would like to clarify that. Yes I am advocating the Top-Down model. When designing and engineering for the education segment, the Bottom-Up model is too sketchy in terms of information flow to come up with something that is worth delivering.

Case Study: A higher secondary school does not have a well defined IS process flow. The board wants to streamline the operations by adopting FLOSS and thus getting ‘value-for-money’. The school functions over 3 distributed premises with no interconnectivity.

Design the solution for the school using both the models and figure out for yourself.

Dave Neary writes about the reduction in the GNOME Foundation Board petition. As you might see from the second link, an impressive all-star cast is supporting the petition. Honestly, I am in two minds about this. What ails the GNOME Foundation is not a top heavy structure but a lack processes. Let’s face it, the Board is a volunteer driven body. And the only means of extracting work from such a body is putting in place clear responsibilities. If I were to list the changes that need to be put in place (assuming that I am not advocating the reduction in size), they would be:

1. Designate areas of operations for the Board Members
2. Provide an adequately reasonable and comfortable response time-limit to questions
3. Create a fallback mechanism for questions related to GNOME branding
4. Have the roadmap information shared on a regular basis

The Board spends far too much time over issues related to GNOME branding, trademarks and licenses and too little time over how to make GNOME PR more layman friendly. And the lack of a structured decision making process hurts. Once issues start getting entangled in what seems like give-no-quarter mail bombs, the motivation to work goes out of the window. I see the Board as a decision making body which delegates authority to members for execution of tasks and then tracks the efforts in terms of effective execution. Currently this is not happening. Will a reduction in the size help ? I am not sure of that. The pros are that it will result in a lesser number of people taking time to decide upon an issue, but it does not really ensure that an issue will end up being resolved. What might be more effective in the current situation is functional distribution – allow people to take up specific responsibilities, make the ‘go-to’ names public and wait till the next release to see the results. The cons in the petition is that if the constituents end up from being situated across disparate timezones, the decision making would seem to take recursively long.

So, where do I stand ? I don’t know. Will think over this again through the weekend and perhaps Monday would be a best time to blog on this.

Take a look at egyan. This is an online record of the development and enhancements being carried out on Moodle bye FiveSpirits. Some weeks back I sat through a presentation by them on why they chose Open Source as a way to complete their term projects. While they are in the infancy stages of doing stuff with Open Source tools, their enthusiasm was infectious in terms of sharing their experience and rush of working with Free/Libre Open Source Software. Their project can be summarised (without giving much away) as making Moodle fit in more with the Indian university pattern of education and course content. Involving the re-doing of the grading system and making the loading of content easy, it also involves localisation. You might want to register at the site as a Beta Tester.

Some posts back I had ranted about customer delight, today the Brand Equity section carried something that fits in nicely what customer angst is like. Based on premises drawn from Paco Underhill’s studies, it talks about the customer care or lack thereof at our urban malls. This can be seen in the way FLOSS business currently works in our country. The developers who dare to cross the chasm and make a business case out of their ideas end up cultivating a take-it-or-leave approach. There is no sincere model towards understanding the requirements of the customer. The mental model of the customer is never really taken into consideration. This is the reason why I feel that software like Gobby would find it hard to be appreciated. I just tried it out – and boy does it deliver ! Until and unless one understands at least to some completion why people use desktop it is not much use fiddling around to provide a working desktop. A desktop should perform and function flawlessly providing the easiest possible means towards accomplishing a task. It should rise beyond mere working.

The hosting space suffered a Denial of Service (DoS) and all bandwidth was exhausted. After some talks with the provider we are up again :). Yeah…

Read this to begin your day.

A line from Atul’s diary struck a chord – What’s so cool about free software ? . Till now all the activity that has been done across the country (the roadshows, the install fests, the demos and the LinuxAsias) have been based on the premise that FLOSS is cool and the devotees will flock to the temple. When we talk about FLOSS in education, perhaps it is worth a second look towards how we go about it ?

Educational institutions are about service delivery. Forgive the crude way of putting it across, but if you strip away all the frills – you get service and the branding that the institutes obtain could be the quality assurance tied in with the delivery of such service. In such a situation, creation of a matrix of FLOSS around the system would be a bit more complex. The current approach revolves around finding a best-fit software tool for the education business process. This includes Institution Management software (school, college, campus), Portal for the institute (along with necessary frills like IM, Single Sign On etc), Laboratory Management Software, Digital Library Information Services Software (Koha for the brave and others for the mere mortals).

Is this the right approach ? Perhaps not. This approach or offering is based on what the developer world makes of the requirements and the processes of the academic world. And in a way that could turn out to be dangerously skewed. Till date, at least for India, the developers have not really sat across with the academicians and educators to question them directly on what they want the software to do, how they want it to behave. I guess the time has come for us to do that. Just imagining (or assuming) the requirements and then trying to figure out the best possible pieces of the puzzle that will complete the jigsaw will only see FLOSS lose credibility.

This would of course lead to a more streamlined engagement with the developers. Only because we might see the need to develop software in house. Small example, any currently available Learning Management System if deployed directly in an Indian set up would fail to make an impact. Primarily because the course content is not on-line (or even in a state of being able to be ported online) and secondarily because the grading and examination processes are different. Then again we have to consider the need of different education boards in the country.

If you notice carefully, we have travelled down a rocky path till now. We began with the assumption that the current way of providing FLOSS for education is not proper and ended up with the real need to motivate developers to create applications or add functionality to existing applications. For example, a software like DrGeo would do pretty well if advanced mathematics modules aimed at standard 10,11 and 12 are added to it. Using that in conjuction with Octave, R and gnuplot would enable the creation of a complete tool set of educational applications for mathematics. And this is exactly what is lacking right now – the means to create modularised education stacks which can be plugged into a FLOSS based educational application framework. One framework for an entire board with modules being added at will to enable it to be re-used.

Involving developers and academic world leads to another phenomenon – User Driven Innovation. In case of a education stack based on FLOSS, UDI is the only way to get it going. It will pull in developers of various skillsets interacting with maintainers of existing packages as well as ensure that a proper fit software is developed.

I was reading through The Tipping Point again yesterday evening and what struck me was that it is time that community based Indic L10n needs to find its tipping point as soon as it can.

The Tipping Point is an examination of the social epidemics that surround us.

. For a moment forget about the semantics of the word epidemic and concentrate on how little things can coalesce to bring about big changes. Around a year and a half back, Indic L10n was a mish-mash of teams racing against each other and time to achieve complete translation for the various desktop environments. Today it is time to consolidate those efforts into providing one little push that will go a long way in changing the scheme of things.

With the release of the sub 10,000 INR desktop PC preloaded with Linux, the hardware vendors have clearly sent out a message that on the desktop, there are Linux applications which are complete in their own way. What needs to be put in place is an understanding of the most commonly used applications on the desktop and making them available in the currently active Indic Languages. One method of collating the information could be a wiki page on IndLinux. The idea would be to capture the localisation/translation status for applications as well as rendering and other known issues which could hinder their adoption on the desktop.

For the desktop space, applications should include Office Tools, Media Tools, Graphics Tools and Internet Applications. Once these are streamlined in terms of feature list and translation skew, they can be showcased as a complete desktop. Hope that this meeting at HBCSE figures out someway to find out the Tipping Point