[gdal-dev] Driver maintenance - long-term solution ?

[xavier lhomme]

Hello all
 The question of maintaining the old drivers raises a whole bunch of
questions: how to finance the technical debt, how to involve more
developers in this project, how to promote it, ... GDAL is an OSGeo
project. Shouldn't these questions be addressed by OSGeo which should help
in the distribution of funds, help in piloting this project...? Maybe OSGeo
could get closer to an organization like OGC with members funding projects,
initiative projets, testbed ...

Best regards
xlhomme

Le jeu. 14 janv. 2021 à 07:06, Ari Jolma <ari.jolma at gmail.com> a écrit :

> Thank you Howard, Daniel, Jukka, and others.
>
> When I google for qgis I get its page and six sub pages in the way
> Google does it. One of those is "Donations". When I do the same for
> GDAL, there's no such page. I guess the first and practical thing to do
> would be to make regular donations possible. The second thing would be
> to advocate companies/people to make donations without strings attached.
> That's already much in the domain of OSGeo, but the first thing is quite
> much in the project's domain.
>
> Best regards,
>
> Ari
>
>
> Daniel Morissette kirjoitti 13.1.2021 klo 21.11:
> > Thank you Howard for a great analysis and for pointing out the key
> > problems.
> >
> > Personally I think the top two problems are:
> >
> > 1- Bus number: we need to find a way to increase the number of active
> > maintainers to ensure the viability and velocity of the project
> >
> > 2- Sustainable revenue stream for maintenance activities: as you
> > explained, it is relatively easy to fund features, but profitable
> > companies selling software or services that use GDAL need to realize
> > that it would be an investment for them to contribute even just a
> > fraction of 1% of their sales in "non-string-attached funding" to
> > support non-sexy stuff such as release management, bug fixes, security
> > fixes, dependency upgrades, packaging, docs, etc... not only in GDAL,
> > but in the top-5 open source components that they rely on.
> >
> > The QGIS approach to managing funding is an option, but it's not the
> > only one. I would tend to go for a more decentralized approach to
> > reduce the risk for the project with a single entity supporting it.
> >
> > I step up to work with you Howard toward improving the situation.
> > (Actually I had already written personally to Even to discuss some
> > options before seeing your reply)
> >
> > Daniel
> >
> >
> >
> > On 2021-01-13 12:33, Howard Butler wrote:
> >>
> >>> Is there something fundamentally wrong with the current GDAL?
> >>
> >> The project's history is one person doing most of the work. This
> >> person eventually burns out.
> >>
> >> Here's a table of the top five lifetime commits to the repository as
> >> of December 2020.
> >>
> >> Even Rouault – 19,838
> >> Frank Warmerdam – 11,503
> >> Kurt Schwehr – 3,403
> >> Andrey Kiselev – 1,320
> >> Howard Butler – 768
> >>
> >> The reason why this person burns out is they are actually doing
> >> *three* jobs, not one. Three, you say?
> >>
> >> First is the actual maintainer job. You're the clearinghouse for
> >> bugs, the primary authority on the mailing list, the first respondent
> >> in the bug tracker, and the one that organizes and cuts the software
> >> release. When we think of the maintainer for the GDAL project, this
> >> is what we think of. No one organization will pay for just this job.
> >>
> >> This means you need a revenue stream to make it maintenance your full
> >> time gig. That's easy enough, just get paid for working on GDAL,
> >> right? Well sure, but people don't want to pay for you to fix bugs
> >> that users vaguely provide in the mailing list. They want to pay for
> >> functionality they need to add to their software. So you are in a
> >> spot – you have to *add* more to the software to earn revenue. For
> >> GDAL, adding more means more drivers and more capabilities for those
> >> drivers (CPL, VSICloud, etc). This creates more bugs and maintenance
> >> load that the original directed funder supports for only a little
> >> while. This second job is in conflict with the first and the
> >> dissonance amplifies as time goes one.
> >>
> >> The third job is you have to solicit work through the contacts you've
> >> built up to keep the revenue hopper full. Invoicing, statements of
> >> work, negotiation, telecons, and the usual business stuff. People see
> >> you as cheap because you're "open source", and pressure you on price,
> >> scope, and completion time. You eventually orient about a small cadre
> >> of repeat clients with strong trust relationships.
> >>
> >> How can this be fixed?
> >>
> >> 1) Burn through the current maintainer and hope another one comes
> >> along. The users of the GDAL project simply got lucky that Even
> >> picked up the torch after Frank moved on. Maybe that happens again on
> >> the next iteration.
> >>
> >> 2) Refactor the software so that more maintainers can participate.
> >> That's been our current discussion, which doesn't seem to be
> >> converging on any solutions.
> >>
> >> 3) Provide a revenue stream so the maintainer only has to do the
> >> maintenance job, and not the other two jobs that are in conflict with
> >> the project's maintenance. This person should be paid like the FAANG
> >> senior engineer that's currently taking GDAL and using it to add some
> >> geo widget to their software.
> >>
> >> OSGeo was supposed to be the answer to #3, but in 15 years of
> >> existence it has shown it is not and never will be. Maybe it is time
> >> to start a GDAL foundation ala QGIS and others and direct corporate
> >> benefactors to fund it directly. Those benefactors would have to
> >> pledge significant resources to at least get to the level of a FAANG
> >> senior engineer as a start.
> >>
> >> Howard
> >>
> >>
> >>
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>
> >
> >
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210114/77e4653a/attachment-0001.html>