QGIS Planet

QGIS Userbase Analytics


Understanding which regions QGIS is being used in, which versions are in active use, which platforms it is being used on, and how many users we have is hugely beneficial to our ability as a project to serve our users. Back in 2017 at the bi-annual QGIS hackfest in Nødebo, Denmark, we had a long discussion about key project goals and the need to better understand our user base in order to plan the future direction of the project, and allocate funding and resources to where they are needed most

Typically proprietary software vendors have ready access to detailed user data through telemetry code which they embed in their software. This telemetry code ‘phones home’ key metrics, which together with other techniques such as license sales analysis gives them a very detailed insight into their user base. The data these vendors collect is typically not shared, so their users do not benefit from being able to understand how their data is used.

For QGIS.org, having to resort to what are generally considered to be nefarious and privacy-invading techniques of siphoning user data from our users goes against the ethos we try to promote as an open project. Further, since QGIS is freely available and doesn’t require any self-registration, we do not have a user database we can consult for such analytics. Additional factors make understanding usage levels hard. For example, a single user can download a copy of a QGIS installer and distribute it to many other users, and conversely web crawlers and bots can download many copies of QGIS installers and never install them. Because of this, simply counting the number of downloads from our website does not give a useful picture of our user base.

So we needed to come up with an approach that:

  1. Does not invade our user’s privacy
  2. Does not require including telemetry code in QGIS which exfiltrates user information from their system
  3. Does not store any user-identifiable data on our servers
  4. Is open and transparent in the data collection methodology
  5. Openly shares the insights we gain from our analytics to the broader community

The most obvious privacy-respecting way we could find to understand more about our users was to collect metrics of access to the QGIS News Feed. In order to display the latest news on startup, QGIS Desktop makes a request to https://feed.qgis.org when it is opened. On the server that hosts the feed, we can then use the web server logs to understand which operating system and version of QGIS made the news feed request. Additionally, using the GeoIP library we can resolve each request to the country from which it originated. These pieces of information are included in the User-Agent headers sent by QGIS when it makes a request to the QGIS News Feed.

This process is anonymous, transparent, and simple to disable. It does not identify unique machines. Only one event is logged per unique network per hour. Only one event is logged per QGIS installation per day, and the event is only triggered when the user opens the QGIS Desktop application.

Operating system statistics are derived from QGIS version information, and no system fingerprinting or telemetry is implemented.

Location information is derived from the request source IP address, which is immediately discarded on the server after resolving it to the country of origin.

No logging on the QGIS News Feed server occurs with legacy installations that do not have the news feed feature, offline usage of QGIS, and installations for which feed collection is disabled (see below for info on how to disable it). It will also have statistics skewed in scenarios where atypical networking infrastructure is in effect, such as using a virtual private network.

Despite these caveats, the statistics should provide a good high-level overview of how QGIS is being used, such as the breakdown of QGIS across operating systems and versions – information that is incredibly useful to the QGIS developer team. Only the following four pieces of information are collected:

  • The date (aggregated by day)
  • The QGIS version
  • The Operating System
  • Country (based on IP which is immediately discarded)

Opting out

If you wish to opt-out of this data collection, simply disabling the feed retrieval, using QGIS offline, or blocking access to the QGIS RSS feed address (feed.qgis.org) on your network will exclude you from this process. QGIS Desktop provides options for disabling version checking and feed access under Settings ➔ Options ➔ General ➔ Application. Note that by default this setting is specific to each individual user profile.

Viewing the analytics

We have made a public dashboard publicly available at https://analytics.qgis.org. The dashboard was made using the fantastic open-source Metabase analytics package.

Credits: This post was written by Charles Dixon-Paver and Tim Sutton

QGIS Pi Mapping Contest Results

As you may have noticed, the next release version will be 3.14 and therefore, we will call it ‘Pi’.

Usually our versions are named for community meeting locations and the splash screen shows a map related to this location.

For 3.14 we were looking for creative maps that capture the essence of Pi.


The submission phase was open for two weeks and we received numerous inspiring submissions:

Public voting

From these submissions, a short list of top 3 candidates was compiled and put up for the public vote:

Candidate #1 Ezequiel Orquera writes about his submission: “As an agronomist, Pi is used every single time that you need to develop a pivot irrigation system (those nice circles we can see on sat. images), making most use of Pi number and the radius. In this image, we can see the circles in contrast with rectangles shapes. The interest thing is that on most of the circles you can see the irrigation system arm that is coming from the center of each circle, making it the radius. Furthermore we all know that Pi x r^2 = circle area. This is useful to estimate for example, crop yields.”

Candidate #2 Francis Josef Gasgonia writes about his submission: “This map would not be complete without the use of Pi. Multicentric ring buffers represent potential danger zones in this map of Mt. Isarog in the Philippines. The calculations necessary to develop the ring buffers depend on Pi. Mt. Isarog is classified as a potentially active stratovolcano. This map best represents the use of Pi in a map because these buffers are crucial in disaster planning, especially now in a Covid-19 pandemic world; wherein ring buffers, and other types of buffers are in use for humanitarian and logistics planning.”

Candidate #3 Michel Stuyts writes about his submission: “Since Pi is very much linked to circles, I looked for the most circular place I could find. The place I made a map of is Vahanga, an atoll in the Pacific Ocean. I decorated the map with angles of a circle in radians as divisions of Pi. Because QGIS splash screens usually show a map of a location where a developer meeting was, the chance it would ever have a map of this part of the world is just as irrational as Pi, because the closest inhabited place is more than a 1000km away. My map is also linked to Corona (the reason there was no dev meeting in the first place), because the atoll is crown shaped and Corona means crown. Besides being linked to Pi and Corona, my map is also very much linked to QGIS, because it’s 100% made with QGIS. The angles in radians where made with “geometry generators” from the central point. The fills where made using “random marker fills” combined with an expression using “randf()” to set the size of the markers with a “Data defined override”. For the shallow water on the inside of the atoll I used a “Shapeburst fill”.

And the winner is …

In the public vote, Francis Josef Gasgonia’s map received the most votes (46%):

Congratulations Francis and thank you again to everyone who participated in this fun contest to ensure that QGIS 3.14 Pi will have great visuals!

LTR usage survey

Back in 2018, we asked QGIS users how often they use QGIS and how often they upgrade. Today, we want to find out more about how different user groups and organisations use QGIS and particularly the LTR. You may be aware of ongoing discussions concerning potentially extending the LTR period and other potential steps to further improve user experience.

To better understand the needs of our QGIS community, we therefore invite you to our new LTR usage survey:


Update as posted on the mailing list: 

Thanks to all respondents, we’ve collected over 1,600 responses to this questionnaire!

Some interesting tidbits:

  1. The LTR concept seems to be well accepted: 50% of respondents use 3.10 LTR, 38% use 3.12, and 16% use 3.4 LTR.
  2. Most respondents install patch versions but 27% do so less often than every 6 months.
  3. Most respondents install .0 releases but 17% wait until .3 or longer
  4. 6% of respondents work in organizations with more than >100 users. It will be interesting to look at those responses separately.
  5. 7% say that they still need 32bit installers

You can find the raw survey responses here:


User question of the Month – Dec 18 & answers from Nov

It’s December and that means it is time to plan for the next year. Planning also means preparing a budget and to do so, we would like to learn more about what you think QGIS.ORG should focus on: features or bug fixing and polishing? Therefore, we invite you to our QGIS user question of December 2018.

We also have localized translated versions of this questionnaire for our French-speaking and Portuguese-speaking users.

Your answers in November

In November, we wanted to know which version of QGIS you use.

User question of the Month – Nov 18

QGIS 2.18 is the third LTR since we started this effort back in 2015 and next year will see the first LTR of QGIS 3. On this occasion, we want to learn more about our users and which versions of QGIS they use. Therefore, we invite you to our QGIS user question of the month.

Promoting and using QGIS for the enterprise

Over the years, QGIS has gained more functionality, more users and more people and organisations who make their livelihood from it. As an Open Source project, there are two things that we value most highly (and equally):

  • Our community of users
  • Our community of project contributors

The two groups are intermingled, co-dependent and indispensable to the project. As both these groups have grown, our reach has grown. Now as a project we touch the lives of (by best estimation) hundreds of thousands of users and contributors around the world.

It is a natural consequence of such reach that QGIS has become an attractive platform for companies on which to build service based business models to their customers. From this rises the advent of ‘enterprise’ offerings – service packages tailored for large corporate and government institutions which need service level agreements, guaranteed turn around times, helpdesk support and so on. As a volunteer driven, grass roots project we are not in the position to, and do not have the interest in catering to this class of user base via support agreements etc. Commercial support is far better taken care of through third party service providers that have the infrastructure and legal means to set up such service offerings.

As the momentum grows around such enterprise services it is probably an inevitable consequence that tension may arise between third party service providers and the QGIS core project. In simplistic terms this tension can be seen as the dichotomy between those of us who view our work on QGIS as a labour of love versus those who see their work around QGIS as a labour of commercial enterprise. Of course there are many cases where the people providing such support do come from the community, do see their work as a labour of love, but as the stakes get higher and the size of support companies grows (to the point where they are also recruiting staff from outside the QGIS community), there is more opportunity for this dichotomy to realise itself.

The reality is that much like the relationship between project contributors and our community of users, there is a huge amount of potential symbiosis between the QGIS developer community and the growing number of value added resellers providing services around QGIS: many of the improvements, bug fixes and other enhancements produced by value added resellers make their way back into the core QGIS offering, whilst the body of work produced by the community of QGIS project contributors becomes the basis around which value added resellers build their marketplace offering.

Over the years we have tried to be sensitive to the fact that many people rely on QGIS for their livelihood – initiatives such as our Long Term Release programme, the creation of test suites and heavy investment of donated project funds into bug fixing (among many other similar initiatives) have all gone a long way to making QGIS a viable platform for value added resellers. We would like to ask that resellers give the QGIS project similar consideration in their marketing and work endeavours. As such I would like to present a few simple guidelines below that you should use as guiding principles in your interaction with the QGIS project. I will use a hypothetical company ‘ACME Corp.’ in my examples below:

Respect the license

QGIS is published under the GPL v2 or greater license. The letter of the license states that if you extend the source code  of QGIS, and publish those changes (for example by making it available on a download site for your users), you need to publish the source code changes too, making them available to your users. In the spirit of the license, you should share your improvements to QGIS with the greater project (e.g. by making your code tree publicly accessible).

Similarly when publishing a plugin, don’t ship it with proprietary binary ‘blobs’, or only with .pyc (compiled python files) leaving out the original python sources. If you do absolutely have to ship it with a binary (for example you need a c-compiled python module for your plugin), make sure to provide a clear trail to the upstream sources for those binary elements.

I personally find discussions of licensing get quickly tedious and I prefer to emphasise the spirit of open source rather than getting stuck in legalese: “We share our work with you, you share your work with us and we all benefit“. It’s really that simple for me. When you stray from this maxim, you are very likely to, at best, ruffle feathers and, at worst, create a really bad impression about your company and the people that work for it.


Don’t present your work as our work

It seems obvious, but many miss the nuance here. If you wrote a marvellous plugin to count sheep in farm fields because it will add great value to your customers, call it ‘ACME. Corp sheep counter’, not ‘QGIS Sheep Counter’. Also bear in mind that the word ‘QGIS’ is trademarked (the trademark is owned by the QGIS.org community). If you want to name your project, you should read our trademark guidelines. Contact us at [email protected] if you have any uncertainty about how you are using the word ‘QGIS’ in your brand.

Don’t present our work as your work

This is the corollary to the above. Our community works incredibly hard to make QGIS, the web site, the documentation, triage bugs, provide help on the mailing lists and forums. All that effort can be disregarded in a single line of careless copy like ‘QGIS by ACME Corp. is the next best thing since sliced cheese‘. Show a little love to the people that built the platform for your service offering and refer back to the parent QGIS project and its community as the progenitor of all the goodness you are sharing with your clients. That does not denigrate the valuable service that you provide your customers and it lets them know that you represent your company and work fairly and contribute back to the source project that you are basing your services on.

Friends don’t fork

Forking in Open Source is the process by which you create your own divergent copy of the  software and maintain it independently, often resulting in two incompatible versions (at the source code level) of the same project. Nobody really wins from that. Your customers lose the ability to migrate projects, workflows and knowledge between the community maintained version of QGIS and your modified one. In reality forking is normal (its the standard workflow in GitHub for example), but I really am referring to the process whereby you create an heavily diverged copy of the source code. When you create a divergent fork, your developers get stuck in a one directional highway which takes them further and further away from the original code base and any opportunity to capitalise on the work of other contributors from the QGIS community. There is also an economic imperative not to make a divergent fork – to quote community member Vincent Picavet:

“… forking a project is not a good idea in terms of economics. Maintaining software is more than half of the TCO [Total Cost of Ownership], and on the medium-long term, maintaining a fork of QGIS will cost much more than integrating the specific code into the master codebase, even if initial costs are higher for master integration.”

Don’t rebrand

Every few months I get an email from a value added service provider asking me if I can help them produce a version of QGIS which is rebranded as ‘ACME Corp. GIS’. By rebranding here I mean deep rebranding – not just replacing the splash screen (which I am generally OK with), but changing the word ‘QGIS’ everywhere in the source code and user interface to ‘ACME Corp. GIS’.  Beyond the fact that you instantly break all sorts of things like QGIS project file support, you also create a fork that will require massive amounts of maintenance  to keep in sync with the upstream project.

Integrate your team with the QGIS community

One great way to give your clients a good service and to ensure that your work is well accepted is to integrate your developers with the QGIS community. By that I mean let them subscribe to our mailing lists, participate in architecture and other discussions, fix issues, contribute code, attend our 6 monthly hackfests and generally be part of the ebb and flow of the project. There are so many benefits to doing this – both to QGIS and yourself – which is probably evidenced by the fact that the most well known QGIS value added service providers each have a number of developers participating in the community. My main motivation above all other reasons is that they will gain the sensitivity to know how to get your improvements integrated into the code base, and the trust and camaraderie of the other community members which is great when the time comes that they need help solving problems.


Integrate your work with the QGIS code base

Whereas above we ask you not to fork, how can you be sure your changes will be acceptable so that you do not need to maintain a fork? Whenever you are thinking about new features for your clients, I encourage you to think about how to make them generic enough that they can be incorporated into the main code base. Once you do that, you have an automatic delivery platform of your work to your users. QGIS has a well established release routine and the features shipped with QGIS get tested and used by many thousands of users. Besides you are benefitting from the features others are funding, why not pay the same compliment back by designing your features in a way that everyone can use them, not only your clients?

Keep us in the loop

There is so much going on around the QGIS project we often get surprised by things people do. More often than not it is a pleasant surprise but sometimes it isn’t. If you are planning some big new feature or creating a new service around QGIS, I highly recommend that you share it with the community early in your planning process. In particular for the case of new features that you would like to see in the main code base, coming along with an ACME Corp. 10,000 line code contribution with no prior consultation creates ample room for friction. If you want to know that a larger feature you are planning will be accepted, check out our QEP (QGIS Enhancement Proposal) process.

Don’t only contribute code

For some reason coders are treated as the main heros in the story of an Open Source project. Many people overlook the fact that there is a far larger team of translators, document writers, sys admins, authors, artists, testers and enthusiasts who contribute a massive amount of effort into the project. When you are thinking about how to contribute back to the project, take a moment to think about all the infrastructure around the project and how you might help that along – as well as the cool new features you plan to contribute to the code base.


There are many other things that you can do to integrate yourself into the community, but my real point in this article is that although QGIS is Free Software, it is not made for free. Take a look at the QGIS page on Ohloh if you want to get a feel for just how much effort has gone into QGIS. Many people have put a lot of sweat equity into QGIS and the only reward they get for their work (if they are lucky) is recognition and appreciation. Think of them when you build services on top of QGIS and find ways to acknowledge and motivate them!

Here’s looking forward to seeing many thousands of people making their livelihood by offering services around QGIS!


Tim Sutton

(QGIS Project Chair)

Back to Top

Sustaining Members