Today we (the QGIS project) sent out the release announcement for QGIS 1.7. This release took much longer than we would have liked – it included many new features and we implemented many changes to our project infrastructure – all of which consumed time and slowed the release process. There was quite a bit of debate around the release, roughly divided into 3 camps:

- lets get the release out now, its overdue and we need to move on
- lets hold up until there are no more critical bugs
- lets put the release out but mark it as beta, release candidate or similar

Its always difficult to keep everyone happy, and some comments especially for example ones like this from Markus Neteler (of GRASS fame) are especially resonant:

If QGIS crashes several times in a row, I will tend to abandon it as a user.

 Recently I had to downgrade (like other colleagues I know) to QGIS 1.5
 since 1.6 was unusable for me. And if QGIS 1.7 is even worse (I stopped
 trying trunk which I used to do elsewhere), I will not even try to install it.
 Sorry if that sounds harsh but I start to no agree much with the apparent
 QGIS' policy of "we-release-with-most-features-possible-but-with-low-stability"
 which impacts more and more the recent QGIS releases.
 Please note that I (happily) follow QGIS since V 0.x.

 A plea: Please don't overload QGIS with new features at the cost of even
 destabilizing the existing good material.

Markus raises some good points and generally I would agree that we do chase features over stability. Personally I don’t experience too many stability issues with QGIS but it could be that I am in the habit of subconsciously working around issues may cause it to throw a wobbly. It’s a difficult trade off though – QGIS in many respects is still an immature GIS with many features that people expect from a GIS missing. This is especially true if you consider the ‘core’ QGIS application without the GRASS plugin (which introduces many tools from the excellent GRASS toolset). In order to meet the mainstream GIS user’s needs, we need to close this feature gap – and we have been making rapid strides in this direction over the last few years. But closing this feature GAP means that we don’t tend to have bug fix only releases and a strong focus on code stabilisation.

Much of these advances in functionality have been due to features directly funded by users (typically corporate or local government).  Usually they will contract a developer independently, the developer will build their requirements and if the features are of general interest, incorporate them into the general QGIS source code base. This is a great model and has really allowed the QGIS featureset to ramp up quickly – and to build up a small cottage industry of code development work around QGIS.

The downside to this model is that these same clients typically don’t exhibit much interest in funding some of the less sexy aspects of the project – things like writing unit tests, maintaining API documentation, maintaining overall GUI consistency and user experience often fall by the way side. We have soft policies for these things – new features to QGIS core should be accompanied by unit tests, all code should be documented properly and adhere to our coding standards, we have a basic Human Interface Guide (HIG) and so on. However, to really follow through with these QA aspects of the project is probably a full time job  for multiple developers and at the moment its achieved as a patchy effort as and when volunteer developers have time to do so.

In the short term we plan to try address the concerns of Markus and others by backporting fixes from the master branch into the 1.7 branch and putting out maintenance releases (i.e. 1.7.1, 1.7.2 and so on) which will hopefully provide a more stable platform into the future. Even this can be difficult though given the points I made above about feature ramp up. This is especially true of the upcoming development cycle where we are going to be paving the way for 2.0 – which will include removing redundant elements of the application. Redundant you may ask? Currently we have two labelling systems, two rendering systems, a growing number of deprecated API calls and so on. For 2.0 we will spring cleaning a lot of this away. This is good, but it also means that the delta between the master branch and the release branch will become rather large and backporting fixes may not always prove to be very easy.

In doing a bit of navel gazing around the 1.7 release, I updated the download stats for the 1.6 release. Here is a quick overview  (click the image for full size view):

Cumulative download chart for QGIS 1.6

Download decay chart for QGIS 1.6

As you can see from the charts, QGIS is becoming more and more popular, we are just shy of 190,000 downloads for the windows standalone installer for QGIS 1.6. (based on our awstats logs). These figures may not totally accurately reflect our user base though. On the one hand, a download does not necessarily represent a user since the internet is full of bots and spiders crawling web sites and so on. On the other hand, a single download may be used by multiple, tens or even hundreds of users. Now the interesting thing is that given that user base, the donations and sponsorship the project receives is probably equivalent to the purchase price of only one or two ESRI Arc* software licenses. When you think about the sheer number of people we are enabling to have access to GIS software at not cost, it is quite a stunning revelation.

At the same time, there are 190,000 users out there whose expectations need to be met by a very small and relatively unfunded group of active developers and community members. The QGIS developer mailing list has had quite a few active discussions about funding models, sponsored bug fixing and the like over the last few months. In the past we have had problems with ‘directed‘ funding for features or bug fixes not materialising or placing unreasonable expectations on a project that is essentially volunteer driven. It has long been by dream that we can create an undirected fund for QGIS that is there to fully sponsor several of us developers and community members to work on those ‘unsexy’ things I listed above. I think directed funding to target bugs and specific features can be a valuable source of improvement to the project, but I think we will only see real improvement gains to the project when we have sufficient undirected funding to afford us the luxury of not having day jobs that interfere with our QGIS hobby, and really focus on the things that we often don’t get time to do in our capacity as hobbyists.

Hopefully as our user base grows and the software reaches a critical mass in Government and the private sector, my dream of working on QGIS full time, and others who share this dream, will become a reality. In the mean time we will continue to try to make the best software that we can and improve the quality of the work we do so that everyone who tries QGIS enjoys the experience and never feels the need to shell out for a commercial software vendors license.

This turned into a bit of an essay….but it is probably useful to put these things out there so that folks get a better feel for how the project ticks, and where they can meaningfully contribute help. Many of the very active developers and community members of the QGIS project don’t ‘blog’ and otherwise keep a low profile, but I want to just say: “you guys and girls are awesome, I am really going to enjoy using your work in QGIS 1.7!”.