Inspired by some forum topics and the general attitude of some users (observed in IRC, bugtracker, mailing lists and personal emails). I actually wrote a bit about this a few months ago. One more time and that’s it, I won’t go back to it.
Disclaimer
Everything that follows is the author’s personal (and possibly incorrect) opinion and does not claim to be the ultimate truth.
The random user is perplexed and outraged because the developers refuse to implement the feature (which gradually becomes a set of loosely connected features) that the user needs for his specific task. Really, why? First of all, the requested functionality looks strange not only to the developers, but also to many other users who, by the way, have a certain weight and influence in the community (more on this below). This means that the importance and necessity of the requested functionality are highly questionable. The second point that the user persistently ignores is the existence of a third-party plugin that does virtually everything they need. It is enough to make a minimal modification to the plugin yourself or to contact the author (an adequate and responsive person who responds promptly to comments and polite, reasoned requests).
The software is made for everyone, there is a roadmap and a vision for future development. And it makes no sense to add something to the core that only a single user needs, especially if there is a plugin with similar functionality. If the feature is really important and should be in the core — justify it. Developers cannot physically know and foresee everything, so if you can explain to them why it should be this way and not that way, changes will be made. After all, they want the program to be convenient and useful. Just remember that reasons along the lines of “I use your software in my company, so you have to…” look silly as an argument.
Another user complains that developers “resist when bugs are clearly pointed out to them”. Obviously, resistance should be understood as a polite request to describe the nature of the problem and the proposed solution in more detail. By the way, it is at least not nice to reply to a stranger with “wise will understand”. It may well turn out that this person is much wiser than you are.
It’s not unreasonable to repeat a few very simple things here:
open source software is usually developed by enthusiasts in their spare time, primarily to solve their own problems
developers are people too (unexpectedly, yes). They have jobs, personal lives and some needs
strange as it may seem, even a fairly large project like QGIS was developed by a very limited number of people. Now, the number of active developers does not exceed 8 people. For comparison, the number of open issues in redmine is 1155. So you should not expect everyone to rush to fix this particular bug as soon as you file it
from what has been said above, you can understand that there is more than enough work to do. If you want a response — respect other people’s work and value other people’s time: spend a few minutes writing a clear description of the problem rather than throwing out scattered links to a dozen sites. Nobody wants to collect and analyse information in such a form, which is also accompanied by an arrogant “wise men will understand”
Also don’t resent the fact that some bugs are fixed when
the problem will “hit” one of the developers or people who have influence over them
It’s expected and normal. Let me try to explain why this happens.
The reason people get into development is almost always the same: they need a convenient tool to solve their problems. As a result, people first work on what they need/are interested in. In other words, people make software for themselves. It is logical that the bugs that hinder the developer personally will be fixed first. The same goes for adding new features.
Furthermore, in any relatively large project, each developer has their own area of responsibility. Some developers are responsible for one subsystem, others for two or three. And no one is going to dive into someone else’s code without a real need: it takes time. And as I have already mentioned, developers tend to be enthusiasts and spend their own free time on it. Do you think there will be many people willing to dig into someone else’s code, with a vague description of the problem and no way to reproduce the bug, instead of doing something more interesting?
Now about “people who have influence over them”. Usually, these are not just some abstract John or Jane. Developers are influenced by people who are recognised in a field, who have knowledge and authority, and who are doing something useful. Both recognition and influence do not just appear, they are well-earned. These people have already proven that their opinions count for something; they not only take from the community but also support it (not necessarily financially, though it can be financial support too). Of course, we shouldn’t ignore the factor of personal sympathy: I don’t think anyone would argue that people are more likely to help their friends than complete strangers.
All of the above applies to “volunteer-based” development. If you are not satisfied with such an arrangement — find your own way to motivate people. When the canton of Solothurn needed annotations, they didn’t moan “Do it for us, we use QGIS”. Instead, they approached Marco, described the problem, got him interested, and soon got what they wanted. When Andreas finds a bug, he reports it with a detailed description and a test dataset. In urgent cases, he always finds a developer willing to help solve the problem. And these are not isolated examples.
Perhaps you should reconsider your attitude to opensource?
We all face problems from time to time. Here are a few recent ones from my personal collection.
QGIS and SpatiaLite
Those who build QGIS themselves know that not so long ago there was a move to use external spatialindex and SpatiaLite instead of internal bundled copies. The former has been completely removed, but SpatiaLite is still there because it is either missing or too old in some distributions (namely Debian Squeeze, as well as Ubuntu Lucid, Maverick, Natty and Oneiric). The problem occurs when building QGIS with an external version of the library.
For historical reasons, the SpatiaLite can be compiled in two different ways:
as a loadable extension module for the system version of SQLite
as a standalone all-in-one library that combines the SQLite engine with the spatial capabilities of SpatiaLite
So. If you have SpatiaLite built as an all-in-one library, you can kiss SpatiaLite support in QGIS goodbye. You will not be able to create a new layer or open an existing one. What spices things up is that both configuration and compilation go smoothly: no missing files, no errors. The solution is to rebuild SpatiaLite as a loadable module and then rebuild QGIS. However, at this point you may face another problem.
SpatiaLite and dynamic linker
If the configure script constantly fails to find SQLite, GEOS and PROJ.4 when building a loadable SpatiaLite module on Linux, even though all these libraries are installed and have the correct version number, it is likely that your distribution has a policy of using unmodified source code (i.e., sources are only patched when absolutely necessary).
It should help to run configure as shown below
LDFLAGS=-ldl ./configure
PyQt4 and a new style of signal-slot connections
Since PyQt 4.5 there is a “new” style of signal-slot connection available in addition to the old style (more details). The new style is more Pythonic, and it is highly recommended to use it instead of the old style. The only thing is… if the interface was generated in Qt Designer and then converted to code using pyuic4, and the new style signal-slot connections are used in the code, then when you try to disconnect the signal from the slot, you may get a message that the operation cannot be performed. The situation has been clarified after contacting the developers:
PyQt allows connections to be made to any Python callable.
With old style connections a proxy slot is created under the covers whenever a callable is used (as opposed to when SLOT() is used to refer to a C++ slot). Therefore, in your example, a proxy is always created for the connection to Dialog.reject even though that refers to the object that wraps the C++ slot (as there is no Python reimplementation of reject()).
New style connections are a bit smarter in that they treat slot objects that refer to a wrapped C++ slot and objects that refer to some real Python code differently – a proxy is only created in the latter case.
So the rule is that if you make a connection old style then you must disconnect old style as well and the same for new style. You also need to be aware that pyuic4 uses old style connections.
It’s actually a bug, but they won’t fix it.
I accept that this is a bug, but I don’t want to fix it. The reason is that the changes required to the old style support code would be quite significant and I don’t think the risk to the stability of that code is worth it at this stage of the life of PyQt4 particularly as the workaround is straightforward.
The mentioned workaround is to create a dummy slot that simply calls the corresponding slot of the parent object. I.e., if you wanted to disconnect the reject() slot of a dialogue from the rejected() signal, using the old style, it was enough to write
I found out how to write plugins for SEXTANTE. It turns out there is nothing difficult about it, and SEXTANTE is great. It is a pleasure to write plugins for it. I started by adapting my first plugin, Statist, and now I’m thinking about porting all the other analytical plugins. And if all goes well, I will have my own toolbox with the modest name “Alex’s tools” :-).
The 7th QGIS developers meeting held in Lyon (France) has ended.
The first day was rather uneventful - the host university had problems with the electricity, and besides, almost everyone arrived in Lyon in the afternoon. The following days were more intense: presentations, discussions on various aspects of the project, and, of course, coding.
finances. If we leave out all the figures and details, the picture is as follows: costs are rising, but the balance is still positive
release model. The idea of multiple release branches has been abandoned, and all new releases will be made from the main tree. Release branches will only be used as “markers”, and to fix critical bugs (like the epic extent bug) after a release. Non-critical bugfixes will not be backported. There will be a freeze period (both for code and strings) before a release on the master branch.
migrating documentation from LaTeX to RST and setting up an online platform for translators. Actually, the migration has already started with the QGIS User Manual. The plan is to convert all project documentation to RST format
improving the testing infrastructure. New tests for different parts of the code have been added, and a testing server has been setup
Among the topics discussed were also the upcoming GSoC, integration of some 3rd-party plugins into the core (DB Manager was already integrated at the time of writing), API changes, and so on.
Let’s be clear. The list of projects I’m involved in and things I do isn’t very long at first glance and includes:
maintaining and developing 26 QGIS plugins (23 Python and 3 C++)
maintaining translations of 3 manuals
QGIS core development/bugfixing
from time to time, small patches to other GIS projects
SlackBuilds for various GIS software
But. All of this, oddly enough, is done in my spare time (which is quite limited, by the way), not on a full-time basis at work. Some of the things have come about because the functionality I needed was not available or did not meet certain criteria; something was done just for fun.
Therefore, do not be offended, and even more, do not try to play boss, having received a refusal to implement some feature; do not breathe down my neck and constantly pester me to fix a bug that annoys you; do not complain about slowness and lack of attention. I don’t want to and won’t reduce my free time any further. I’d rather just stop doing some things.
I’ve already posted a couple of beautiful videos showing the QGIS development process (first, second) made with Gource. Here are a few more, this time made by myself.
A complete history, from the beginning of development to 25 January 2012.
Developers activity from 1 September 2011 to 26 January 2012 (805 commits were made)
Another year has passed. It is time to remember all the interesting and important events.
QGIS 1.7.0 has been released. It is positioned as a long-term support version and the last release of the 1.x series. The project has radically upgraded its infrastructure: the repository has been moved to GIT (main mirror is GitHub), the separate bug tracker and wiki have been replaced by Redmine. A new plugin repository has been launched, providing developers with a code repository, bug tracker and plugin description page. This repository already contains several unique plugins and is included by default in the development version of QGIS.
After much deliberation, I entered a competition for scientific and practical projects on the problem of forest fires. My modest result was third place.
A Russian translation of the PyQGIS Developer Cookbook has been published on the QGIS website. Unfortunately, another translation I was working on remained unfinished for various reasons. I released 4 new plugins in addition to the existing ones, and the same number of plugins remained in a suspended state. I have written some HOWTOs, actually there are a lot of topics to cover, but no mood or inspiration to write anything.
Unfortunately, I missed both QGIS hackfests. I’ve started reading a lot again, and I’ve made a list of films I want to watch, which I’m slowly whittling down.
The 6th Quantum GIS developer meeting in Zurich (Switzerland) ended on Monday. Below are my impressions, supplemented with information from Tim’s blog.
This meeting was more “quiet” than the previous ones: the presentations were only held on the first day (but the picture and sound were very good), there were no announcements of the presentations on IRC, so it wasn’t always clear who was speaking and what the topic was.Some topics were discussed on IRC and the mailing lists, if you wanted to, you could contribute with your comments, suggestions or topics. Subjectively, there were not that many commits, partly due to the use of GIT, but still not that many changes compared to previous hackfests.
One of the main discussions was on issues related to topology support. This was facilitated by the presence of Sandro Santilli, one of the developers of GEOS and PostGIS. Topological editing has been discussed almost since the introduction of digitising support in QGIS. At the meeting, we discussed the possibility and prospects of creating a common mechanism for topological editing of different data, but in the end, we decided to keep all three existing systems (simple features, the GRASS topological model, and the PostGIS topological model). This decision was made because of the large differences in the underlying models. Of course, if someone proposes a worthy implementation of the universal mechanism, it will be gladly considered.
As QGIS has expanded from the desktop market to the web, discussions about QGIS Server and, more recently, QGIS Web Client have become an integral part of meetings. Some of the results of these discussions can be found on a dedicated wiki page.
Finally, the move to GitHub is complete: all the documentation was moved there during the hackfest. The migration was accompanied by a change in directory structure, and a description of the new workflow for translators will be published soon. There are also plans to abandon LaTeX in favour of RST (ReStructured Text), which should lower the barrier to entry for both authors and translators.
Since the preparation of new QGIS releases is quite complex and time consuming task, Tim has taken Werner on as his assistant. Tim will prepare the main releases, and Werner will do the point releases. By the way, the upcoming release 1.7.2 is his first work at this position.
As preparing new QGIS releases is a complex and time-consuming task, Tim took on Werner as his assistant. Tim will prepare the major releases and Werner will prepare the point releases. The upcoming 1.7.2 release is his first work in this position.
Strangely enough, although everyone has been talking about revising and updating the API for a long time, nothing has been broken yet (I was hoping this process would at least start at haskfest). At the same time, so much new functionality has been added that it was decided to make 1.7.2 the last release of the 1.7 series and then release 1.8.
In addition to the topics already mentioned, the following issues were also discussed to a greater or lesser extent:
QGIS on Android
performance testing and identification of bottlenecks in vector data handling
new infrastructure (wiki migration, bugtracker improvements, new plugins repository, styles repository)
revival of unit testing and the launch of the project’s Dart server
user interface optimisation and redesign for version 2.0 (1, 2)
overhaul of the QgsGeometry class (adding support for curves, splines, collections)
As for me, I was not in the mood to fix bugs, nor did I have any special plans. So I was mainly busy adding new bugs :-) by adding new tools to fTools and GdalTools.