During the developer hackfest at our recent QGIS Conference in Nødebo, the developers present had a discussion session about the future (post 3.0) road map for QGIS. Note that the ideas laid out here do no necessarily represent a consensus between all the QGIS developers and community members since those present at the hackfest were only a subset of the great QGIS community. However the discussion probably provides a good idea of the kind of things on our minds as we move forward to QGIS 3.0 and beyond. Just a note before you get too excited reading the article below: This was a future looking session of great ideas that will take QGIS forward, but there may not be anybody actively working on these ideas (if you are looking for something to fund it would be a great start!). Here are twelve ideas that were raised (in no particular order)…

1. We need to beef up the analytical capabilities in QGIS

There was a general feeling that we should have stronger analytical capabilities in QGIS. Somewhere along the line we lost ManageR (the R integration with QGIS) and we have missed the boat in having something like Pandas / Jupyter Notebooks, embedded into QGIS (with iface available to the console). Whilst many data scientists are using R, going the python route with Pandas and Jupyter Notebooks might be a better fit in terms of being harmonious with the other work that has been done to provide python bindings for QGIS. But hey, why not provide both a Jupyter Notebook that supports both Python and R out of the box? Technically curious may want to look here for some hints on how we might go about integrating Jupyter into the QGIS application…

2. We need to improve our ‘first open’ experience

Especially for new users and novice GIS users, starting a QGIS project with a blank white canvas and many buttons and menus can be quite intimidating. We want to provide some basic projects (e.g. based on OpenStreetmap tiles) that can appear as a default layer when you open the QGIS application so that you can immediately get a sense of place and space – much like you would get in Google maps or any web mapping application. Naturally we will provide the option to disable this for those who are not interested in this functionality, but we would make it a default behaviour for new users…

3. We need a better way of communicating with our users

We do not even know simple things like how many users we have (I estimate broadly between 500 000 and 1 000 000 users based on downloads). Most users are silent users – they never communicate with the upstream project via our mailing lists or other communication mechanisms. Not knowing stuff about our users makes it hard to build a better product for them, and not having a communication channel with our users makes it hard for us to let them know about important updates, bug fixes, events etc. and it is a bit silly to be in this situation because every time a user opens QGIS, we have an opportunity to share this kind of information with them. So in the future it would be nice to have a way to provide timed and targeted messages to our users (for example letting them know when we have made a new blog post on the official QGIS blog). It would be nice to have the notification system scriptable by plugin. Of course it should be easy to opt out of or filter the messages by category (e.g. don’t show me event announcements) we share with our users. Imagine on the projects list view you see when you first open QGIS that we have a panel to the right of the projects list which just lists the headlines of the latest announcements. Perhaps there are other ways we can communicate with our users, but we should really make it a priority to get to know our users and this seems like a good start. By seeing how many times a given article gets read after it as been posted in the QGIS announcement area, we might get a better indication of how many users we have. Another example – when a new LTR bug fix comes out, we can publicise it better to make sure users are aware of the important fixes.

4. We need to focus on Quality Assurance (QA)

Especially as relates to reducing the incidence of side effects, QA is going to be critical as the project grows and gains a user base that uses it for critical functions. Side effects happen when e.g. a developer implements one feature that (probably unbeknownst to him) breaks another feature. Side effects are bad because they are hard to test for and hard to trace back to the root cause. The development of QGIS happens in a largely ad hoc manner – developers get contracts to build features their clients need, there is no top-down approach to how we roll out new features. This makes it difficult for us to ensure that side effects do not happen. We are not only concerned with side effects, but QA in general and would like to have the time and resources to spend on really taking the work that has already been put in place (automated testing on Travis for example) to the next level.

5. We need more dedicated (paid) effort to take care of the project

QGIS has become too big of a project to rely entirely on volunteers to take care of all aspects of the project. Many of us still contribute many hours of unpaid volunteer time to the project and will continue to do so. It has long been my vision that we eventually recruited a corps of professional (i.e. paid) contributors to work on QGIS, especially to take care of things that contract work will never cover. For example triaging the pull request queue (which is extremely time consuming), managing the issues in the issue tracker, expanding our test suite coverage, writing documentation, fixing bugs and building ‘cross cutting functionality that typically would not be funded by client work but that everyone will derive benefit from. Our project revenue (from sponsorships and donations) has been steadily growing (thank you to all of those that have contributed!) and if we can increase the revenue a little more we will reach the point where we can start to recruit some of our community members to work for QGIS.org on a professional basis – maybe on a part time basis in the beginning, but eventually building a corps of full time paid staff. This has long been a vision of mine for QGIS and if it is the one thing we achieve while I am project chair, I will be a happy chappie!

6. We need to automate trace captures

This relates somewhat to 3. above – when a user experiences a crash in QGIS, we have no automated way to get that crash information (and no Apple / Microsoft do not pass along the tracebacks to us when they offer to let you post them to their domain 🙂 ). Services like Sentry can aggregate crash data and help us understand the impact of different issues – and thus how to prioritise fixes.

7. We need to find ways to include a more diverse range of people in the project

In this particular brain storming session, we had one lady (hi Sophie!) in a room full of maybe 40 men.

We also have little representation from Africa, Asia, Latin America. A few years ago we added a diversity statement and a code of conduct to our web site, but  we need to ‘get out there’ and be more active about ensuring that people of all ages, genders, races, religions and cultures feel welcomed into our project and start actively participating as ‘makers’ not just consumers. We are a friendly and welcoming project and we should take the effort to let everyone know they are welcome in our community. Some ideas were aired about e.g. having scholarships to fund people from developing nations who would like to attend our conferences and hackfests, and scholarships to fund new developers to port plugins to QGIS 3.0 or similar more entry level tasks. It would be great to have users out there in the commercial world reach out to us to help make this happen (e.g. by offering to fund the travel and expenses of a developer who would normally not be able to attend due to costs).

8. We need to work on maintaining good relations with providers

QGIS sports a growing list of independent commercial support providers – some with very large user bases. I’ve written before here on the blog about some things providers should do to be ‘QGIS friendly’. We really want to encourage providers to use the QGIS LTR’s (Long Term Releases) as the basis for their support services, upstream their fixes to the QGIS project and avoid providing forked copies of QGIS to their clients. Why? It will improve the quality of the LTR QGIS packages and clients of every support provider will benefit. We would also really like to appeal to our commercial support providers to refer to QGIS upstream LTR builds as the ‘Official’ QGIS releases and not some lesser adjective like the ‘Community’ QGIS Release. There was the sentiment in the meeting that  calling it a community release implies that the vendor’s packaged copy is the ‘good one’ and the QGIS.org is the ‘not so good one’ and we would like to reverse that perception. It may seem like splitting hairs to some but we would like to see that there is not fragmentation in the user base of QGIS so we think that it is important to set the right tone from the get-go.

9. We need to promote that QGIS is now a legal entity

It has taken a lot of work, planning and hoop jumping, but QGIS.org is now a legal entity – a Swiss Association / Verein. We are VAT registered, have our own bank account and can now hold our own trademarks and IP instead of working through a proxy. We hope this will open a new chapter in the future growth of QGIS – in particular in our ability to attract much more substantial funding and to make formal agreements with entities where needed. A huge thank you to Andreas Neumann (QGIS PSC Member and project treasurer) for making the whole process happen!

10. We should establish credibility by code signing our products

There was some discussion about the fact that QGIS installers don’t always get recognised by operating systems as a ‘good’ application – virus checkers might flag it or system preferences my reject applications that are not code signed. The good news is that since the meeting Jürgen Fischer has added code signing for the Windows binaries (if that makes you happy please buy him a beer or something :-)) and there is work in progress by Larry Shaffer (who might also be motivated by beer :-)) to have code signed MacOS installers. Of course Linux users are probably scoffing here since they have a nice package distribution mechanism in place and they are already signed.

11. We need a smoother path to integration of code contributions

There was an extended discussion in our meeting about how we should manage contributions to QGIS as we move forward. Some were in favour of forcing everyone to use Pull Requests (PR’s) with a peer review. Others were in favour of also being able to push directly to the code base. Various other permutations were discussed. For now we are going to continue on with our current approach more or less which is to not prevent direct pushes to the code tree, but to discourage it – and of course non-core users will be required to use PR’s since they don’t have direct push rights to the official repo. Suffice to say we are aware of the fact that we have a large backlog of PR’s that are not merged and that it can sometimes be difficult to get your work merged. Hopefully in the future the ideas outlined in point 5. above will help to alleviate this situation….

12. Intergalactic domination

This was a late addition to our meeting notes, but still a worthwhile cause. Martin Dobias  felt strongly that we should include in our roadmap (thus not pictured below), plans for intergalactic domination and hey, if we are going to do something like that, we will need a good GIS to help us find our way around right? 🙂

Thanks to Nyall Dawson for prompting the discussion, it was great to once again experience how convivial and constructive our community discussions are, even when the topics can sometimes get difficult or technically involved!