<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi<div class=""><br class=""><blockquote type="cite" class="">On 26 Nov 2015, at 15:53, Vincent Picavet (ml) <<a href="mailto:vincent.ml@oslandia.com" class="">vincent.ml@oslandia.com</a>> wrote:<br class=""><br class="">Hello,<br class=""><br class="">On 26/11/2015 14:08, Andreas Neumann wrote:<br class=""><blockquote type="cite" class="">Hi Vincent,<br class=""><br class="">While I agree with you generally - please keep in mind that the<br class="">situation is a bit different here. Sourcepole developed this<br class="">functionality already (because their customers needed more reliable<br class="">analysis functions) and we (<a href="http://qgis.org" class="">QGIS.ORG</a>) did not know about this<br class="">development. It wasn't coordinated. Also, no customer from Sourcepole<br class="">paid for it. It was their investment.<br class=""></blockquote><br class="">Yes, I do understand that the situation is odd, and that it would be an<br class="">exception to a general way of doing things.<br class=""><br class=""><blockquote type="cite" class="">I was trying to find a useful compromise here, knowing that it is<br class="">against what we should do normally. But maybe the best in this situation.<br class=""><br class="">I personally find it a waste of resources (both time-wise and financial<br class="">wise) if another company would redevelop everything that Sourcepole<br class="">already did from scratch.<br class=""><br class="">I totally agree that this shouldn't be the norm - and that all companies<br class="">that develop stuff around QGIS should announce it and coordinate. But,<br class="">for whatever reasons, this wasn't the case here and we will have to live<br class="">with compromises.<br class=""><br class="">I am also not suggesting, that <a href="http://qgis.org" class="">QGIS.ORG</a> should pay for all of this, but<br class="">may co-finance it.<br class=""></blockquote><br class="">I would suggest that <a href="http://qgis.org" class="">QGIS.ORG</a> do not intervene in this kind of<br class="">development funding, as it feature-oriented and not general maintenance.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><br class=""><blockquote type="cite" class=""><br class="">Again, this could be an exception. But according to the amount of money<br class="">invested, this exception may represent a significant amount of the<br class="">general <a href="http://qgis.org" class="">QGIS.ORG</a> global funding, in detriment of other actions such as<br class="">quality insurance, bugfixing or PR reviews.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">Let's try to establish better rules/processes for the future so that<br class="">this situation doesn't happen again, but I'd like to act pragmatic and<br class="">find the most cost-effective way - while still ensuring high quality - <br class="">of getting to our goals. Money is not abundant - neither at <a href="http://qgis.org" class="">QGIS.ORG</a>,<br class="">nor at the QGIS user base.<br class=""></blockquote><br class="">I do not agree that money is not abundant in the QGIS user base.<br class="">If you go this way, money will never be enough to fund all we could<br class="">potentially do.<br class="">There are a lot of organisms having budgets for software development and<br class="">funding. Feature funding is known to be easier to fund.<br class="">If <a href="http://qgis.org" class="">QGIS.ORG</a> starts to fund features, the message you carry is not "you<br class="">can help improve qgis by funding" but "if you do not fund the software,<br class="">the organization will do it for you anyway". This may solve a short-term<br class="">issue, but this is a wrong message for long-term development of the project.<br class=""></blockquote><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><br class="">While we (QGIS community) have limited impact on user's funding, we do<br class="">have full control of <a href="http://qgis.org" class="">QGIS.ORG</a> resources. I would rather continue<br class="">spending them on real QGIS issues - bugfixing, quality, code review -<br class="">than feature development.<br class=""><br class="">In case we would make an exception for the ftools case, then it really<br class="">should be accompanied by a clear and loud message on the general process<br class="">and mid/long-term position of <a href="http://qgis.org" class="">QGIS.ORG</a> regarding funding priorities.<br class="">And even if we do not do this exception, let's make all this clearer<br class="">than it is now.<br class=""><br class=""><blockquote type="cite" class="">But as I understand Tim - he wants to start a bidding process anyway -<br class="">for replacing the analysis tools.<br class=""></blockquote><br class="">And again, I am strongly against <a href="http://qgis.org" class="">QGIS.ORG</a> making tender bids for features.<br class=""></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Well here are our options:</div><div class=""><br class=""></div><div class="">1) do nothing, ship fTools with its band aids</div><div class="">2) ask the community ‘will someone replace fTools with something better?’ and hope for the best</div><div class="">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)</div><div class="">4) directly fund SourcePole to integrate their code</div><div class=""><br class=""></div><div class="">For me the only acceptable route is (3) if you have a better idea of how to address it please share it :-)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thanks for your inputs Vincent!</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Tim</div><br class=""><blockquote type="cite" class=""><br class="">Vincent<br class=""><br class=""><blockquote type="cite" class=""><br class="">Andreas<br class=""><br class="">On 26.11.2015 13:08, Vincent Picavet (ml) wrote:<br class=""><blockquote type="cite" class="">Hello,<br class=""><br class="">A reaction to the initial proposal and Martin's comment.<br class=""><br class="">On the proposal, I am worried about the global process, which does not<br class="">seem a fair way of doing things. I understand this is mainly a context<br class="">and situational issue.<br class="">IMHO this should never be the way we should do things. I fear that going<br class="">further with this proposition would carry a bad image on the development<br class="">and funding processes of QGIS. We are not really in a momentum where we<br class="">can do exceptions to rules we are still trying to define.<br class=""><br class="">We (and most opensource project) have development processes going this<br class="">way "announce what you want do, do it, enforce quality on it, review,<br class="">and integrate it".<br class=""><br class="">We should not encourage a different process by funding it, even if it<br class="">may be the easiest technical way.<br class=""><br class="">On 24/11/2015 17:14, Martin Dobias wrote:<br class=""><blockquote type="cite" class="">In order to keep spending of <a href="http://qgis.org" class="">QGIS.ORG</a> efficient and transparent, it<br class="">would make sense to undertake bigger projects through a simple bidding<br class="">process. The board would prepare a specification with requirements and<br class="">any interested party would be allowed to participate. Bidders would<br class="">submit their proposals and the board would then award the contract to<br class="">the best bid. A proposal would include 1. total cost, 2. delivery<br class="">date, 3. draft QEP, so that it is clear what the developers want to<br class="">do.<br class=""></blockquote>I am totally against <a href="http://qgis.org" class="">QGIS.org</a> managing tender bids.<br class=""><br class="">It would come with a lot of conflicts of interest. This is something<br class="">which is very difficult to do well, and for an organization to gain<br class="">trust on such a process, it would need a lot of efforts.<br class="">Furthermore, <a href="http://qgis.org" class="">QGIS.org</a> operates on an international level, and<br class="">differences of business cultures, contract management and terms and<br class="">administrative tasks would add to the difficulty.<br class=""><br class="">There is a strong difference between <a href="http://qgis.org" class="">QGIS.ORG</a> funding things that nobody<br class="">wants to do, and managing tender bids between competitors for feature<br class="">development.<br class="">While I truly support the former, the latter should be out of scope for<br class="">the organization, and this should be clearly stated somewhere.<br class=""><br class="">Vincent<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">Regards<br class="">Martin<br class=""><br class=""><br class="">On Tue, Nov 24, 2015 at 11:58 AM, Neumann, Andreas<br class=""><<a href="mailto:a.neumann@carto.net" class="">a.neumann@carto.net</a>> wrote:<br class=""><blockquote type="cite" class="">Hi <a href="http://qgis.org" class="">QGIS.ORG</a> board,<br class=""><br class="">As you may know, Sourcepole developed the Vector analysis tools from<br class="">Scratch<br class="">for QGIS enterprise. They are apparently willing to port it into<br class="">QGIS master<br class="">- but there are several things missing. They would do the missing<br class="">parts for<br class="">25k CHF (Swiss franks) - it probably also contains a smaller share<br class="">of the<br class="">initial dev costs they had.<br class=""><br class="">The missing bits are:<br class=""><br class="">- porting into QGIS master<br class=""><br class="">- moving the code from plugin to QGIS core analysis library<br class=""><br class="">- create Python bindings<br class=""><br class="">- create unit tests<br class=""><br class="">-----------------------<br class=""><br class="">What they already did:<br class=""><br class="">Complete Rewrite in C++ of:<br class=""><br class="">- Convex Hull<br class=""><br class="">- Buffer<br class=""><br class="">- Intersect<br class=""><br class="">- Union<br class=""><br class="">- Symmetric difference<br class=""><br class="">- Clip<br class=""><br class="">- Difference<br class=""><br class="">- Dissolve<br class=""><br class="">- Eliminate sliver poylgons<br class=""><br class="">It allows to save the result as any OGR format, supports<br class="">multi-threading and<br class="">comes with a detailed error log in case of problems with invalid<br class="">geometries.<br class=""><br class="">---------------------------<br class=""><br class="">Some additional background: they already invested >200 hours for the<br class="">re-development of the above methods. This equals about 35 kCHF.<br class=""><br class="">----------------------------<br class=""><br class="">Timing: they could probably do it for the QGIS 2.16 release (feature<br class="">freeze<br class="">May 20, 2016). They are busy with contracts - they cannot do it<br class="">earlier with<br class="">the resources they have.<br class=""><br class="">To me, personally, this sounds like a good offer.<br class=""><br class="">We would have to find a solution for our short-term problems with<br class="">fTools -<br class="">but to me this is a very good proposal to have a good fTools<br class="">replacement in<br class="">the future.<br class=""><br class="">Andreas<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">Qgis-psc mailing list<br class=""><a href="mailto:Qgis-psc@lists.osgeo.org" class="">Qgis-psc@lists.osgeo.org</a><br class="">http://lists.osgeo.org/mailman/listinfo/qgis-psc<br class=""></blockquote>_______________________________________________<br class="">Qgis-psc mailing list<br class=""><a href="mailto:Qgis-psc@lists.osgeo.org" class="">Qgis-psc@lists.osgeo.org</a><br class="">http://lists.osgeo.org/mailman/listinfo/qgis-psc<br class=""><br class=""></blockquote></blockquote><br class=""></blockquote><br class="">_______________________________________________<br class="">Qgis-psc mailing list<br class=""><a href="mailto:Qgis-psc@lists.osgeo.org" class="">Qgis-psc@lists.osgeo.org</a><br class="">http://lists.osgeo.org/mailman/listinfo/qgis-psc<br class=""></blockquote><br class=""><div class=""><span>—</span><br class=""><span><br class=""></span><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline"><span><img height="66" width="160" apple-inline="yes" id="C77DF0DD-75CC-4C2A-9BE5-311C82361F1D" apple-width="yes" apple-height="yes" src="cid:62C890D4-3964-4609-BDE6-7536D5FBDD70" class=""></span><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-align: center;" class=""><br class="Apple-interchange-newline"><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-align: center;" class="">Tim Sutton</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-align: center;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="text-align: center;" class="">Visit <a href="http://kartoza.com" class="">http://kartoza.com</a> to find out about open source:</div><div style="text-align: center;" class=""><br class=""></div><div class=""><div style="text-align: center;" class="">* Desktop GIS programming services</div><div style="text-align: center;" class="">* Geospatial web development</div><div style="text-align: center;" class="">* GIS Training</div><div style="text-align: center;" class="">* Consulting Services</div><div style="text-align: center;" class=""><br class=""></div><div class=""><div style="text-align: center;" class="">Skype: timlinux Irc: timlinux on #qgis at <a href="http://freenode.net" class="">freenode.net</a></div><div style="text-align: center;" class="">Tim is a member of the QGIS Project Steering Committee</div><div style="text-align: center;" class=""><br class=""></div><div style="text-align: center;" class="">Kartoza is a merger between Linfiniti and Afrispatial</div></div></div></div>
</span></div><br class=""></div></body></html>