[Qgis-psc] Sourcepole offer to port QGIS vector analysis tool to QGIS master

Vincent Picavet (ml) vincent.ml at oslandia.com
Thu Nov 26 05:53:28 PST 2015


Hello,

On 26/11/2015 14:08, Andreas Neumann wrote:
> Hi Vincent,
> 
> While I agree with you generally - please keep in mind that the
> situation is a bit different here. Sourcepole developed this
> functionality already (because their customers needed more reliable
> analysis functions) and we (QGIS.ORG) did not know about this
> development. It wasn't coordinated. Also, no customer from Sourcepole
> paid for it. It was their investment.

Yes, I do understand that the situation is odd, and that it would be an
exception to a general way of doing things.

> I was trying to find a useful compromise here, knowing that it is
> against what we should do normally. But maybe the best in this situation.
> 
> I personally find it a waste of resources (both time-wise and financial
> wise) if another company would redevelop everything that Sourcepole
> already did from scratch.
> 
> I totally agree that this shouldn't be the norm - and that all companies
> that develop stuff around QGIS should announce it and coordinate. But,
> for whatever reasons, this wasn't the case here and we will have to live
> with compromises.
> 
> I am also not suggesting, that QGIS.ORG should pay for  all of this, but
> may co-finance it.

I would suggest that QGIS.ORG do not intervene in this kind of
development funding, as it feature-oriented and not general maintainance.

Again, this could be an exception. But according to the amount of money
invested, this exception may represent a significant amount of the
general QGIS.ORG global funding, in detriment of other actions such as
quality insurance, bugfixing or PR reviews.

> Let's try to establish better rules/processes for the future so that
> this situation doesn't happen again, but I'd like to act pragmatic and
> find the most cost-effective way - while still ensuring high quality - 
> of getting to our goals. Money is not abundant - neither at QGIS.ORG,
> nor at the QGIS user base.

I do not agree that money is not abundant in the QGIS user base.
If you go this way, money will never be enough to fund all we could
potentially do.
There are a lot of organisms having budgets for software development and
funding. Feature funding is known to be easier to fund.
If QGIS.ORG starts to fund features, the message you carry is not "you
can help improve qgis by funding" but "if you do not fund the software,
the organization will do it for you anyway". This may solve a short-term
issue, but this is a wrong message for long-term development of the project.

While we (QGIS community) have limited impact on user's funding, we do
have full control of QGIS.ORG resources. I would rather continue
spending them on real QGIS issues - bugfixing, quality, code review -
than feature development.

In case we would make an exception for the ftools case, then it really
should be accompanied by a clear and loud message on the general process
and mid/long-term position of QGIS.ORG regarding funding priorities.
And even if we do not do this exception, let's make all this clearer
than it is now.

> But as I understand Tim - he wants to start a bidding process anyway -
> for replacing the analysis tools.

And again, I am strongly against QGIS.ORG making tender bids for features.

Vincent

> 
> Andreas
> 
> On 26.11.2015 13:08, Vincent Picavet (ml) wrote:
>> Hello,
>>
>> A reaction to the initial proposal and Martin's comment.
>>
>> On the proposal, I am worried about the global process, which does not
>> seem a fair way of doing things. I understand this is mainly a context
>> and situational issue.
>> IMHO this should never be the way we should do things. I fear that going
>> further with this proposition would carry a bad image on the development
>> and funding processes of QGIS. We are not really in a momentum where we
>> can do exceptions to rules we are still trying to define.
>>
>> We (and most opensource project) have development processes going this
>> way "announce what you want do, do it, enforce quality on it, review,
>> and integrate it".
>>
>> We should not encourage a different process by funding it, even if it
>> may be the easiest technical way.
>>
>> On 24/11/2015 17:14, Martin Dobias wrote:
>>> In order to keep spending of QGIS.ORG efficient and transparent, it
>>> would make sense to undertake bigger projects through a simple bidding
>>> process. The board would prepare a specification with requirements and
>>> any interested party would be allowed to participate. Bidders would
>>> submit their proposals and the board would then award the contract to
>>> the best bid. A proposal would include 1. total cost, 2. delivery
>>> date, 3. draft QEP, so that it is clear what the developers want to
>>> do.
>> I am totally against QGIS.org managing tender bids.
>>
>> It would come with a lot of conflicts of interest. This is something
>> which is very difficult to do well, and for an organization to gain
>> trust on such a process, it would need a lot of efforts.
>> Furthermore, QGIS.org operates on an international level, and
>> differences of business cultures, contract management and terms and
>> administrative tasks would add to the difficulty.
>>
>> There is a strong difference between QGIS.ORG funding things that nobody
>> wants to do, and managing tender bids between competitors for feature
>> development.
>> While I truly support the former, the latter should be out of scope for
>> the organization, and this should be clearly stated somewhere.
>>
>> Vincent
>>
>>
>>
>>> Regards
>>> Martin
>>>
>>>
>>> On Tue, Nov 24, 2015 at 11:58 AM, Neumann, Andreas
>>> <a.neumann at carto.net> wrote:
>>>> Hi QGIS.ORG board,
>>>>
>>>> As you may know, Sourcepole developed the Vector analysis tools from
>>>> Scratch
>>>> for QGIS enterprise. They are apparently willing to port it into
>>>> QGIS master
>>>> - but there are several things missing. They would do the missing
>>>> parts for
>>>> 25k CHF (Swiss franks) - it probably also contains a smaller share
>>>> of the
>>>> initial dev costs they had.
>>>>
>>>> The missing bits are:
>>>>
>>>> - porting into QGIS master
>>>>
>>>> - moving the code from plugin to QGIS core analysis library
>>>>
>>>> - create Python bindings
>>>>
>>>> - create unit tests
>>>>
>>>> -----------------------
>>>>
>>>> What they already did:
>>>>
>>>> Complete Rewrite in C++ of:
>>>>
>>>> - Convex Hull
>>>>
>>>> - Buffer
>>>>
>>>> - Intersect
>>>>
>>>> - Union
>>>>
>>>> - Symmetric difference
>>>>
>>>> - Clip
>>>>
>>>> - Difference
>>>>
>>>> - Dissolve
>>>>
>>>> - Eliminate sliver poylgons
>>>>
>>>> It allows to save the result as any OGR format, supports
>>>> multi-threading and
>>>> comes with a detailed error log in case of problems with invalid
>>>> geometries.
>>>>
>>>> ---------------------------
>>>>
>>>> Some additional background: they already invested >200 hours for the
>>>> re-development of the above methods. This equals about 35 kCHF.
>>>>
>>>> ----------------------------
>>>>
>>>> Timing: they could probably do it for the QGIS 2.16 release (feature
>>>> freeze
>>>> May 20, 2016). They are busy with contracts - they cannot do it
>>>> earlier with
>>>> the resources they have.
>>>>
>>>> To me, personally, this sounds like a good offer.
>>>>
>>>> We would have to find a solution for our short-term problems with
>>>> fTools -
>>>> but to me this is a very good proposal to have a good fTools
>>>> replacement in
>>>> the future.
>>>>
>>>> Andreas
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Qgis-psc mailing list
>>>> Qgis-psc at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>>> _______________________________________________
>>> Qgis-psc mailing list
>>> Qgis-psc at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
> 




More information about the Qgis-psc mailing list