[geos-devel] GEOS Maintenance Grant

[Paul Ramsey]

While I appreciate the sentiment behind this, I do not believe the particular breakdown below is reflective of the current needs of this project.

- This is a library. The users of the project are not pro-sumers or non-technical, they are C and C++ developers. Users who are not C and C++ developers are supported by the particular project that is embedding the library, whether it be PostGIS, QGID, GDAL or Shapely. The documentation requirements are therefore relatively meagre. 
- This is a library with 15 years of technical debt. From its very birth, GEOS was built on foundations of sand. Hewing over-closely to the JTS code, it built up a burden of heal-allocations that have only been slowly pared back. The first professional services contract I let for improvements was... to track down the huge piles of memory leaks generated by that festival of heap allocations. Between the date of birth in the early 2000's to now, the C++ language itself has been transformed (several times), leaving the code base in a somewhat mish-mash state, some "modern" other ... not.
- This is a library with some big jobs that are no fun and yet fairly foundational. Off the top of my  head: support for M coordinates and rationalizing that against an efficient implementation of coordinatesequences, support for ISO circular arc geometry structures, efficient use of in-place data for more 'no-copy' operations.

The breakdown below perhaps makes sense for a project like QGIS, but for a this particular project with this projects current needs, focussing on development and developer-level documentation needs (good/better doxygen, example programs, consistent and clear in-code commenting) for this round is where we are going to go.

ATB,

P


> On Feb 17, 2022, at 1:20 PM, Jeff McKenna <jmckenna at gatewaygeomatics.com> wrote:
> 
> Dear GEOS PSC,
> 
> Great to hear about a grant to help the project along.
> 
> My feedback is to make sure that the funds are spread around, not just to one developer, but also to the (even more critical) parts of software projects that never receive funding, yet are so important to end-users: documentation, testing, and packaging.
> 
> I know it is 2022, and we have so many corporate influences in FOSS4G that it's hard to see through the activity/smoke, but, we should always try to make sure that the funds are spread around to as many parts of the project as possible.  For example, 50k USD could be shared by the GEOS PSC as:
> 
>  - 25k development
>  - 10k documentation
>  - 10k packaging
>  -  5k testing and releases
> 
> That is a fair plan for actual project "maintenance". QGIS.ORG (the registered entity behind QGIS) & the QGIS PSC does an excellent job at spreading the funding around to all parts of the project, which creates a "product" feeling to QGIS (a well-rounded result).
> 
> My rule of thumb, is that for every 1 hour of development in a software project spent, it should take approximately 8 hours of further testing, documentation, and packaging by others, if done properly. (instead of one funded developer doing an hour of development, and squeezing in a few minutes of docs often by the same developer).
> 
> I hope my feedback can be received well by the GEOS PSC, and they could keep this feedback in mind the next time funding comes along.
> 
> Thanks, sent from the east coast of Canada,
> 
> -jeff
> 
> 
> 
> 
> -- 
> Jeff McKenna
> GatewayGeo: Developers of MS4W, MapServer Consulting and Training
> co-founder of FOSS4G
> http://gatewaygeo.com/
> 
> 
> 
> On 2022-02-15 11:37 a.m., Howard Butler wrote:
>> GDAL PSC,
>> When we wrote the GDAL RFCs on sponsorship, we provided an escape clause to allow us to direct resources to other projects upon which GDAL depends. Our sponsorship numbers are still increasing, which provides us an opportunity to directly support some of those projects, and one of them is obviously GEOS. GEOS provides all of the geometry algebra support for GDAL/OGR and many other open source geospatial softwares including Shapely, PostGIS, GeoPandas, MapServer, and more.
>> Dan Baston of the GEOS PSC has been identified as the developer with capacity and interest in the next year to take on GEOS development on APIs and performance, which he has a long history of doing for the project. This support should allow him to work longer, multi-release upgrades that will provide strong performance and convenience benefits for the project.
>> I motion to provide the GEOS PSC with a $50,000 USD grant to address performance, API, and other work that does not attract directed funding in GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates, and development timelines. Howard Butler or Even Rouault of the GDAL NumFocus liaison team will coordinate dispersement as directed by the GEOS PSC and NumFocus rules.
>> Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html who have made this kind of grant possible. A better GEOS makes for a better GDAL.
>> Howard
> 
> 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel