What is "is a qgis problem"? (it was Re: [Qgis-user] Scattergram with compiled qwt5.2.0)

[Agustin Lobo]

I think this issue is equivalent to the one on having
Mrsid and ecw support under linux. From
a developer point of view (Jurgen), the fact that plugin Scatter plot
does not work because of a python-qwt5 problem is not "a qgis problem".
But from the user perspective, anything making qgis not working properly
or not fulfilling a set of minimum operational requirements must
be "a qgis problem".

In this particular case, if the situation is that there is no
python-qwt5 package able to let a given plugin work, then either
the qgis developers accept that making an specially-tuned binary version of
the python-qwt5 package is a TODO task, or the "qgis book of style of python
plugins"
must state that no plugins should be made relying on that package, and thus
an alternative for the current Scatter plot plugin should be in the agenda.

In general terms, I think that the qgis developers should discuss and
get to an agreement
on whether the goal is having an operational package or a testbed
for newer developments and proofs of concepts where reaching an
operational reliability is not a main issue.

Both options are valid, but they are different, and users must know the
choice.

I totally disagree with the comments posted by Tim Sutton and Paolo
Cavallini few weeks ago:

"> The counter side to the 'FOSS developers expect users to be compiling
> > geeks' debate is that users always want things at no effort and now 
  :-)

Tim: agreed fully. Too often we have requests from users, too rarely we
have help"

Users must put their effort on using QGIS, and their satisfaction is
the main reason for QGIS to exist. With no or few users, qgis will
decay. And users do a lot of effort on using QGIS, as they often must deal with
problems that are not present in commercial software and sometimes find, with
frustration, that their processing chain gets interrupted
in an step where qgis tools are not working (and the only answer they get
is "this is solved in svn trunk". A pretty satisfactory answer for a developer,
but a totally devastating answer for an student with his/her exercise to be due
in 24h). For some users, this is the price to pay because they cannot afford
paying the licenses
but for some others, having several alternatives of commercial licenses
paid as campus licenses, this is the price they pay for actively collaborating
on a public domain tool which, they believe, will be better on the long run.
We must all acknowledge the contribution made by developers. We must all
acknowledge the contribution made by of users.

The question is reaching a point in which a minimal set of critical operations
are reliably and efficiently done by QGIS (independently of other software such
as GRASS: QGIS+GRASS is already operational, but this is because GRASS reached
operational status 20 years ago). From this point on, people having
stable jobs (i.e., GIS technicians at universities, professors, researchers...)
will put a significant part of their paid time on debugging, enhancing and
extending QGIS. This is the case of R, which is, i my opinion, the paramount
example of success of public domain software, at least in science. I do not
know the exact numbers, but I think that despite the significant direct funding,
the most important source of funding for R comes from paid working time
invested by academic personnel with stable jobs).

I'm working on a web page in which I will propose a set of critical tasks
to be accomplished by a GIS software, along with an score of operationality and
comments for the specific case of QGIS on the different OS for which binary
versions exist. Hopefully other users will add their opinions.
In an equivalent way, I'll try to set up another page for the plugins, so that
users can have a fast check on the degree of operationality of a giving plugin
prior to actually installing it.

I think that QGIS is not far from such an operational point and that
making an effort on reaching it rather than on developing newer tools for a
while would make a lot of sense... for users. Obviously, developers will do
what they will be willing to do. All what users can do is telling other users
what the situation is.

Hopefully this message reaches enough "controversiality degree" for you to
comment during the hackfest

Have fun!

Agus

Jürgen E. Fischer wrote:
> Hi Agus,
> 
> On Tue, 27. Oct 2009 at 17:42:28 +0100, Agustin Lobo wrote:
>> Hmm... all I get is that building of qt3 should be avoided. Perhaps I
>> should wait until a general solution is set, perhaps during
>> your hackfest? Hopefully...
> 
> I doubt that it is a qgis problem at all.  You probably just need proper
> python-qwt5 packages.
> 
> 
> Jürgen
>