Last week I wrote about the new version of Ilwis that is in the making. It is still a long way off but its contours are beginning to take shape. The questions is though, why are we (52n) doing this? What is the rationale behind it? I mean, we have a working version of Ilwis. It may have its quirks and limitations but I have the feeling that what it is trying to, it does that well enough. So why?

First of all a little bit of history. Ilwis has a long history; started in the second half of 80’s of the last century, going through various versions from 1.xxx version that rand on MS-DOS and needed two screens (basically, one for the map and one for the rest). The 2.xxx versions ( designed mostely around 1994-1995), with a dongel and still firmly rooted in 16-bits code with all kind of limitations (640k memory limits, anyone?). And then the 3.xxx versions which were basically a much improved 2.xxx version in 32-bits. Though Ilwis went through many versions and many changes, the core architecture is still a 1995 architecture. Credits to the designers of those days ( Wim Koolhoven and Jelle Wind) that the basics of their design remains viable to this day.

But times have changed. The single workstation situation of 1995 has been severely eroded and will continue to shrink in importance. The last 10-15 years we have seen a quick rise in connectivity all over the world and Ilwis has not really moved with that. Data also has changed. The file based concepts of 1995 are still relevant to this day but online data is quickly growing in importance. Furthermore  the nature of data has changed, spatial temporal data, semi structured data, real time data, sensor data and the list goes on. Data types that played a limited or no role when Ilwis was designed , are now widely available.

Then there is the question of platform. In 1994- 1995 ( before I worked here) there was basically one choice : Windows. Sure there was Unix, and there has even been a serious investigation in the viability of making Ilwis on that platform, but seeing the dominance of windows the choice for that platform was reasonable. That has changed. Windows is still dominant on the desktop but a number of other platforms have become attractive choices. Linux on the desktop is still a midget and though I know a number of users would like a desktop-Linux version of Ilwis, the effort would be hard to defend compared to the gains. But Linux has a strong market segment in the server world and as the next generation of Ilwis will also run server side as service provider, Linux has to be taken into consideration. Besides that, there has been of course the explosion of the mobile devices of the last 5 years. We must respond to that; it is probably the most important change that has taken place in the platform business and it will continue to shape it in the years to come.

The next important issue is the programming itself. Ilwis was started as a close sourced piece of software. There was some documentation but it was never really that needed. There was always somebody in the group “who knew”. Furthermore, as communication was limited to the group, interfaces were designed in such a way that they solved a problem but were not especially transparent or general. And then there was of course time. Time erodes most good intentions and what were at first isolated quick solutions for problems became a patch work complex interfaces and inter-dependencies. Open sourcing Ilwis was a good idea but the code base was not really conductive for it. Growing the number of developers is  needed to remain viable in the long run, but you need quite a lot of persistence to understand the jungle that is the current code base.

So were does that leave us? Could we patch up the current version to meet these challenges? I don’t see it. Ilwis is very tied to the Windows platform; its core coding relies on a number of libraries that are solely available on windows (MFC a.o.) and removing that from the code is herculean task. Restarting that part from the ground up is a much better choice as that solves the byzantine code problem and the documentation issue at the same time.

Another idea would be to take part in an existing FOSS project like for example QGIS and do “our thing” there. It is a reasonable idea but it has a few flaws. I work mostly for scientists and at times their requests and wishes require some tinkering at deep core level. The Geonetcast toolbox would never have worked properly if I didnt have the ability to change the core handling of commands in Ilwis. This kind access isnt granted (unless you fork the whole project, but then the reason for participating is questionable anyway)  to anyone but trusted commiters who have proven their worth over time (rightly so). It is also questionable if existing FOSS projects can meet the requirements I see without major redesigning. So, yeah, you could join but it would be a big political effort(and thus time) to get out of the project what you need.  Anyway, some arrogance, “I know better than they do”, isn’t that bad. That is how creative things usually start (and then comes the part no one mentions : lots of work).

The road forward is then to redesign Ilwis from the ground up, taking into account the current and foreseeable IT context, and, also important, not forgetting what we did right in the existing Ilwis(and migrate that). Furthermore we must build on a base that is platform independent. Documentation is important ( up to a point) and it is not acceptable that new structure will go largely undocumented. Yes , i know, this is a lot of work. But well, good things usually require effort. So no surprise there :).

Next week : The high level design

On a more practical level. Ilwis 3.8.3 is done and at 52n but will probably be available after Eastern due to some holidays.