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

Tim Sutton tim at kartoza.com
Fri Nov 27 03:19:17 PST 2015 

Hi

> On 26 Nov 2015, at 15:53, Vincent Picavet (ml) <vincent.ml at oslandia.com> wrote:
> 
> 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 maintenance.

I do not think we should make blanket rules excluding us from developing features with QGIS funds. Our criteria should be only whether it is in the interests of the community. I think in the case or fTools it clearly is.

> 
> 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.

I think we will always try to keep funds for hackfests, bug fixing and QA work as first priority. Andreas as treasurer will keep any planned spending in check, and will present an annual budget for the annual general meeting of QGIS which all voting members can vote on, and any general member of the QGIS community is welcome to comment on.

> 
>> 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.

I think we need to put out both messages - the problem with organisations building features is they are generally serving their own interests, and where they intersect with the greater community hopefully contributing them. But there are many things that don’t get attention because a specific organisation is not interested, even though the whole user base is. fTools is probably a good example of that - the code is largely untouched since it was originally contributed although geo-processing is such a core activity in GIS you would think it would have received lots of attention.

Further, using funding to steer development also allows us to introduce a sense of cohesion across QGIS that will be missed by ad hoc feature additions.

I think as with all things we need to evaluate each situation and suggestion by its merits, look at what the broader community is worrying about and then make our plans accordingly.


> 
> 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.


Well here are our options:

1) do nothing, ship fTools with its band aids
2) ask the community ‘will someone replace fTools with something better?’ and hope for the best
3) provide funding or co-funding to sponsor its replacement in a fair and transparent way that any capable developer can make a proposal for (including SourcePole)
4) directly fund SourcePole to integrate their code

For me the only acceptable route is (3) if you have a better idea of how to address it please share it :-)


Thanks for your inputs Vincent!

Regards

Tim

> 
> 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
>>>> 
>> 
> 
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc

—





Tim Sutton

Visit http://kartoza.com <http://kartoza.com/> to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20151127/ceaba44d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaLogo160x66.png
Type: image/png
Size: 9324 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20151127/ceaba44d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20151127/ceaba44d/attachment.sig>

More information about the Qgis-psc mailing list