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.