[Qgis-developer] Fwd: Re: [Qgis-community-team] Books section on our website

Andreas Neumann a.neumann at carto.net
Tue Oct 13 05:25:04 PDT 2015


In the context of our release discussion I am forwarding the perspective 
of an educator and book author - just posted to the QGIS community 
mailing list. See forwarded mail.

I understand it must be a nightmare to teach, document and write books 
on QGIS at the current pace.

I hope that the devs and QGIS.ORG board can listen to their users and 
understand their perspective.


-------- Forwarded Message --------
Subject: 	Re: [Qgis-community-team] Books section on our website
Date: 	Tue, 13 Oct 2015 12:53:56 +0100
From: 	Colin D. MacLeod <cdmacleod at GISinEcology.com>
To: 	qgis-community-team at lists.osgeo.org

Hi Otto,

In response to your question:

>>I just wonder how can we be more attractive to people writing QGIS book?

As someone who writes GIS book (including a QGIS book for marine biologists
(and a percentage of profits will be donated to the QGIS project from its
sales once I get the yearly sales in), and one I'm currently finishing for
undergraduate biologists, which also uses QGIS), I have given a lot of
thought to how to make QGIS more attractive to writers of books, so maybe I
can add my two-cents worth from this perspective (and as an educator in

The main issue with writing books about QGIS (or indeed any software
package) is the time it takes to prepare, write and edit a book versus the
time between updates of the software package. It will typically take at
least 12 months to develop a book, edit it, test it out and then complete
it, especially if you are aiming for a high quality product. If the software
is updated during this time, this can cause major problems because either
the book is outdated before it is published, or it has to be re-worked to a
greater or lesser extent.

The main thing that causes problems is when there are changes in where tools
or settings are placed within individual menus (rather than the addition of
new functionality). In particular, people working from books can quickly
become lost if things are not exactly where a book says they are. This can
mean having to edit and re-test a book with each and every software update
(no matter how minor they might seem). For example, with the book I'm
currently finishing (which was written over a 12 months or so period), I
started it off under QGIS 2.4, then updated it for 2.6, and then again for
2.8.3 (with the latest version of QGIS now being 2.10, but I will stick with
the long-term legacy edition). The changes might have been relatively minor
between these editions of QGIS, but they are enough to have to re-work
books, and this slows the publication process. In addition, it greatly
reduces the useful lifespan of books written about using QGIS.

One of the things I really like about QGIS is that older versions are always
available, and that there is a long-term legacy edition. This makes it much
more attractive to write books using QGIS as the GIS software package as you
can tell people exactly what version to use (once they know how to do things
in one software version, it is easy enough to transfer this knowledge to
newer versions that might be available). However, this doesn't alter the
underlying issue that changes between QGIS versions, and the speed that
versions are put out make writing books problematic. This is not to say that
QGIS should not be updated regularly, and the addition of new functionality
is always to be applauded, it's just that it causes problems for would-be
book writers and publishers.

One potential way round this issue is to avoid relatively minor changes in
the location of tools and the layout of menus between different software
versions. For example, between QGIS 2.4 and 2.6, the location of the ADD
VECTOR LAYER tool was shifted from one set of menus to slightly different
one, meaning that books would need to be updated to remain useful. However,
as far as I can work out, this does not affect the functionality of QGIS in
any way (I may well be wrong on this point), but it does affect the ease
with which books can be written and remain up to date.

Now, from a programming point of view, it might not be easy to maintain the
location of tools and the layout of menus between software versions, but if
it could be (i.e. if the standard approach was to maintain layout as
appearance between versions rather than make relatively minor non-functional
changes with every update), it would make writing books using QGIS much
easier, and it would make the books more useful because they'd have a longer
shelf life.

In addtion, it would make it much easier to develop other resources that
would remain relevant for much longer periods of time (such as how to
videos, on YouTube - another thing I produce - and so on). Such a policy
would likely to lead to an increased uptake by educators, because they are
not having to continually update their instructions and exercises all the
time (it is the bain of many educators when, just before you start a block
of teaching, a key software package is updated and you are faced with having
to either hastily update your instructions, or somehow muddle through with
something that is out of date). Finally, it would also make producing
effective free documentation for QGIS by the QGIS project much, much easier,
because it wouldn't need to be continually updated (or at least, less of it
would need to be updated between software updates).

All this having been said, this is not a problem restricted to QGIS, or
indeed to GIS software in general. In fact, QGIS is actually one of the
better packages for maintaining menu layouts etc, but still, I feel that it
is limitting factor for those wishing to write and publish books, create
self-help resources and write effective documentation using QGIS.  However,
these are just my thoughts based on my own experiences, and others may
differ on this subject.

I hope this in some way helps, and thanks to all who develop QGIS for
producing such a great alternative to commercial GIS software packages (I
really feel that QGIS has come of age on the last 12 to 18 months).

All the best,


PS As a QGIS user, I'm always happy to donate a proportion of profits from
books back to the QGIS project, and will do this with all books I produce
that use QGIS.

But it
would be much nicer, if we could publish our own (free) documentation. We
could provide it as free download and people can pay for printed books, if
they want and authors could get payed from that, too. Would it make sense to
go in that direction, too?


Am Tue, 13 Oct 2015 10:42:48 +0200
schrieb "Neumann, Andreas" <a.neumann at carto.net>:
> Hi website team,
> I have been in contact with the company PacktPub - a company
> specializing in IT and in particular OpenSource IT books. They publish
> several books on QGIS. The nice thing is that they return some of the
> revenues back to the Open Source projects. We just received a payment
> over EUR 140 from Anitas book. They will add the other books to our
> royalty scheme.
> We also just recently added an entry in their Open Source section:
> https://www.packtpub.com/books/info/packt/open-source-projects-starting-q
> I noticed that we don't have a book section yet on our website. Given
> that there are more and more books on QGIS, it would be nice to have
> such a section. It would be a win-win situation - for PacktPub and for
> us. And of course it wouldn't have to be limited to books from PacktPub
> but can reference any books.
> The PacktPub manager would offer us additional discount codes or group
> discounts for ebooks if one wants to buy all QGIS ebooks at once - if we
> integrate this in our web page. Please note - the more books there are
> sold - the more we also get back from the royalty scheme program.
> Thanks,
> Andreas

Qgis-community-team mailing list for organizing community resources such as
documentation, translation etc..
Qgis-community-team at lists.osgeo.org

This email has been checked for viruses by Avast antivirus software.

Qgis-community-team mailing list for organizing community resources such as documentation, translation etc..
Qgis-community-team at lists.osgeo.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151013/2f4e761d/attachment.html>

More information about the Qgis-developer mailing list