How to effectively get things changed in QGIS

I’ve been heavily involved in the open source QGIS mapping project for a number of years now. During this time I’ve kept a close watch on the various mailing lists, issue trackers, stackexchange, tweets and other various means users have to provide feedback to the project. Recently, I’ve started to come to the conclusion that there’s a lot of fundamental confusion about how the project works and how users can get changes made to the project. Read on for these insights, but keep in mind that these are just my thoughts and not reflective of the whole community’s views!..

Firstly – QGIS is a community driven project. Unlike some open source projects (and unlike the commercial GIS offerings) there is no corporate backer or singular organisation directing the project. This means two things:

  1. The bad news: No-one will do your work for you. QGIS has been created through a mix of user-led contributions (ie, users who have a need to change something and dive in and do it themselves) and through commercially supported contributions (either organisations who offer commercial QGIS support pushing fixes because their customers are directly affected or because they’ve been contracted by someone to implement a particular change). There HAS been a number of volunteer contributions from developers who are just donating their time (for various reasons), but these contributions are very much the minority.
  2. The good news: YOU have the power to shape the project! (And whenever I say “you” – I’m referring directly to the person reading this, or the company you work for. Just pretend it’s in 24 point bold red blinking text.) Because QGIS is community driven (and not subject to the whims of any one particular enterprise) every user has the ability to implement changes and fixes in the program.

So how exactly can users get changes implemented in QGIS? Well, let’s take a look at all the possible different ways that changes get made and how effective each one is:

  1. YOU can make the changes yourself. This implies that you have the c++/Python skills required to make the changes, are able to find your way around the source code, and push through the initial hurdles of setting up a build environment and navigating git. This can be a significant time investment, but the ultimate result is that you can make whatever changes you want, and so long as your pull request is accepted you’ll get your changes directly into QGIS. You’ll find the QGIS team is very open to new contributors and will readily lend a hand if you need assistance navigating the source or for advise on the best way to make these changes. Just ask!
  2. YOU (or your employer) can pay (or “sponsor”) someone to make the changes on your behalf. Reinvesting some of those savings you’re making through using an open source program back into the program itself is a great idea, and everyone benefits. There’s numerous organisations who specialise in QGIS development (eg… my own consultancy, North Road). You can liaise with these organisations to get them to make the changes on your behalf. This is probably the most effective way of getting changes implemented. These organisations all have a history with QGIS development and this experience generally translates to much faster development then if you code it yourself. It’s also somewhat of a shortcut – if you hire a core QGIS developer to make your changes, then you can be confident that they are familiar with the coding style, policies, and long-term goals of the project and accordingly can get the changes accepted rapidly. The obvious down side of paying for changes is that, well, it costs money. Understandably, not everyone has the resources available to do this.
  3. Following on from option 2 – if you can’t directly sponsor changes yourself, you could help indirectly raise funds to pay for the changes. This is a great way to get changes implemented, because everyone has the power to do this. You could seek out similar organisations/users who have the same need and pool your resources, get involved with the local QGIS user group and raise funds together, organise a crowd-funding campaign, etc.
  4. Ask a developer to make the changes for you. This is not terribly effective – you’re basically asking someone to work for free, and take time away from their family/job/hobbies/social life to do work for you. That said, it does sometimes happen, and here’s a few reasons I can think of why:
    • You’ve build up enough “karma” within the project through other contributions. If someone has been heavily involved in the non-development side of the project (eg translations, documentation, helping users out on mailing lists/stackexchange, organising hackfests or user groups, etc) then developers are much more likely to want to help them out in turn.
    • You’ve got a fantastic idea which has just never occurred to anyone before. By bringing it to the attention of a developer you might trigger the “wow, I could really benefit from that too!” impulse which is hard-wired into some of us!
    • It’s a particularly interesting or challenging problem, and sometimes developers just like to extend themselves.
  5. (For bugs only) File a bug report, and hope it gets picked up in one of the pre-release bug fixing sprints. This is basically the same as option 2 – expect that in this case someone else (the QGIS steering committee) is paying for the development time. There’s no way of guaranteeing that your bug will get fixed during this time though, so it’s not a particularly reliable approach if the fix is critical for you.

Finally, there’s two more very ineffective approaches:

  1. File a bug report/feature request, and wait. This isn’t very effective, because what you’re doing is basically the same as 1-4 above, but just waiting for someone else to either do the work or sponsor the changes. This might happen in a week, or might take 10 years.
  2. Complain about something and hope for the best. This is… not very effective. No-one is particularly motivated to help out someone who is being a jerk.

That’s it. Those are the ONLY ways changes get made in QGIS. There’s no other magical short-cuts you can take. Some of these approaches are much more effective than others, and some require skills or resources which may not be available. If you want to see something change in QGIS, you need to take a look at these options and decide for yourself which best meets your needs. But please, just don’t choose option 7!

Update: a follow up to this article was published

 

Tagged , ,

9 thoughts on “How to effectively get things changed in QGIS

  1. Paulo says:

    I fully appreciate and agree to your points, but just to add a small side note about the option to file a bug report (option 5). Apart from the likelihood that your bug report will be addressed, I think bug reporting should be encouraged as it can help to improve stability / reliability. This is especially true for those willing to run a development version of QGIS.

  2. Hi Nyall,
    I do totaly agree with what you have written. I have also included most of your points in each release article published on linuxfr (in french) in the conclusion part: https://linuxfr.org/news/sortie-de-qgis-2-16-nodebo#conclusions where I tell users how they can contribute to the QGIS project…

  3. Just says:

    Excellent writeup! Think we can substitute “QGIS” in the text for any Open Source Geospatial/OSGeo project and the content would still be holding. (And I agree with Paulo’s comment).

  4. Brilliant article, very useful; thanks. One remark to add to point 4 about asking a developer: there are QGIS users out there who don’t have the required programming skills but *do* have great ideas for improvements on, for example, rendering functions. They’re usually called cartographers. These people can only make their dreams come true by asking developers to implement changes for them. I’ve seen this work beautifully myself recently with curved road labeling 😉

  5. Germán says:

    First of all, thanks Nyall for explaining us a bit more about the QGIS project.

    I think option 5 only shows one side of the coin. I encourage people to fill tickets if they find problems, and I do it myself, not because I WANT something to be fixed, but to inform QGIS devs (and users too) about things they might have overlooked for any reason (i.e., a case that tests didn’t identify).

    I think developers may appreciate if someone finds a ‘hole’ in some of their developments, because, at least for me, it can also be considered work (namely, testing) and, as such, it represents a contribution. Bug reports should be welcomed for the project ‘health’ and should not be seen as simple requests.

    A last thing, it’s not about ‘your bug’, it’s about a QGIS bug. If a bug affects me more than it does to anyone else (i.e., if nobody else cares about it), then we could be talking about a feature, and that’s another story you have already covered in this post.

    Regards.

  6. […] week I posted regarding some thoughts I’ve had recently concerning what I perceive as a general confusion about how QGIS is […]

Leave a Reply

Your email address will not be published. Required fields are marked *